[PYTHON] numpy에 대한 메모리 프로파일 러

numpy에 대한 메모리 프로파일 러

내가 맨 위에 따르면 약 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만을 차지합니다 (대량 메모리는 대량 인쇄 배열에 의해 거의 확실히 사용됩니다).

heapy 나 내가 시도해야하는 다른 도구 (이 스레드에서 이미 언급 된 것 이외의)를 잘못 처리 한 것에 대한 제안은 무엇입니까?

해결법

1. ==============================

   1.Numpy와 라이브러리 바인딩은 C malloc을 사용하여 공간을 할당하기 때문에 엄청난 양의 할당으로 사용되는 메모리는 heapy와 같은 것들의 프로파일 링에 나타나지 않고 결코 쓰레기로 정리되지 않습니다. 수집기.

   Numpy와 라이브러리 바인딩은 C malloc을 사용하여 공간을 할당하기 때문에 엄청난 양의 할당으로 사용되는 메모리는 heapy와 같은 것들의 프로파일 링에 나타나지 않고 결코 쓰레기로 정리되지 않습니다. 수집기.

   큰 누출에 대한 일반적인 용의자는 실제로 파이썬 코드 자체가 아니라 불쾌하거나 매끄러운 라이브러리 바인딩입니다. 작년에 scipy.linalg 인터페이스에 의해 심하게 화상을 입었습니다. umfpack 인터페이스는 약 10Mb의 속도로 메모리를 유출했습니다. 코드를 프로파일 링하기 위해 valgrind와 같은 것을 시도 할 수 있습니다. 종종 누수가있는 곳을 어디에서 볼지에 대한 힌트를 줄 수 있습니다.

from https://stackoverflow.com/questions/6018986/memory-profiler-for-numpy by cc-by-sa and MIT license