jvm內存問題最佳實踐-文庫吧在線文庫

　　

【正文】 M本身的 Bug，例如 GC的 Bug 30 在 Java 堆中發生的 OOM 的故障癥狀 ? 如果 Java 堆發生 OOM/ML： – Weblogic Server運行緩慢，響應速度很慢（ JVM在頻繁的做 GC，Java進程占用比較多的 CPU ） – 從 console的內存監控曲線看，一直徘徊在頂部 – 最終 JVM拋出 異常， stdout 或 stderr 中將顯示這則消息 – 通過 thread dump可以看到大部分時間 ? 所有線程都在 wait，只有 GC線程在工作 ? 很多線程都在申請內存 – 線程可能會異常退出（即在 Thread Dump 中看不到這個線程，線程丟失） – 持續的 Java 堆 OOM/ML錯誤偶爾也會導致 JVM進程退出服務，通常伴隨會產生一個文本 Core文件 31 在本地內存中發生的 OOM 的故障癥狀 ? 如果本地內存 OOM/ML： – Weblogic Server運行緩慢，響應速度很慢 – 通過操作系統觀察可以看到， Java進程內存很大，而且一直在增長 – 通過 console或者 GC log可以看到， heap內存通常還有富余 – JVM 的通常做法是：處理 OOM 狀態，記錄消息，然后退出進程。 GC日志顯示內存還充足 [memory ] : GC 73043K72989K (131072K) in ms [memory ] : GC 72989K72905K (131072K) in ms [memory ] : GC 72905K72580K (131072K) in ms . . . 49 進一步分析 Java 堆 OOM ? 如果迄今為止所進行的分析不起作用，請使用 JVM 性能探查工具： – 該探查工具將實現 JVM 事件探查器接口 (JVM Profiler Interface, JVMPI)，如 Jprobe 或 OptimizeIt或者 YourKit – 確定占用堆的對象的類型、數量和大小 – 確定對象在代碼中的創建位置 – 其用法的詳細信息，請參考相應的 JVM性能探查工具文檔 ? 不過， JVM 事件探查器通常需要較高的系統開銷， 因此建議一定不要在生產環境中使用！ ? 與應用程序團隊合作，查明可能存在的內存泄漏或 改進對象的使用和 /或生命周期狀況。 53 處理本地內存 OOM（ 3） ?使用收集到的數據來解決 OOM 錯誤 ?如果懷疑發生了內存泄漏，集中精力查找泄漏源 – 第三方代碼（例如， JDBC 驅動程序）或 JNI 代碼 可能會發生泄漏 – 排除法，不使用第三方代碼 – 可能的情況下嘗試替換純 Java 實現，以確認泄漏源。重啟過了一段時間又是這樣。39。39。39。39。39。39。39。39。39。39。39。39。39。39。39。39。39。39。MDD4J －離線分析 59 YourKit（ 1） ? YourKit是一款輕量級的 Java運行時分析工具 ? ? 特性： – 性能好，對生產系統造成的影響相對其他工具比較小 – 支持多種平臺（ windows/linux/mac/solaris） – 支持多種 JDK（理論上） – 界面友好 ? 啟動方式： – 安裝 YourKit，啟動并加載 license – 拷貝 domain下的啟動腳本 ，并重命名為– 在 YourKit中找到 ，得到新的啟動腳本– 使用 ，記住啟動時 YourKit在 weblogic server上得到的監聽端口 – 在 YourKit中連接到這個監聽端口，并開始監控和分析 weblogic server的運行情況 60 YourKit（ 2） ? 啟動和配置 YourKit 1 2 3 4 61 YourKit（ 3） ?使用收集到的數據來解決 OOM 錯誤 ?如果 YourKit跟 WebLogic Server本機運行，選第一項 ?如果 YourKit連接遠程的 WebLogic Server，選第二項 需要 IP和 Port 62 YourKit（ 4） ?抓取內存鏡像 SnapShot ，做分析 63 Eclipse Memory Analyzer（ 1） ? Eclipse Memory Analyzer原名 SAP Memory Analyzer，后 SA公司捐獻給 Eclipse社區，現在 IBM也加入進來，是目前最實用的免費離線內存診斷工具 ? 特性： – 離線分析，不影響生產系統 – 需要得到 JDK內存鏡像 – 支持 SUN、 HP( ) – 最新版本支持 IBM JDK ? 啟動方式： – 啟動參數增加 XX:+HeapDumpOnCtrlBreak XX:+HeapDumpOnOutOfMemoryError – Kill 3 pid得到 heapdump文件 – jmap heap:format=b pidofjava – jmap dump:live,format=b,file=/tmp/ pidofjava – 啟動 Eclipse Memory Analyzer，加載 heapdump文件 – 圖形化分析 64 Eclipse Memory Analyzer（ 2） ? 啟動界面 65 Eclipse Memory Analyzer（ 3） ? Overview視圖 66 Eclipse Memory Analyzer（ 4） ? Leak Suspects視圖 67 Eclipse Memory Analyzer（ 5） ? Dominator tree視圖 68 Eclipse Memory Analyzer（ 6） ? 結合使用 Leak Suspects和 Dominator tree視圖 69 HeapAnalyzer（ 1） ? HeapAnalyzer是一款針對 IBM JDK的內存文本鏡像 HeapDump的分析工具 ? 特性： – 離線分析，不影響生產系統 – 需要得到 IBM JDK內存鏡像 – 只支持 IBM JDK – 只能靜態分析，要求得到現場數據 ? 啟動方式： – Kill 3 pid得到 heapdump文件 – 啟動 HeapAnalyzer，加載 heapdump文件 – 圖形化分析 70 HeapAnalyzer（ 2） ? HeapDump是 IBM JDK Heap內存的一個文本鏡像，默認生成位置在 Weblogic Server啟動目錄下，通常是 Domain目錄 ? 如果得不到 HeapDump，可能是禁止生成 ? HeapDump的生成開關 – export IBM_HEAPDUMP=true – export IBM_HEAP_DUMP=true – export IBM_HEAPDUMP_OUTOFMEMORY=true – export IBM_JAVADUMP_OUTOFMEMORY=true – export IBM_JAVACORE_OUTOFMEMORY=true – export IBM_HEAPDUMPDIR=directory_path ? 注意： – 通常 HeapDump會比較大，尤其是在 Heap內存設置很大的情況下 – 為了重現問題，得到現場數據，建議先把 HeapDump調小，推薦 1G以下 – 在 Window上，如果 HeapDump大于 1G，可能會無法打開，出現 OOM錯誤 – 啟動 HeapAnalyzer需要指定 Xmx參數 71 HeapAnalyzer（ 3） ?啟動界面 72 HeapAnalyzer（ 4） ?內存按樹狀引用關系顯示 73 HeapAnalyzer（ 5） ?內存按對象和類型顯示 74 HeapAnalyzer（ 6） ?找到懷疑泄漏的內存對象 75 HeapAnalyzer（ 7） ?內存碎片分析 76 小節回顧 ? 內存分析工具 ? YourKit ? Eeclipse Memory Analyzer ? IBM HeapAnalyzeramp。 ? 執行幾分鐘的記錄，然后對數據進行分析，以確定具 體的 JVM 問題 ? JRockit 的 JRA支持 Memory Leak檢測功能 51 處理本地內存 OOM（ 1） ?對于本地內存 OOM 錯誤： – 采用的探查方法與對 Java 堆 OOM 采用的探查方法 相同： ? 通過 verbosegc 開關收集 GC 信息 ? 確認 GC 的運行合乎預期，例如，是在 OOM 發生 前 運行 ? 留意 JVM 堆的初始（和周期）可用性 /占用率。 Hp JDK hs_err_pid****.log文件 – JRockit JDK – jrockit.****.dump文件 ? 文本 Core文件包含 JVM退出時收到的信號量，并會用 *標識導致退出的lib庫文件 – Signal 1 – Signal 0 – Signal 4 – Signal 10 – Signal 11 – 實踐表明，收到以上的信號量，通常但不絕對，表明 JVM的內存出現問題 – 需要結合 thread dump或者 GC日志來分析 33 小節回顧 ? 內存不足和內存泄漏錯誤的典型原因 ? OOM 錯誤的類型及相關故障癥狀 ? 文本 Core文件 在本小節中，我們講述了以下內容： 34 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例 35 說在診斷和定位 OOM/ML錯誤 之前 ? 第一 – 所有 JDK的 OOM/ML都是類似的，原理是一樣的 – 診斷定位方法基本一致，除非特殊說明針對那個 JDK – 這里提及的診斷定位方法以 weblogic server為主，但是適用于任何應用服務器（包括 tomcat,resin,IAS,websphere） ? 第二 – OOM/ML發生時間跨度大：短的 1個小時之內，長的 10天甚至 1個月 – 問題解決可能需要耗費大量時間和精力 – 問題解決經常會反復很多次檢查和跟蹤 – 注意保護現場，收集足夠多的信息 ? 第三 – 統計顯示 ： – OOM/ML 問題占 %， – 但平均處理時間 ，數倍于問題平均處理時間 36 探查 OOM/ML問題基本步驟 ? 1）確定是否 OOM/ML錯誤 ? 2）如果保留現場，立即查看 – 物理內存大小 – Java進程內存大小 – 剩余可用內存大小 – Swap區大小 – 查看 GC log 或 進 console查看內存使用曲線 – 并發用戶數量 /主要業務類型分析 – 立即做 thread dump幫助分析 ? 3）如果沒有保留現場，那么 – 加上 GC Flag，收集垃圾回收日志 – 直到再次發生 OOM/ML，分析 GC日志 ? 4）基本確定內存問題類型 – 物理內存不足 – 并發太多 /Java堆內存不足 – 本地泄漏 – 其他原因 ? 5）采取相應措施 ? 6）觀察，問題是否重現 ? 7）重復定位 /問題解決 37 確定是否 OOM/ML錯誤 ? 明確的 OOM/ML錯誤 –