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

У меня есть скрипт 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 или какие другие инструменты я должен попробовать (кроме уже упомянутых в эту тему)?


python numpy memory memory-profiling
person NPE    schedule 16.05.2011    source источник

Ответы (1)


arrow_upward
11
arrow_downward

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

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

person talonmies    schedule 16.05.2011
comment
Да, но все еще есть случаи, когда было бы неплохо знать размер массивов numpy/scipy, например, при отладке утечек памяти в вашем собственном 150 000 приложении, где вы передаете и копируете массивы влево и вправо, и вы знаете проблема в вашем собственном коде. Было бы неплохо, если бы pympler и т. д. могли просто использовать атрибут array.nbytes для получения значимых результатов. - person partofthething; 06.02.2016