python 脚本的 pmap 高内存使用率
pmap high memory usage by python script
我有一个 python 脚本基础守护进程(在网络上侦听客户端连接),它使用大量内存,差不多 23G。以下是我的 pmap 输出:
[root@example ~]# pmap -x 9766 | grep anon
0000000001f64000 31140 31140 31140 rw--- [ anon ]
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
000000308d875000 16 12 12 rw--- [ anon ]
000000308e409000 184 0 0 rw--- [ anon ]
0000003659a18000 8 0 0 rw--- [ anon ]
0000003989021000 4 4 4 rw--- [ anon ]
000000398998f000 20 16 16 rw--- [ anon ]
0000003989c19000 16 4 4 rw--- [ anon ]
000000398d017000 8 0 0 rw--- [ anon ]
0000003e49c1e000 4 4 4 rw--- [ anon ]
0000003e4a1df000 16 16 16 rw--- [ anon ]
0000003e4a585000 8 0 0 rw--- [ anon ]
0000003e4d02b000 4 0 0 rw--- [ anon ]
00007fc7d8000000 132 8 8 rw--- [ anon ]
00007fc7d8021000 65404 0 0 ----- [ anon ]
00007fc7e0000000 132 8 8 rw--- [ anon ]
00007fc7e0021000 65404 0 0 ----- [ anon ]
00007fc7e6bfe000 4 0 0 ----- [ anon ]
00007fc7e6bff000 10240 12 12 rw--- [ anon ]
00007fc7e75ff000 4 0 0 ----- [ anon ]
00007fc7e7600000 10240 2048 2048 rw--- [ anon ]
00007fc7e8000000 132 8 8 rw--- [ anon ]
00007fc7e8021000 65404 0 0 ----- [ anon ]
00007fc7ec000000 132 8 8 rw--- [ anon ]
00007fc7ec021000 65404 0 0 ----- [ anon ]
00007fc7f0000000 132 8 8 rw--- [ anon ]
00007fc7f0021000 65404 0 0 ----- [ anon ]
00007fc7f4179000 3076 3076 3076 rw--- [ anon ]
00007fc7f44b8000 1452 1440 1440 rw--- [ anon ]
00007fc7f466a000 908 884 884 rw--- [ anon ]
00007fc7f47f1000 4 0 0 ----- [ anon ]
00007fc7f47f2000 10240 12 12 rw--- [ anon ]
00007fc7f51f2000 4 0 0 ----- [ anon ]
00007fc7f51f3000 10240 12 12 rw--- [ anon ]
00007fc7f5bf3000 4 0 0 ----- [ anon ]
00007fc7f5bf4000 10240 12 12 rw--- [ anon ]
00007fc7f8503000 260 256 256 rw--- [ anon ]
00007fc7f8b56000 520 512 512 rw--- [ anon ]
00007fc7f8ddb000 260 256 256 rw--- [ anon ]
00007fc7f903d000 260 256 256 rw--- [ anon ]
00007fc7f9495000 520 512 512 rw--- [ anon ]
00007fc7f972c000 1292 1284 1284 rw--- [ anon ]
00007fc7fa08f000 260 256 256 rw--- [ anon ]
00007fc7fa4d9000 260 256 256 rw--- [ anon ]
00007fc7fb360000 260 256 256 rw--- [ anon ]
00007fc7fbfd6000 260 256 256 rw--- [ anon ]
00007fc801ea8000 520 512 512 rw--- [ anon ]
00007fc801f5c000 540 532 532 rw--- [ anon ]
00007fc8023ae000 60 60 60 rw--- [ anon ]
00007fc8023c5000 4 4 4 rw--- [ anon ]
00007fc8023c6000 4 4 4 rwx-- [ anon ]
00007fc8023c7000 4 4 4 rw--- [ anon ]
00007fffd45ff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
我注意到它在增长,感谢我的系统有 64G 内存,所以它仍然存在,但我担心一旦达到最大值就会崩溃。
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
以上输出看起来正常吗?我不是专家,但我需要建议才能知道发生了什么,我该如何清理肮脏的记忆?
以下内存使用情况:
[root@example ~]# free -m
total used free shared buffers cached
Mem: 64389 46304 18085 22 242 12892
-/+ buffers/cache: 33170 31219
Swap: 1027 0 1027
看起来你的大部分用法都在这里:
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
这可能是 Python 运行-time 的堆。在这种情况下,不可能通过查看 pmap 输出来猜测其中的内容。
我建议您将 gdb 调试器附加到此进程。这使您可以直接访问进程内存,并将该段转储到文件以进行检查。
首先你需要找到内存偏移的开始和结束(据我所知,pmap 没有给你)。您可以为此过程转储 smaps:
cat /procs/9766/smaps
找到从0000000003dcd000开始的对应区块。应该是这样的:
03dcd000 -070be000 rw-p 00000000 00:00 0
Size: 60 kB
Rss: 60 kB
Pss: 51 kB
Shared_Clean: 0 kB
Shared_Dirty: 12 kB
Private_Clean: 0 kB
Private_Dirty: 48 kB
Referenced: 60 kB
Anonymous: 60 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
这里数据段的start/end为0x03dcd000 / 0x070be000
附加调试器:
gdb -p 9766
然后将这段内存转储到一个文件中:
dump binary memory /root/swap_problem_raw 0x03dcd000 0x070be000
然后您可以在十六进制编辑器中查看此文件以了解发生了什么。它应该会给你一个线索,传递的是什么类型的数据 if/when 它是明文。我目前使用 vim 并且工作正常。
/proc/$id/smaps 的摘要信息可以在 proc 手册页中找到。
我有一个 python 脚本基础守护进程(在网络上侦听客户端连接),它使用大量内存,差不多 23G。以下是我的 pmap 输出:
[root@example ~]# pmap -x 9766 | grep anon
0000000001f64000 31140 31140 31140 rw--- [ anon ]
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
000000308d875000 16 12 12 rw--- [ anon ]
000000308e409000 184 0 0 rw--- [ anon ]
0000003659a18000 8 0 0 rw--- [ anon ]
0000003989021000 4 4 4 rw--- [ anon ]
000000398998f000 20 16 16 rw--- [ anon ]
0000003989c19000 16 4 4 rw--- [ anon ]
000000398d017000 8 0 0 rw--- [ anon ]
0000003e49c1e000 4 4 4 rw--- [ anon ]
0000003e4a1df000 16 16 16 rw--- [ anon ]
0000003e4a585000 8 0 0 rw--- [ anon ]
0000003e4d02b000 4 0 0 rw--- [ anon ]
00007fc7d8000000 132 8 8 rw--- [ anon ]
00007fc7d8021000 65404 0 0 ----- [ anon ]
00007fc7e0000000 132 8 8 rw--- [ anon ]
00007fc7e0021000 65404 0 0 ----- [ anon ]
00007fc7e6bfe000 4 0 0 ----- [ anon ]
00007fc7e6bff000 10240 12 12 rw--- [ anon ]
00007fc7e75ff000 4 0 0 ----- [ anon ]
00007fc7e7600000 10240 2048 2048 rw--- [ anon ]
00007fc7e8000000 132 8 8 rw--- [ anon ]
00007fc7e8021000 65404 0 0 ----- [ anon ]
00007fc7ec000000 132 8 8 rw--- [ anon ]
00007fc7ec021000 65404 0 0 ----- [ anon ]
00007fc7f0000000 132 8 8 rw--- [ anon ]
00007fc7f0021000 65404 0 0 ----- [ anon ]
00007fc7f4179000 3076 3076 3076 rw--- [ anon ]
00007fc7f44b8000 1452 1440 1440 rw--- [ anon ]
00007fc7f466a000 908 884 884 rw--- [ anon ]
00007fc7f47f1000 4 0 0 ----- [ anon ]
00007fc7f47f2000 10240 12 12 rw--- [ anon ]
00007fc7f51f2000 4 0 0 ----- [ anon ]
00007fc7f51f3000 10240 12 12 rw--- [ anon ]
00007fc7f5bf3000 4 0 0 ----- [ anon ]
00007fc7f5bf4000 10240 12 12 rw--- [ anon ]
00007fc7f8503000 260 256 256 rw--- [ anon ]
00007fc7f8b56000 520 512 512 rw--- [ anon ]
00007fc7f8ddb000 260 256 256 rw--- [ anon ]
00007fc7f903d000 260 256 256 rw--- [ anon ]
00007fc7f9495000 520 512 512 rw--- [ anon ]
00007fc7f972c000 1292 1284 1284 rw--- [ anon ]
00007fc7fa08f000 260 256 256 rw--- [ anon ]
00007fc7fa4d9000 260 256 256 rw--- [ anon ]
00007fc7fb360000 260 256 256 rw--- [ anon ]
00007fc7fbfd6000 260 256 256 rw--- [ anon ]
00007fc801ea8000 520 512 512 rw--- [ anon ]
00007fc801f5c000 540 532 532 rw--- [ anon ]
00007fc8023ae000 60 60 60 rw--- [ anon ]
00007fc8023c5000 4 4 4 rw--- [ anon ]
00007fc8023c6000 4 4 4 rwx-- [ anon ]
00007fc8023c7000 4 4 4 rw--- [ anon ]
00007fffd45ff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
我注意到它在增长,感谢我的系统有 64G 内存,所以它仍然存在,但我担心一旦达到最大值就会崩溃。
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
以上输出看起来正常吗?我不是专家,但我需要建议才能知道发生了什么,我该如何清理肮脏的记忆?
以下内存使用情况:
[root@example ~]# free -m
total used free shared buffers cached
Mem: 64389 46304 18085 22 242 12892
-/+ buffers/cache: 33170 31219
Swap: 1027 0 1027
看起来你的大部分用法都在这里:
0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]
这可能是 Python 运行-time 的堆。在这种情况下,不可能通过查看 pmap 输出来猜测其中的内容。
我建议您将 gdb 调试器附加到此进程。这使您可以直接访问进程内存,并将该段转储到文件以进行检查。
首先你需要找到内存偏移的开始和结束(据我所知,pmap 没有给你)。您可以为此过程转储 smaps:
cat /procs/9766/smaps
找到从0000000003dcd000开始的对应区块。应该是这样的:
03dcd000 -070be000 rw-p 00000000 00:00 0
Size: 60 kB
Rss: 60 kB
Pss: 51 kB
Shared_Clean: 0 kB
Shared_Dirty: 12 kB
Private_Clean: 0 kB
Private_Dirty: 48 kB
Referenced: 60 kB
Anonymous: 60 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
这里数据段的start/end为0x03dcd000 / 0x070be000
附加调试器:
gdb -p 9766
然后将这段内存转储到一个文件中:
dump binary memory /root/swap_problem_raw 0x03dcd000 0x070be000
然后您可以在十六进制编辑器中查看此文件以了解发生了什么。它应该会给你一个线索,传递的是什么类型的数据 if/when 它是明文。我目前使用 vim 并且工作正常。
/proc/$id/smaps 的摘要信息可以在 proc 手册页中找到。