【问题标题】:pmap high memory usage by python scriptpython脚本的pmap高内存使用率
【发布时间】:2015-06-03 14:07:37
【问题描述】:

我有一个 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

【问题讨论】:

    标签: linux memory memory-management memory-leaks pmap


    【解决方案1】:

    看起来你的大部分用法都在这里:

    0000000003dcd000 24265388 24265220 24265220 rw--- [ anon ]

    这很可能是 Python 运行时的堆。在这种情况下,通过查看 pmap 输出无法猜测其中的内容。

    我建议您将 gdb 调试器附加到此进程。这使您可以直接访问进程内存,并将该段转储到文件中进行检查。

    首先,您需要找到内存偏移的开始和结束(据我所知,pmap 并没有给您)。您可以为此转储进程的 smap:

    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

    这里数据段的开始/结束是0x03dcd000 / 0x070be000

    附加调试器:

    gdb -p 9766

    然后将此内存转储到文件中:

    dump binary memory /root/swap_problem_raw 0x03dcd000 0x070be000

    然后您可以在十六进制编辑器中查看此文件以了解发生了什么。如果/何时是明文,它应该有望为您提供线索。我目前使用 vim 并且工作正常。

    /proc/$id/smaps 的摘要信息可以在 proc 手册页中找到。

    【讨论】:

    • 我执行了dump binary memory 命令,但它创建了空文件。如果它拥有大量数据,这怎么可能。
    • 这是我在 smap 03860000-c7eb1000 rw-p 00000000 00:00 0 看到的最后一位数字 0 这意味着它是空的
    • 以下是这些数字的含义: 3860000-c7eb1000 :此段的进程地址偏移 rw-p :此段的权限(p 表示私有) 00000000 :文件偏移(此处没有) 00: 00:设备版本(这里没有) 0:设备上的inode 所以,大小是开始和结束之间的差异。您的偏移量可能已更改,您是否重新启动了该过程? (有关“proc”的详细信息,请参见您的手册页条目。)
    • 是的,我们确实会重新启动以防止出现“OOM”,我找到了新的 pid 并按照您的步骤操作,但每次该位置都是空的。
    • 好的,此时我会尝试各种方法。您可以尝试不同的文件路径,可以尝试转储另一个段,尝试使用其他调试器命令(例如信息线程)访问线程信息或其他杂项信息等内容。这是为了消除权限失败等可能性。听起来您的调试器无法访问那部分内存,因此是空文件。这可能是因为您正在执行此操作的用户没有访问其他进程内存空间的权限。但不可能对我说。你用的是root用户吗?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-07-02
    • 1970-01-01
    • 2014-02-24
    • 2019-07-29
    • 2014-01-29
    • 2011-09-19
    相关资源
    最近更新 更多