guppy报告的内存使用情况与ps命令不同。

Question

我在分析我扭曲的服务器。它使用的内存比我预期的要多得多。它的内存使用量随着时间的推移而增加。

 ps -o pid,rss,vsz,sz,size,command
  PID   RSS    VSZ    SZ    SZ COMMAND
 7697 70856 102176 25544 88320 twistd -y broadcast.tac

正如你所看到的，它的成本为102176 KBs，即99.78125 MBs。我用扭曲的井筒里的古皮来观察内存使用情况。

>>> hp.heap()
Partition of a set of 120537 objects. Total size = 10096636 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  61145  51  5309736  53   5309736  53 str
     1  27139  23  1031596  10   6341332  63 tuple
     2   2138   2   541328   5   6882660  68 dict (no owner)
     3   7190   6   488920   5   7371580  73 types.CodeType
     4    325   0   436264   4   7807844  77 dict of module
     5   7272   6   407232   4   8215076  81 function
     6    574   0   305776   3   8520852  84 dict of class
     7    605   1   263432   3   8784284  87 type
     8    602   0   237200   2   9021484  89 dict of type
     9    303   0   157560   2   9179044  91 dict of zope.interface.interface.Method
<384 more rows. Type e.g. '_.more' to view.>

哼..。好像出了什么问题。古皮显示，内存的总使用量为10096636字节，即9859.996 KBs或9.628 MBs。

这是一个巨大的差异。这个奇怪的结果怎么了？我做错了什么？

更新：我昨晚写了一个监视器脚本。它记录内存的使用情况和在线用户的数量。这是一个无线电服务器，所以你可以看到有收音机和总听众。下面是matplotlib生成的图。

​

有些事很奇怪。有时候，ps打印的内存使用量非常低，如下所示

2010-01-15 00:46:05,139 INFO 4 4 17904 36732 9183 25944
2010-01-15 00:47:03,967 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:48:04,373 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:49:04,379 INFO 4 4 17916 36732 9183 25944
2010-01-15 00:50:02,989 INFO 4 4 3700 5256 1314 2260

内存使用率极低的原因是什么？更重要的是，即使没有在线收音机，也没有听众，内存使用率仍然很高。

Answer 1

可能是由于交换/内存预留，根据ps的定义：

RSS: resident set size, the non-swapped physical memory
     that a task has used (in kiloBytes).

VSZ: virtual memory usage of entire process.
     vm_lib + vm_exe + vm_data + vm_stack

这可能有点令人困惑，4种不同的大小度量可以通过以下方式看到：

# ps -eo pid,vsz,rss,sz,size,cmd|egrep python

PID    VSZ   RSS   SZ    SZ    CMD
23801  4920  2896  1230  1100  python

虚拟大小包括进程保留且未使用的内存、已加载的所有共享库的大小、已交换的页以及已被进程释放的块，因此它可能比python中所有活动对象的大小大得多。

一些用于调查内存性能的其他工具：

http://guppy-pe.sourceforge.net/

• Python

• Heapy(您正在使用的
• Heapy的一部分)：内存验证器http://www.softwareverify.com/python/memory/index.html
  • PySizer http://pysizer.8325.org/

使用pdb和objgraph跟踪python中内存泄漏的良好指南：

http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks

Answer 2

正如上面所指出的，RSS大小是您最感兴趣的。“虚拟”大小包括映射库，您可能不想计算这些库。

自从我使用heapy以来已经有一段时间了，但是我确信它打印的统计信息不包括heapy本身添加的开销。这种开销可能相当大(我已经看到一个100 MB的RSS进程又增长了十几MB，参见http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst )。

但在您的情况下，我怀疑问题在于您使用的是某个C库，它以heapy不跟踪的方式泄漏或使用内存。Heapy知道python对象直接使用的内存，但是如果这些对象包装了C对象，单独分配的对象heapy通常根本不知道内存。您可能可以将heapy支持添加到绑定中(但如果您不控制使用的绑定，这显然是一个麻烦，而且即使您控制了绑定，也可能无法做到这一点，这取决于您包装的内容)。

如果C级出现泄漏，heapy也会丢失该内存(RSS大小将增加，但heapy的报告大小将保持不变)。与其他C应用程序中的情况一样，瓦伦可能也是你追踪这些信息的最佳选择。

最后:内存碎片通常会导致您的内存使用量(如顶部所示)上升，但不会下降(很多)。对于守护进程来说，这通常不是什么大问题，因为进程将重用这个内存，它只是没有被释放回os，所以顶部的值不会下降。如果内存使用量(如顶部所示)与用户(连接)的数量大致呈线性增长，不会下降，但在达到新的最大用户数之前也不会永远增长，那么碎片可能是罪魁祸首。

Answer 3

这不是一个完整的答案，但从您的井口来看，我还建议在使用ps或top之前手动运行gc.collect()。guppy将显示已分配的堆，但不会对不再分配的主动释放对象做任何事情。