- 主题:发生内存泄漏怎么办
有一个做监控用途的脚本，刚启动时占内存几十M，长期运行之后已经超过300M
lsof检查，没什么异常，只有Python、各种so库、它自己的日志文件
查看/proc/pid/smaps发现大量匿名内存块，不对应文件、不是heap、不是stack、不是vdso性质。用gdb把这些块分别dump查看，发现内容有：
1 sar的执行结果（这脚本调用过sar）
2 这脚本读取过的某日志文件的内容，而且包含不止最新内容，还有些旧日期的内容
这种情况应该怎么处理呢？
--
修改:JulyClyde FROM 113.108.77.*
FROM 113.108.77.*
valgrind 试试？
【 在 JulyClyde (我的月份又来了) 的大作中提到: 】
: 有一个做监控用途的脚本，刚启动时占内存几十M，长期运行之后已经超过300M
: lsof检查，没什么异常，只有Python、各种so库、它自己的日志文件
: 查看/proc/pid/smaps发现大量匿名内存块，不对应文件、不是heap、不是stack、不是vdso性质。用gdb把这些块分别dump查看，发现内容有：
: ...................
--
FROM 124.72.118.*
搜了个资料，说编译的时候需要-g
对我这个场景，是指编译python的时候需要-g吗？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: valgrind 试试？
--
FROM 113.108.77.*
这东西本身支持插件机制
刚发现内存超高和安装了某个插件有对应关系
而这个插件调用了numpy
搜了一下，numpy似乎这方面名声不太好啊？
【 在 JulyClyde (我的月份又来了) 的大作中提到: 】
: 有一个做监控用途的脚本，刚启动时占内存几十M，长期运行之后已经超过300M
: lsof检查，没什么异常，只有Python、各种so库、它自己的日志文件
: 查看/proc/pid/smaps发现大量匿名内存块，不对应文件、不是heap、不是stack、不是vdso性质。用gdb把这些块分别dump查看，发现内容有：
: ...................
--
FROM 113.108.77.*
numpy内存泄漏？
【 在 JulyClyde 的大作中提到: 】
: 这东西本身支持插件机制
: 刚发现内存超高和安装了某个插件有对应关系
: 而这个插件调用了numpy
: ...................
--
FROM 60.1.11.*
应该是某些不再用的对象没有释放。
我也碰到类似的问题。还好程序是自己开发的。出问题以前写了很多测试用例，根据测试用例大致判断出问题的几个模块，然后挨个排查。
不知道有没有统一的对象管理接口，能够跟踪统计所有未销毁的对象。
【 在 JulyClyde 的大作中提到: 】
: 有一个做监控用途的脚本，刚启动时占内存几十M，长期运行之后已经超过300M
: lsof检查，没什么异常，只有Python、各种so库、它自己的日志文件
: 查看/proc/pid/smaps发现大量匿名内存块，不对应文件、不是heap、不是stack、不是vdso性质。用gdb把这些块分别dump查看，发现内容有：
: ...................
--
FROM 59.109.150.*
刚刚搜了搜，可以试试tracemalloc这个模块。
【 在 JulyClyde 的大作中提到: 】
: 有一个做监控用途的脚本，刚启动时占内存几十M，长期运行之后已经超过300M
: lsof检查，没什么异常，只有Python、各种so库、它自己的日志文件
: 查看/proc/pid/smaps发现大量匿名内存块，不对应文件、不是heap、不是stack、不是vdso性质。用gdb把这些块分别dump查看，发现内容有：
: ...................
--
FROM 59.109.150.*
升级了numpy之后
第一次启动还是很快升高；第二次稳定了
好奇怪
【 在 ZHMZFFL (ZHMZFFL) 的大作中提到: 】
: numpy内存泄漏？
--
FROM 113.108.77.*