20

numpy-- によるとtop-- 約 5 GB の RAM を使用しているスクリプトがあります。

  PID USER   PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16994 aix    25   0 5813m 5.2g 5.1g S  0.0 22.1  52:19.66 ipython

そのメモリの大部分を使用しているオブジェクトについてのアイデアを得ることができるメモリ プロファイラーはありますか?

私は試しましheapyたguppy.hpy().heap()が、私にこれを与えています:

Partition of a set of 90956 objects. Total size = 12511160 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  42464  47  4853112  39   4853112  39 str
     1  22147  24  1928768  15   6781880  54 tuple
     2    287   0  1093352   9   7875232  63 dict of module
     3   5734   6   733952   6   8609184  69 types.CodeType
     4    498   1   713904   6   9323088  75 dict (no owner)
     5   5431   6   651720   5   9974808  80 function
     6    489   1   512856   4  10487664  84 dict of type
     7    489   1   437704   3  10925368  87 type
     8    261   0   281208   2  11206576  90 dict of class
     9   1629   2   130320   1  11336896  91 __builtin__.wrapper_descriptor
<285 more rows. Type e.g. '_.more' to view.>

何らかの理由で、5GB のうち 12MB しか占めていません (メモリの大部分はほぼ確実にnumpy配列によって使用されます)。

私が間違っている可能性があること、または他のどのツールを試す必要があるかについての提案はありますか(このスレッドheapyで既に言及されているもの以外)?

4

1 に答える 1

11

Numpy (およびそのライブラリ バインディングについては、後で詳しく説明します) は、C の malloc を使用してスペースを割り当てます。これが、大きな numpy 割り当てによって使用されるメモリが heapy などのプロファイリングに表示されず、ガベージによってクリーンアップされることがない理由です。コレクタ。

大規模なリークの通常の容疑者は、実際には Python コード自体ではなく、scipy または numpy ライブラリ バインディングです。私は昨年、umfpack へのデフォルトの scipy.linalg インターフェイスによってひどい火傷を負いました。このインターフェイスは、1 回の呼び出しで約 10Mb の割合でメモリ リークを起こしました。コードをプロファイリングするために valgrind のようなものを試してみてください。多くの場合、リークがある可能性のある場所をどこで確認すればよいかについて、いくつかのヒントが得られます。

于 2011-05-16T14:45:26.767 に答える