Профилировщик памяти для numpy - PullRequest
Новая
       32

Профилировщик памяти для numpy

19 голосов
/ 16 мая 2011

У меня есть сценарий numpy, который - согласно top - использует около 5 ГБ ОЗУ: 

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

По какой-то причине он составляет только 12 МБ из 5 ГБ (большая часть памяти почти наверняка используется numpy массивами).

Любые предложения относительно того, что я могу делать неправильно с heapy или какие другие инструменты мне следует попробовать (кроме тех, которые уже упомянуты в этой теме )?

1 Ответ

10 голосов
/ 16 мая 2011

Numpy (и его привязки к библиотекам, подробнее об этом через минуту) используют C malloc для выделения пространства, поэтому память, используемая большими распределенными распределениями, не отображается при профилировании таких вещей, как heapy, и никогда не очищается у сборщика мусора.

Обычные подозрения на большие утечки - это на самом деле скучные или клочковатые привязки к библиотекам, а не сам код Python. В прошлом году я сильно обгорел из-за интерфейса scipy.linalg по умолчанию для umfpack, который пропускал память со скоростью около 10 Мб на звонок. Возможно, вы захотите попробовать что-то вроде valgrind для профилирования кода. Часто он может дать некоторые подсказки о том, где искать утечки.

...