背景:
该项目功能比较多, 而且在不同机房部署了多个实例, 但是只有其中一个机房的使用出现了明显的内存泄露(因为功能比较多,不同机房用的功能或者着重用的功能不一样). 发现问题是通过访问出现了 500,然后上服务器 top 发现了 uwsgi 多个进程占用比较大的内存,最大一个占用了 20% (8g 内存), 累积起来用满了内存和交换空间.
求助: 如何有一种比较通用的内存泄露排查方法来定位到源码行.
优先不考虑通过修改源码重启后收集内存对象的方法.(什么 objgraph 工具之类) 因为这种感觉不太适用于其他语言, 而且需要重启破坏掉现场,需要等待下次触发.
已经有的思路:
想通过查看具体分配堆地址看具体内容, 猜测是哪部分的功能.但是还在踩坑中.
通过 gdb --pid [pid] attach 进程, 然后 shell pmap [pid] 查看分配内存,定位到一个 anno 的比较大的内存,然后
x/big number address 来取得内存地址内容
感觉大家的回答.
该项目功能比较多, 而且在不同机房部署了多个实例, 但是只有其中一个机房的使用出现了明显的内存泄露(因为功能比较多,不同机房用的功能或者着重用的功能不一样). 发现问题是通过访问出现了 500,然后上服务器 top 发现了 uwsgi 多个进程占用比较大的内存,最大一个占用了 20% (8g 内存), 累积起来用满了内存和交换空间.
求助: 如何有一种比较通用的内存泄露排查方法来定位到源码行.
优先不考虑通过修改源码重启后收集内存对象的方法.(什么 objgraph 工具之类) 因为这种感觉不太适用于其他语言, 而且需要重启破坏掉现场,需要等待下次触发.
已经有的思路:
想通过查看具体分配堆地址看具体内容, 猜测是哪部分的功能.但是还在踩坑中.
通过 gdb --pid [pid] attach 进程, 然后 shell pmap [pid] 查看分配内存,定位到一个 anno 的比较大的内存,然后
x/big number address 来取得内存地址内容
感觉大家的回答.