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来分析代码.它通常可以提供一些关于在哪里查看可能存在泄漏的提示.
| 归档时间: |
|
| 查看次数: |
1876 次 |
| 最近记录: |