由guppy報告的內存使用情況與ps命令不同

我正在分析我的扭曲服務器。它使用的內存比我預期的要多得多。內存使用量隨着時間的推移而增長。由guppy報告的內存使用情況與ps命令不同

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生成的圖。 alt text http://static.ez2learn.com/temp/mem_figure.svg

有些奇怪。有時由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

內存使用量超低的原因是什麼？而且，即使沒有在線收音機，沒有聽衆，內存使用率仍然很高。

來源

2010-01-14 Fang-Pen Lin

可能由於交換/內存預留，基於PS的定義：

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

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

虛擬尺寸：

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度不同尺寸的度量可以與可見包括由進程保留並未使用的內存，已加載的所有共享庫的大小，已換出的頁面以及已由進程釋放的塊，因此它可能大於所有活動的大小python中的對象。

一些額外的工具來探討內存性能：

Heapy（顧比的一部分，您正在使用）： http://guppy-pe.sourceforge.net/
Python的內存驗證 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

來源

2010-01-14 18:07:43 jspcal

但即使我比較69 MB與10MB，它是太過分了。可能是什麼問題呢？而且，內存使用量隨着時間而增長。起初，RSS大約是2MB，現在是6x。 – 2010-01-14 18:10:17

一些由孔雀魚報告的物體，否則會被交換出去，以便蟒蛇可能會報告的，而RSS將不包括它..即時通訊不知道爲什麼過程中保留這麼多的內存壽，也許噸共享庫的..？ – jspcal 2010-01-14 18:15:54

所有庫在啓動時加載。服務器啓動時，它在RSS字段中僅使用2個MB。圖書館佔用額外的內存使用量是沒有意義的。有沒有什麼辦法知道那些看不見的內存使用情況？ – 2010-01-14 18:42:53

正如指出的上述RSS大小是你最感興趣的是在這裏。「虛擬」大小包括映射的庫，您可能不想計數。

它已經，因爲我用heapy一段時間，但我敢肯定的統計數據也打印不通過heapy本身包括開銷增加。這種開銷可能非常顯着（我已經看到一個100MB的RSS過程增長了十幾個MB，見http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst）。

但在你的情況，我懷疑的問題是，你正在使用或者泄露或使用內存的方式，heapy不跟蹤某些C庫。 Heapy知道python對象直接使用的內存，但是如果這些對象包裝分開分配的C對象，那麼heapy通常不會意識到該內存。你可以添加heapy支持到你的綁定中（但是如果你不控制你使用的綁定顯然是一件麻煩事，即使你控制了綁定，你也可能無法做到這一點，這取決於你正在包裝什麼）。

如果有在C級heapy泄漏也將失去的軌道，內存（RSS規模就上去了，但heapy的報告的大小將保持不變）。 Valgrind可能是您追蹤這些數據的最佳選擇，就像在其他C應用程序中一樣。

最後：內存碎片往往會導致你的內存使用情況（如被看見在頂部）上去，但不下來（多）。這通常不是守護進程的問題，因爲進程將重用這個內存，它不會被釋放回os，所以頂端的值不會回落。如果內存使用量（如上圖所示）與用戶數（連接數）呈線性關係，則不會降低，但也不會一直持續增長，直到達到新的最大用戶數時，可能會導致碎片化惹的禍。

來源

2010-01-29 18:42:24 mzz

這不是一個完整的答案，但是從你的沙井，我也建議手動運行GC.Collect的（）用ps或頂部看之前。 guppy將顯示已分配的堆，但不會執行任何操作來主動釋放不再分配的對象。

來源

2011-10-11 20:06:21

由guppy報告的內存使用情況與ps命令不同

回答

相關問題