jvm內存問題最佳實踐(留存版)

　　

【正文】 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錯誤 – 是否有明確的 OutOfMemory錯誤信息顯示 – 是否明確的看到內存曲線一直在頂部 – 是否 GC日志明確顯示內存緊張 ? 不明確的信息，但是可以歸到 OOM/ML錯誤 – 需要更多信息來證實 – GC日志 – Thread Dump – 文本 Core文件 – 通常可以歸到 OOM/ML錯誤的可能癥狀： – Weblogic Server不響應，很慢 – GC異常，例如 heap使用到頂， GC時間很長 – Thread Dump顯示幾乎所有的線程都在等待，只有 GC線程在工作 – Core文件指出信號量為 1/0/4/10/11 38 查看現場 /收集信息 (1) ?物理內存大小 – 如果物理內存不夠，請增加物理內存 ?Java進程內存大小 – 如果 Java進程內存不大，只有幾百 M或者 1G左右，要結合并發用戶和 GC日志來考慮 – 如果 Java進程內存特別大，例如到 ，結合 heap設置綜合考慮。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。39。39。39。39。39。39。39。39。39。 53 處理本地內存 OOM（ 3） ?使用收集到的數據來解決 OOM 錯誤 ?如果懷疑發生了內存泄漏，集中精力查找泄漏源 – 第三方代碼（例如， JDBC 驅動程序）或 JNI 代碼 可能會發生泄漏 – 排除法，不使用第三方代碼 – 可能的情況下嘗試替換純 Java 實現，以確認泄漏源。 ? 示例： – Xms768m Xmx1024m Xmn256m Xgcpolicy:gencon 24 選擇合適的 GC算法 ? 選擇 GC算法，遵循以下原則： – 評估程序類型 桌面應用還是服務器端應用 吞吐量優先還是響應時間優先 – 僅適用 64位 JDK的算法 比如在 IBM AIX 64位 JDK環境下，當 heap區大于 16G后， subpool明顯性能提高 – 確定 GC算法之后，再逐步調整小參數 Xmn(XX:NewSize XX:MaxNewSize) XX:SurvivorRatio XX:MaxTenuringThreshold ....... – 測試期間實時監控 SUN、 HP、 JRockit都可以通過 jstat命令進行實時監控 避免使用 jmap histo，原因是可能會造成 Full GC 25 小節回顧 ? GC概念 ? 常見 GC算法 ? 選擇合適的 GC算法 在本小節中，我們講述了以下內容： 26 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例 27 Java內存問題的主要發生在 ?操作系統本身 ?Java內存區： – heap堆內存 – permanent區 ?本地內存區： – JVM進程內存 – Java使用的第三方本地代碼 28 內存不足和內存泄漏錯誤的典型原因（ 1） ? 物理內存不足 – 物理內存有限，例如只有 1G – 物理內存很大，但是應用很多，占用太多內存 ? Swap區大小不夠 ? Weblogic Server壓力太大 – 并發用戶太多 – 大數據量分配應用，例如統計報表 ? Permanent區太小 ? 用戶代碼內存不釋放 – session放置了大量對象 – 在內存分配大量數據 – 用戶自己創建太多線程 – 調用 AWT等畫圖接口 ? 用戶代碼內存泄漏問題 – jdbc連接沒有 close – 分配好的對象沒有 close和釋放 29 內存不足和內存泄漏錯誤的典型原因（ 2） ? Weblogic Server配置不當 – 給 heap分配的內存太多 – session timeout時間太長 – EJB pool和 Cache的太大 – JMS配置 ? Java內存碎片 – 尤其在 IBM JDK上表現明顯 ? 第三方 Java應用的內存問題 – 第三方 Java應用也存在內存不足或者泄漏問題 ? 第三方本地代碼的內存泄漏問題 – 第二類 JDBC驅動的內存泄漏，例如 Oracle Oci Driver – 其他第三方本地代碼的內存泄漏 ? JVM本身的內存問題 – JIT技術需要消耗更多的本地內存 – JV