【问题标题】:Memory profiler for numpynumpy 的内存分析器
【发布时间】:2011-05-16 14:37:24
【问题描述】:

我有一个 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

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

我试过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 可能做错了什么或我应该尝试哪些其他工具(this thread 中已经提到的那些除外)有什么建议吗?

【问题讨论】:

    标签: python memory numpy memory-profiling


    【解决方案1】:

    Numpy(及其库绑定,稍后会详细介绍)使用 C malloc 分配空间,这就是为什么大型 numpy 分配使用的内存不会出现在 heapy 之类的分析中并且永远不会被清理的原因由垃圾收集器。

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

    【讨论】:

    • 是的,但在某些情况下,最好知道 numpy/scipy 数组的大小,例如,在调试您自己的 150,000 个应用程序中的内存泄漏时,您正在传递和复制左右数组,您知道问题出在您自己的代码中。如果 pympler 等可以只使用 array.nbytes 属性来提供有意义的结果,那就太好了。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-23
    • 2010-09-15
    • 2010-11-26
    • 1970-01-01
    • 2011-03-28
    相关资源
    最近更新 更多