关于 Python 内存泄漏

2018-10-10 22:23:30 +08:00
 Buffer2Disk
线上机器跑了一个 Python 的多线程的程序，运行了 2 天，发现貌似有内存泄漏的情况

htop 查了下真实内存使用达到 1G 左右(机器总共是 2G 内存)

但是 htop 上面查看 Python 程序本身只占了不到 10%的内存，整个机器上只有这一个 Python 程序

请问大家，这是 Python 程序的 内存泄漏 还是 句柄泄漏 了？

有没有什么好的办法来排查嘛？ 我用了下检测工具查看 Python 程序自身是 dict 对象占用了最多的内存

4227 次点击
所在节点    Python
32 条回复
Buffer2Disk
2018-10-11 21:25:51 +08:00
@aijam

cat /proc/meminfo
MemTotal: 2046876 kB
MemFree: 750100 kB
Buffers: 104608 kB
Cached: 188044 kB
SwapCached: 0 kB
Active: 392248 kB
Inactive: 134392 kB
Active(anon): 234008 kB
Inactive(anon): 212 kB
Active(file): 158240 kB
Inactive(file): 134180 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 4095996 kB
SwapFree: 4095996 kB
Dirty: 156 kB
Writeback: 0 kB
AnonPages: 233992 kB
Mapped: 9972 kB
Shmem: 228 kB
Slab: 404976 kB
SReclaimable: 304236 kB
SUnreclaim: 100740 kB
KernelStack: 1872 kB
PageTables: 6592 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 5119432 kB
Committed_AS: 281420 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 349680 kB
VmallocChunk: 34359380816 kB
HardwareCorrupted: 0 kB
AnonHugePages: 157696 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6080 kB
DirectMap2M: 2091008 kB
DirectMap1G: 0 kB

从这个角度看可能更清楚一点，anon + file 占用的内存很多，active + inactive 加起来差不多 500 多 M 了，看来应该是 Python 程序里面操作的"文件"比较消耗内存？
Buffer2Disk
2018-10-11 21:30:47 +08:00
@MrGba2z 大佬帮忙分析下上面这个，我感觉 /proc/meminfo 看的更直观一些
Buffer2Disk
2018-10-11 21:31:27 +08:00
pmap -x 2473 | sort -nk 2 | grep anon
00007fb4c3fff000 4 0 0 ----- [ anon ]
00007fb4e17fc000 4 0 0 ----- [ anon ]
00007fb4e21fd000 4 0 0 ----- [ anon ]
00007fb4e2bfe000 4 0 0 ----- [ anon ]
00007fb4e35ff000 4 0 0 ----- [ anon ]
00007fb4fc3fa000 4 0 0 ----- [ anon ]
00007fb4fcdfb000 4 0 0 ----- [ anon ]
00007fb4fd7fc000 4 0 0 ----- [ anon ]
00007fb4fe1fd000 4 0 0 ----- [ anon ]
00007fb4febfe000 4 0 0 ----- [ anon ]
00007fb4ff5ff000 4 0 0 ----- [ anon ]
00007fb503fff000 4 0 0 ----- [ anon ]
00007fb504993000 4 0 0 ----- [ anon ]
00007fb505394000 4 0 0 ----- [ anon ]
00007fb507be5000 4 4 4 rw--- [ anon ]
00007fb50864f000 4 0 0 rw--- [ anon ]
00007fb511cc7000 4 4 4 rw--- [ anon ]
00007fff29bff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
00007fb507dfe000 8 4 4 rw--- [ anon ]
00007fb511cc3000 8 8 8 rw--- [ anon ]
00007fb509160000 16 16 16 rw--- [ anon ]
00007fb510e53000 16 16 16 rw--- [ anon ]
00007fb5116fb000 16 4 4 rw--- [ anon ]
00007fb511a97000 56 56 56 rw--- [ anon ]
00007fb4d4000000 132 36 36 rw--- [ anon ]
00007fb5063a5000 260 256 256 rw--- [ anon ]
00007fb506b45000 260 256 256 rw--- [ anon ]
00007fb511c38000 540 532 532 rw--- [ anon ]
00007fb4c8000000 584 144 144 rw--- [ anon ]
00007fb5048d2000 772 772 772 rw--- [ anon ]
00007fb4d8000000 856 552 552 rw--- [ anon ]
00007fb4dc000000 1020 776 776 rw--- [ anon ]
00007fb4f4000000 1028 1028 1028 rw--- [ anon ]
00007fb511b02000 1040 1024 1024 rw--- [ anon ]
00007fb4f8000000 1048 808 808 rw--- [ anon ]
00007fb4d0000000 1184 944 944 rw--- [ anon ]
00007fb4e4000000 1272 1040 1040 rw--- [ anon ]
00007fb5067ee000 1292 1284 1284 rw--- [ anon ]
00007fb4ec000000 1296 1296 1296 rw--- [ anon ]
00007fb4f0000000 1520 1284 1284 rw--- [ anon ]
00007fb4e8000000 1772 1544 1544 rw--- [ anon ]
0000000001476000 3216 3100 3100 rw--- [ anon ]
00007fb5040cb000 6148 6148 6148 rw--- [ anon ]
00007fb4e0efa000 9224 9224 9224 rw--- [ anon ]
00007fb4e17fd000 10240 20 20 rw--- [ anon ]
00007fb4e21fe000 10240 20 20 rw--- [ anon ]
00007fb4e2bff000 10240 20 20 rw--- [ anon ]
00007fb4e3600000 10240 2048 2048 rw--- [ anon ]
00007fb4fc3fb000 10240 20 20 rw--- [ anon ]
00007fb4fcdfc000 10240 20 20 rw--- [ anon ]
00007fb4fd7fd000 10240 20 20 rw--- [ anon ]
00007fb4fe1fe000 10240 20 20 rw--- [ anon ]
00007fb4febff000 10240 20 20 rw--- [ anon ]
00007fb4ff600000 10240 2048 2048 rw--- [ anon ]
00007fb504994000 10240 20 20 rw--- [ anon ]
00007fb505395000 10240 48 48 rw--- [ anon ]
00007fb4c4000000 19984 19024 19024 rw--- [ anon ]
00007fb4c5384000 45552 0 0 ----- [ anon ]
00007fb4e81bb000 63764 0 0 ----- [ anon ]
00007fb4f017c000 64016 0 0 ----- [ anon ]
00007fb4ec144000 64240 0 0 ----- [ anon ]
00007fb4e413e000 64264 0 0 ----- [ anon ]
00007fb4d0128000 64352 0 0 ----- [ anon ]
00007fb4f8106000 64488 0 0 ----- [ anon ]
00007fb4f4101000 64508 0 0 ----- [ anon ]
00007fb4dc0ff000 64516 0 0 ----- [ anon ]
00007fb4d80d6000 64680 0 0 ----- [ anon ]
00007fb4c8092000 64952 0 0 ----- [ anon ]
00007fb4d4021000 65404 0 0 ----- [ anon ]
00007fb4c0000000 65532 65532 65532 rw--- [ anon ]
00007fb500000000 65532 65532 65532 rw--- [ anon ]

这个是 Python 进程的内存使用情况(anon)
redsonic
2018-10-12 00:07:40 +08:00
anon 比较高没什么可说，毕竟没看代码。但 Slab 也很高啊，这个一般是内核用，比如驱动之类的。或者你的程序非常频繁申请 /注销大小差异极大的内存（造成碎片），频繁访问几十万个目录，比如一些语音文字分析程序。 可以用 slabtop 看看谁占用大头，至少可以排除掉内核的因素。
Buffer2Disk
2018-10-14 00:29:27 +08:00
@redsonic
我看了下 /proc/meminfo , 感觉 Slab + AnonPages + python 进程的 RES 内存 = 系统的真实使用内存，不知道这么算对不对？

下面是 slabtop 的结果，dentry 不知道是干啥用的
<img src=" " />
redsonic
2018-10-14 03:09:41 +08:00
@Buffer2Disk 之前看过内存管理部分的代码，差不多 buf+cache+active+slab 就是物理用量，有差的部分是 DMA 保留区，I/O 占用，还有静态库。

dentry 比较多的话说明打开的文件 /目录多，可以参考这个 https://yq.aliyun.com/articles/131870
Buffer2Disk
2018-10-14 11:59:47 +08:00
@redsonic 你好，你说的 active 是指哪个 active，因为之前有看过一篇文章 Active = Active(anon) + Active(file)
而 buffers + cached = Active(file) + Inactive(file) + Shmem，这样算的话，是不是和你那个公式里面 buffer+cache 算重复了？
文章来源： https://lujun9972.github.io/blog/2018/04/17/meminfo%E6%96%87%E4%BB%B6%E8%AF%A6%E8%A7%A3/
Buffer2Disk
2018-10-14 12:10:03 +08:00
@redsonic 还有一个问题，我这个 Python 多线程的程序打开的文件确实很多(fd),但是上个月的时候没有占用这么多内存，系统实际占用内存大概 600M，不知道为什么这个月就突增到 1.2G 了，fd 增长应该没有这么快，所以有点奇怪；
感觉应该是是 fd 占用内存最多了；

看前面的回复说，anon 和多线程有关系，我的程序里面是有 13 个线程常驻的，除了主线程外，其他的线程都是轮询从 MySQL 拿数据，然后操作 fd，之前好像也没这么消耗内存啊。。。。
redsonic
2018-10-14 12:44:27 +08:00
@Buffer2Disk 是的，active 包含 anon 和 file 的部分。 印象中 buf 是 block io 占用的，就是读写磁盘的裸数据缓存，属于内核设施。Active(file) 和 Inactive(file)是进程相关的，应该没有关系。可以扒扒代码 fs/proc/meminfo.c，顺藤摸瓜。之前自己也扒过 committed_as 找泄漏, 如果我讲错请回复.
redsonic
2018-10-14 12:49:16 +08:00
@Buffer2Disk 你 fd 的数据库文件很多吗？多的话可以试试预先把零碎库表写入一个文件中。以前见过类似优化的。 还有像 iOS 就把自带应用的 dyly 动态库文件合并成一个大文件，减小内存占用和访问时间。
Buffer2Disk
2018-11-16 11:25:39 +08:00
@MrGba2z @redsonic
花了一个多月排查，过程有点艰辛，不过总算有点成果
首先是换了 centos7 的系统，启用了 tcmaloc,然后解决了代码里面一些存在内存泄漏的地方，内存增长终于可以保持较稳定的状态
不过接下来碰到一个诡异的问题，内存总是在以 4kb 的速度不断往上缓慢增长，起先我以为是 python 的官方库 ordeedDict 问题 ，因为有些文章里面提到过 ordeedDict 的实现存在循环引用的情况，在 del 的时候会产生一个 self-refering list

不过后来发现好像不是这个原因 ，去掉了 tcmalloc，export MALLOC_ARENA_MAX=1 后，好像这个诡异的内存不断增长问题就消失了

使用的工具包括 objgraph 和 gc，pympler 等
参考教程 http://blog.soliloquize.org/2017/10/01/Python%E4%BB%A3%E7%A0%81%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F%E5%88%86%E6%9E%90%E7%BB%AD/
Buffer2Disk
2018-11-19 16:57:38 +08:00
今天从 tcmalloc 换了 jemalloc，好像效果更好了，听说 jemalloc 处理内存碎片方面更有优势（ tcmalloc 在线程频繁创建和销毁的场景下更有优势，但是我的业务系统线程数恒定）
看来可能是 python EventLoop 不断创建对象，销毁对象 造成了大量的内存碎片，然后 glibc 默认的 ptmalloc 处理内存碎片不够好造成的？

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/496498

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX