【文章內(nèi)容簡介】 OOM/ML錯誤 – 是否有明確的 OutOfMemory錯誤信息顯示 – 是否明確的看到內(nèi)存曲線一直在頂部 – 是否 GC日志明確顯示內(nèi)存緊張 ? 不明確的信息，但是可以歸到 OOM/ML錯誤 – 需要更多信息來證實(shí) – GC日志 – Thread Dump – 文本 Core文件 – 通?？梢詺w到 OOM/ML錯誤的可能癥狀： – Weblogic Server不響應(yīng)，很慢 – GC異常，例如 heap使用到頂， GC時間很長 – Thread Dump顯示幾乎所有的線程都在等待，只有 GC線程在工作 – Core文件指出信號量為 1/0/4/10/11 38 查看現(xiàn)場 /收集信息 (1) ?物理內(nèi)存大小 – 如果物理內(nèi)存不夠，請?jiān)黾游锢韮?nèi)存 ?Java進(jìn)程內(nèi)存大小 – 如果 Java進(jìn)程內(nèi)存不大，只有幾百 M或者 1G左右，要結(jié)合并發(fā)用戶和 GC日志來考慮 – 如果 Java進(jìn)程內(nèi)存特別大，例如到 ，結(jié)合 heap設(shè)置綜合考慮。如果 heap設(shè)置不大 1G左右，那么需要考慮本地內(nèi)存泄漏的可能 ?剩余可用內(nèi)存 – 結(jié)合物理總內(nèi)存， Java進(jìn)程內(nèi)存綜合考慮是否合理 ?Swap區(qū)大小 – Swap區(qū)通常建議是物理內(nèi)存的 2－ 3倍 39 查看現(xiàn)場 /收集信息 (2) ? 查看 GC log 或 進(jìn) console查看內(nèi)存使用曲線 – 并發(fā)用戶數(shù)量 /主要業(yè)務(wù)類型分析 – 當(dāng)時并發(fā)用戶數(shù)量以及 session大小分析 – 主要業(yè)務(wù)類型分析，是否有大內(nèi)存占用的業(yè)務(wù)，例如統(tǒng)計(jì)報(bào)表等等 ? 立即做 thread dump幫助分析 – 每隔 30秒做一次，做 3次 – Unix/Linux : kill 3 pid – Windows : Ctrl+break ? 收集操作系統(tǒng) /JDK/WLS信息 – 操作系統(tǒng)版本信息 – JDK版本信息 – WebLogic Server版本信息 ? 是否使用了第三方本地代碼 40 查看現(xiàn)場 /收集信息－－措施 ? 調(diào)整措施 – 增加物理內(nèi)存 – 調(diào)整合理的 Heap設(shè)置 – 調(diào)整 Swap區(qū)大小 ? 繼續(xù)跟蹤 – 通過 Java進(jìn)程內(nèi)存大小和 Heap大小判斷 ? Java堆內(nèi)存問題 ? 本地內(nèi)存問題 – 加上 GC Flag來分析 ? IBM JDK ? verbose:gc Xverbosegclog:path_GC_log_file_name ? HP JDK ? Xverbosegc[:help]|[0|1][:file=[stdout|stderr|filename]] Xloggc ? Sun JDK / BEA Jrockit ? verbose:gc – 繼續(xù)下一步 – 分析 GC日志 41 分析 GC日志－－ 完整 GC 的輸出 ?不同的 JDK將產(chǎn)生不同格式 GC日志，以下分析以 Sun JDK標(biāo)準(zhǔn) GC日志為準(zhǔn) ?不同的 JDK有各自的其他豐富信息的 GC開關(guān)選項(xiàng) ?完整 GC 將產(chǎn)生類似如下內(nèi)容的消息： [memory ] start: GC beforeKafterK (heapK), total ms 其中： start GC 的開始時間（秒），從 JVM 啟動開始計(jì)算 before 回收前對象所使用的內(nèi)存 (KB) after 回收后對象所使用的內(nèi)存 (KB) size 回收后的堆大小 (KB) total 執(zhí)行回收的總時間（毫秒）。 完整 GC 消息示例： [memory ] : GC 131072K130052K (131072K) in ms 42 分析 GC日志－－ 分析 GC 輸出 ?GC 輸出可以反映以下情況： – OOM 錯誤是否發(fā)生在運(yùn)行完整 GC 之后 – GC 返回了多少空閑空間， GC運(yùn)行了多長時間 – 內(nèi)存使用量是否增加緩慢（即表明發(fā)生了內(nèi)存泄漏，通常需要觀察長時間 /大量的 GC日志） – 是否存在內(nèi)存碎片 – 結(jié)合 JVM進(jìn)程內(nèi)存大小，判斷 Java heap內(nèi)存問題還是本地內(nèi)存問題 43 分析 GC日志－－確定內(nèi)存問題類型 ?基本確定內(nèi)存問題類型 – Java堆內(nèi)存不足 – 本地內(nèi)存泄漏 ?不同內(nèi)存問題類型，解決方案有所不同 ?如何確定： – Java堆內(nèi)存不足 ? Java進(jìn)程內(nèi)存比較穩(wěn)定 ? GC日志顯示， heap區(qū)內(nèi)存不夠， GC很頻繁 – 本地內(nèi)存泄漏 ? GC日志顯示， heap內(nèi)存尚有足夠空間 ? 但是 Java進(jìn)程卻隨時間一直在增長（需要長時間觀察積累） 44 處理 Java Heap OOM 錯誤 ?對于 Java Heap OOM 錯誤： – 請確保啟用 verbose GC，也就是在啟動服務(wù)器時使用 java verbosegc 開關(guān) – 檢查 OOM 錯誤是否發(fā)生在運(yùn)行了完整的 GC 之后 – 檢查是否執(zhí)行了內(nèi)存壓縮以減少內(nèi)存碎片 – 還要留意初始（和周期） JVM 堆可用性 /占用率。 45 針對 Java 堆 OOM 的應(yīng)用程序分析 ?如果 JVM 正確執(zhí)行了 GC，則應(yīng)該是應(yīng)用程序問題所致： – 如果應(yīng)用程序使用了緩存對象： ? 請確保對緩存對象數(shù)量施加了限制 ? 或許可以降低緩存限值來減少總體堆大小 – 如果應(yīng)用程序使用了活動時間長的對象，請減少這些對象的數(shù)量或縮短它們的生命周期，例如，縮短 HTTP 會話的超時期間 – 調(diào)整垃圾回收策略，可能解決 OOM問題 – 查找內(nèi)存泄漏，例如，不正確的 JDBC 池連接處理 – 如果服務(wù)器只是對負(fù)載增加或添加應(yīng)用程序作出反應(yīng)，JVM 自然會需要更大的 Heap 46 分析 GC日志－－內(nèi)存緩慢增長 ?從 GC日志中看到內(nèi)存的緩慢增長 [GC 71678K61588K(98112K), secs] [GC 97999K87826K(98240K), secs] [GC 190603K170624K(191640K), secs] [GC 144325K121582K(225376K), secs] [GC 189537K162596K(257432K), secs] [GC 239766K210684K(277080K), secs] [GC 246611K208929K(359776K), secs] ??????? 47 分析 GC日志－－內(nèi)存碎片 ?從 GC日志中分析觀察到內(nèi)存碎片現(xiàn)象 – 這個問題多發(fā)生在 IBM JDK上，因?yàn)樗捎玫睦厥账惴ǜ鷦e的JDK不一致（注： IBM JDK GC輸入與上略有不同） – 在 Sun JDK / HP JDK不常見，很少出現(xiàn) ?調(diào)整策略 – IBM JDK： Xpactgc – Sun JDK：增加 young區(qū)大小 XX:NewRatio XX:NewSize XX:MaxNewSize XX:SurvivorRatio(詳細(xì)參見 Sun文檔 ) GC 減少了使用的堆，其大小已與最大 堆大小有明顯差距， OOM 卻依然出現(xiàn)！ 顯示在執(zhí)行 GC 后仍存在碎片的 GC 消息示例： [memory ] : GC 73043K72989K (131072K) in ms [memory ] : GC 72989K72905K (131072K) in ms [memory ] : GC 72905K72580K (131072K) in ms . . . 48 分析 GC日志－－ Permanent區(qū)不夠 ?從 GC日志中觀察到 – 這個問題發(fā)生在 Sun/HP JDK上，因?yàn)樗捎?Permanent區(qū)來存放 Java的 class對象 – 這個問題的主要區(qū)別在于兩者發(fā)生的時間不一樣 ?調(diào)整策略 – 增加 Permanent區(qū)大小 – XX:MaxPermSize=256M（ 推薦 128M以上） OOM 卻依然出現(xiàn)！ 注意這種情況主要出現(xiàn) 在 WLS啟動不久，通常在 1－ 20分鐘內(nèi)。 GC日志顯示內(nèi)存還充足 [memory ] : GC 73043K72989K (131072K) in ms [memory ] : GC 72989K72905K (131072K) in ms [memory ] : GC 72905K72580K (131072K) in ms . . . 49 進(jìn)一步分析 Java 堆 OOM ? 如果迄今為止所進(jìn)行的分析不起作用，請使用 JVM 性能探查工具： – 該探查工具將實(shí)現(xiàn) JVM 事件探查器接口 (JVM Profiler Interface, JVMPI)，如 Jprobe 或 OptimizeIt或者 YourKit – 確定占用堆的對象的類型、數(shù)量和大小 – 確定對象在代碼中的創(chuàng)建位置 – 其用法的詳細(xì)信息，請參考相應(yīng)的 JVM性能探查工具文檔 ? 不過， JVM 事件探查器通常需要較高的系統(tǒng)開銷， 因此建議一定不要在生產(chǎn)環(huán)境中使用！ ? 與應(yīng)用程序團(tuán)隊(duì)合作，查明可能存在的內(nèi)存泄漏或 改進(jìn)對象的使用和 /或生命周期狀況。 50 JRockit 功能 ? JRockit 支持 Java 運(yùn)行時分析器 (Java Runtime Analyzer, JRA)： – 該分析器對 JRockit JVM 及 JRockit 上運(yùn)行的 Java 應(yīng)用程序都能夠進(jìn)行運(yùn)行時性能分析。 ? JRA 包括以下兩個部分： – 收集有關(guān) JVM 和當(dāng)前正在運(yùn)行的 Java 應(yīng)用程序的數(shù)據(jù)。 – 使用分析器工具來查看收集到的信息。 ? 執(zhí)行幾分鐘的記錄，然后對數(shù)據(jù)進(jìn)行分析，以確定具 體的 JVM 問題 ? JRockit 的 JRA支持 Memory Leak檢測功能 51 處理本地內(nèi)存 OOM（ 1） ?對于本地內(nèi)存 OOM 錯誤： – 采用的探查方法與對 Java 堆 OOM 采用的探查方法 相同： ? 通過 verbosegc 開關(guān)收集 GC 信息 ? 確認(rèn) GC 的運(yùn)行合乎預(yù)期，例如，是在 OOM 發(fā)生 前 運(yùn)行 ? 留意 JVM 堆的初始（和周期）可用性 /占用率。 – 定期監(jiān)視進(jìn)程內(nèi)存大小： ? 在 Unix/Linux 上，使用 ps p PID o vsz 或者 top命令 ? 在 Windows 上，使用 perfmon 工具。 – 確定是否使用了任何本地模塊或 JNI 代碼。 – 還要檢查計(jì)算機(jī)的物理內(nèi)存總量（ RAM 和交換空間 之和）是否足以滿足所有正在運(yùn)行的進(jìn)程的需要 52 處理本地內(nèi)存 OOM（ 2） ? 請記住，進(jìn)程內(nèi)存大?。? – 是進(jìn)程運(yùn)行時所占用的地址空間 – 受 OS 進(jìn)程大小值的限制： ? 32 位 Unix：進(jìn)程大小限值為 4GB，保留 12GB 供 OS 自己使用 ? Red Hat Linux AS ：可供應(yīng)用程序使用的進(jìn)程大小為 3GB ? Windows：進(jìn)程大小限值為 2GB（缺省值），但可以增加到 3GB – 包括 Java 堆內(nèi)存， JVM 在服務(wù)器啟動時會保留指定的最大值 – 還可能由 JNI 代碼或本地模塊（例如，本地 JDBC 驅(qū)動程序） 進(jìn)行分配 – 還會受計(jì)算機(jī)物理內(nèi)存及計(jì)算機(jī)中運(yùn)行的其它進(jìn)程的限制。 53 處理本地內(nèi)存 OOM（ 3） ?使用收集到的數(shù)據(jù)來解決 OOM 錯誤 ?如果懷疑發(fā)生了內(nèi)存泄漏，集中精力查找泄漏源 – 第三方代碼（例如， JDBC 驅(qū)動程序）或 JNI 代碼 可