8

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

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

如您所见，它的成本为 102176 KB，即99.78125 MB。我使用来自扭曲沙井的孔雀鱼来观察内存使用情况。

>>> 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.>

哼……好像有什么不对。Guppy 显示内存的总使用量为 10096636 字节，即9859.996 KB或9.628 MB。

这是一个巨大的差异。这个奇怪的结果有什么问题？我究竟做错了什么？

更新： 我昨晚写了一个监控脚本。它记录了内存使用情况和在线用户数。它是一个广播服务器，因此您可以看到有广播和总听众。这是我用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

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

4

3 回答 3

6

可能是由于交换/内存保留，基于 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 中的所有活动对象。

一些额外的工具来调查内存性能：

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

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

于 2010-01-14T18:07:43.550 回答
3

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

自从我使用 heapy 已经有一段时间了，但我很确定它打印的统计数据不包括 heapy 本身增加的开销。这种开销可能相当大（我已经看到一个 100MB 的 RSS 进程又增长了十几个 MB，请参阅http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst）。

但是在您的情况下，我怀疑问题在于您正在使用一些 C 库，该库要么泄漏，要么以 heapy 无法跟踪的方式使用内存。Heapy 知道 python 对象直接使用的内存，但如果这些对象包装了单独分配的 C 对象，heapy 通常根本不知道该内存。您可能能够为您的绑定添加大量支持（但如果您不控制所使用的绑定，这显然是一件麻烦事，即使您确实控制了绑定，您也可能无法做到这一点，具体取决于您包装的内容）。

如果 C 级别存在泄漏，heapy 也会失去对该内存的跟踪（RSS 大小会增加，但 heapy 报告的大小将保持不变）。Valgrind 可能是追踪这些的最佳选择，就像在其他 C 应用程序中一样。

最后：内存碎片通常会导致您的内存使用量（如上图所示）上升但不会下降（很多）。对于守护进程，这通常不是什么大问题，因为进程将重用此内存，它只是没有释放回操作系统，因此顶部的值不会下降。如果内存使用量（如上图所示）与用户数（连接数）或多或少呈线性增长，不会回落，但也不会永远增长，直到达到新的最大用户数，碎片可能是惹的祸。

于 2010-01-29T18:42:24.860 回答
0

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

于 2011-10-11T20:06:21.380 回答