Python實現記憶體洩露排查的示例
導讀 | 一般在python程式碼塊的除錯過程中會使用memory-profiler、filprofiler、objgraph等三種方式進行輔助分析,今天這裡主要介紹使用objgraph物件提供的函式介面來進行記憶體洩露的分析,感興趣的可以瞭解一下 |
一般情況下只有需要長期執行的專案才會去關注記憶體的增長情況,即使是很小部分的記憶體洩露經過長期的執行仍然會產生很大的隱患。
python本身也是支援垃圾的自動回收的,但是在特定的情況下也是會出現記憶體洩露的問題的。
比如對於很多全域性的列表(list)/字典(dict)等物件在經過不斷的資料賦值而沒有進行手動回收,或者某些物件被不停的迴圈引用而不能及時的進行回收等都會產生記憶體洩露的情況。
一般在python程式碼塊的除錯過程中會使用memory-profiler、filprofiler、objgraph等三種方式進行輔助分析,今天這裡主要介紹使用objgraph物件提供的函式介面來進行記憶體洩露的分析。
objgraph是python的非標準模組,因此需要使用pip的方式安裝一下。
pip install objgraph
更多詳細的介紹可以訪問下面的官方地址進行檢視。
接下來就可以直接將objgraph匯入到我們的程式碼塊中進行使用了。
# Importing the objgraph module and renaming it to graph. import objgraph as graph
這裡初始化一組字典型別的資料物件。
dict_ = { '姓名': ['Python', 'Java', 'Scala'], '年齡': ['21', '22', '19'] }
透過objgraph.count()函式,可以統計出GC中的dict_物件的數目是多少。
# Counting the number of dict_ objects in the GC. print(graph.count(dict_))
和objgraph.count()函式對應的是可以使用by_type返回該物件在GC中的列表,若是GC返回的為空的列表說明已經被回收了。
# Returning a list of dict_ objects in the GC. print(graph.by_type(dict_))
在統計記憶體洩露時比較好用的函式就是graph.show_growth()函式,可以統計自上次呼叫以來增加得最多的物件。
# Showing the growth of objects in the memory since the last time it was called. print(graph.show_growth()) # function 3013 +3013 # tuple 1463 +1463 # dict 1417 +1417 # wrapper_descriptor 1178 +1178 # ReferenceType 883 +883 # method_descriptor 814 +814 # builtin_function_or_method 794 +794 # getset_descriptor 514 +514 # type 463 +463 # list 436 +436 # None
可以根據返回結果中的物件每次增加的數量來判斷記憶體洩露的相關情況。
還有一個比較常用的分析函式就是graph.show_most_common_types(),可以按照從大到小的方式列出物件例項比較多的情況。
# Showing the most common types of objects in the memory. print(graph.show_most_common_types()) # function 3013 # tuple 1463 # dict 1417 # wrapper_descriptor 1178 # ReferenceType 883 # method_descriptor 814 # builtin_function_or_method 794 # getset_descriptor 514 # type 463 # list 436 # None
最後一個比較使用函式就是show_backrefs函式,使用它可以分析出記憶體洩露的原因是什麼。
它會生成一張有關objs的引用圖,可以看出物件為什麼不釋放?只是呼叫該函式時的引數比較多,下面是該函式的介面。
# def show_backrefs(objs, max_depth=3, extra_ignore=(), filter=None, too_many=10, # highlight=None, filename=None, extra_info=None, # refcounts=False, shortnames=True, output=None, # extra_node_attrs=None):
我們還是和上面一樣使用dict_作為物件進行分析。
# Showing the back references of the dict_ object. graph.show_backrefs(dict_)
執行完成後dot型別的圖片已經生成了,發現出現了下面的錯誤,意思是沒有發現支援dot的影像元件。
# Graph written to C:\Users\86159\AppData\Local\Temp\objgraph-dkqm85f0.dot (4 nodes) # Graph viewer (xdot) and image renderer (dot) not found, not doing anything else
可以使用pip的方式分別安裝graphviz xdot,這兩個python的非標準模組。
pip install graphviz xdot
若是檢視.dot決策樹影像可以使用graphviz工具,可以到下面地址進行下載安裝。
安裝完成後配置環境變數,然後重啟開發工具(這裡使用的是pycharm)即可。
到此這篇關於Python實現記憶體洩露排查的示例詳解的文章就介紹到這了
原文來自:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2938190/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- nodejs爬蟲記憶體洩露排查NodeJS爬蟲記憶體洩露
- netty 堆外記憶體洩露排查盛宴Netty記憶體洩露
- 記一次"記憶體洩露"排查過程記憶體洩露
- 排查Java記憶體洩露實戰(內附各種排查工具介紹)Java記憶體洩露
- 一次Kafka記憶體洩露排查經過Kafka記憶體洩露
- 實戰Go記憶體洩露Go記憶體洩露
- 記一次尷尬的Java應用記憶體洩露排查Java記憶體洩露
- SHBrowseForFolder 記憶體洩露記憶體洩露
- 記憶體溢位和記憶體洩露記憶體溢位記憶體洩露
- Lowmemorykiller記憶體洩露分析記憶體洩露
- 分散式 | 令人頭疼的堆外記憶體洩露怎麼排查?分散式記憶體洩露
- ArkTS 的記憶體快照與記憶體洩露除錯記憶體洩露除錯
- 使用 mtrace 分析 “記憶體洩露”記憶體洩露
- Android 記憶體洩露詳解Android記憶體洩露
- android Handler導致的記憶體洩露Android記憶體洩露
- 填坑總結:python記憶體洩漏排查小技巧Python記憶體
- redisson記憶體洩漏問題排查Redis記憶體
- Linux記憶體洩露案例分析和記憶體管理分享Linux記憶體洩露
- JVM 常見線上問題 → CPU 100%、記憶體洩露 問題排查JVM記憶體洩露
- Pprof定位Go程式記憶體洩露Go記憶體洩露
- 一次 Java 記憶體洩漏的排查Java記憶體
- 簡單的記憶體“洩露”和“溢位”記憶體
- JAVA記憶體洩露的原因及解決Java記憶體洩露
- win10驅動記憶體洩露如何解決_win10記憶體洩露處理方法Win10記憶體洩露
- 乾貨分享:淺談記憶體洩露記憶體洩露
- 解決git記憶體洩露問題Git記憶體洩露
- Spring Boot heapdump洩露記憶體分析方法Spring Boot記憶體
- 線上記憶體洩露定位--memleak工具記憶體洩露
- java中如何檢視記憶體洩露Java記憶體洩露
- iOS 記憶體洩漏排查方法及原因分析iOS記憶體
- 一個 Vue 頁面的記憶體洩露分析Vue記憶體洩露
- 一個Vue頁面的記憶體洩露分析Vue記憶體洩露
- C程式記憶體洩露檢測工具——ValgrindC程式記憶體洩露
- Android效能最佳化之記憶體洩露Android記憶體洩露
- 小題大做 | Handler記憶體洩露全面分析記憶體洩露
- 異常連線導致的記憶體洩漏排查記憶體
- 記錄一次記憶體洩漏排查過程記憶體
- 案例:隱秘而低調的記憶體洩露(OOM)記憶體洩露OOM