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です。そして、ねじれたマンホールから guppy を使用して、メモリ使用プロファイルを監視します。

>>> 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 プロセスがさらに 10 MB ほど大きくなるのを見てきました。 http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rstを参照してください)。

しかし、あなたの場合、ヒーピーが追跡しない方法でメモリをリークまたは使用するCライブラリを使用していることが問題であると思われます。Heapy は Python オブジェクトが直接使用するメモリを認識していますが、それらのオブジェクトが個別に割り当てられた C オブジェクトをラップしている場合、heapy は通常、そのメモリをまったく認識しません。バインディングに大量のサポートを追加できる場合があります (ただし、使用するバインディングを制御しない場合は明らかに面倒です。また、バインディングを制御したとしても、ラップする内容によってはこれを行うことができない場合があります)。 ）。

C レベルでリークがある場合、heapy もそのメモリを追跡できなくなります (RSS サイズは増加しますが、heapy のレポート サイズは変わりません)。Valgrind は、他の C アプリケーションと同様に、おそらくこれらを追跡するための最善の策です。

最後に: メモリの断片化により、メモリ使用量 (上に示されているように) が増加することがよくありますが、減少することはありません (あまり)。プロセスはこのメモリを再利用し、OS に解放されず、top の値は元に戻りません。メモリ使用量 (top で見られるように) がユーザー (接続) の数に応じて多かれ少なかれ直線的に上昇し、元に戻らず、ユーザーの新しい最大数に達するまで永遠に増加し続けない場合、断片化はおそらく責める。

于 2010-01-29T18:42:24.860 に答える
0

これは完全な答えではありませんが、マンホールから、psまたはtopで調べる前にgc.collect（）を手動で実行することもお勧めします。guppyは割り当てられたヒープを表示しますが、割り当てられなくなったオブジェクトをプロアクティブに解放するために何もしません。

于 2011-10-11T20:06:21.380 に答える