numpy的内存分析器

NPE*_*NPE 19 python memory numpy memory-profiling

我有一个numpy脚本 - 根据top- 使用大约5GB的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
Run Code Online (Sandbox Code Playgroud)

是否有内存分析器可以让我了解占用大部分内存的对象?

我试过了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.>
Run Code Online (Sandbox Code Playgroud)

出于某种原因,它只占了5GB的12MB(大部分内存几乎肯定被numpy阵列使用).

关于我可能做错了heapy什么或者我应该尝试什么其他工具的任何建议(除了在这个线程中已经提到的那些)?

tal*_*ies 10

Numpy(和它的库绑定,更多关于它的一分钟)使用C malloc来分配空间,这就是为什么大numpy分配使用的内存不会出现在像heapy这样的东西的分析中,并且永远不会被垃圾清理掉集电极.

通常的大泄漏嫌疑人实际上是scipy或numpy库绑定,而不是python代码本身.去年我被umfpack的默认scipy.linalg接口严重烧毁,它以大约10Mb的速率泄漏内存.您可能想尝试使用valgrind来分析代码.它通常可以提供一些关于在哪里查看可能存在泄漏的提示.