jvm內(nèi)存問題最佳實踐-文庫吧

【正文】 ate14引入，實際生產(chǎn)環(huán)境中還沒有采用 21 常見 GC算法 SUN、 HP（ 2） ? 并行算法示例： – server Xms1536m Xmx1536m XX:NewSize=512m XX:MaxNewSize=512m XX:PermSize=128m XX:MaxPermSize=256m XX:+UseParallelGC XX:+UseParallelOldGC XX:+UseAdaptiveSizePolicy XX:SurvivorRatio=2 XX:+DisableExplicitGC verbose:gc XX:+PrintGCDetails XX:+PrintGCTimeStamps Xloggc:/tmp/server_gc$$.log ? 并發(fā)算法示例： – server Xms1536m Xmx1536m XX:NewSize=1024m XX:MaxNewSize=1024m XX:PermSize=128m XX:MaxPermSize=256m XX:+UseConcMarkSweepGC XX:+UseParNewGC XX:SurvivorRatio=2 XX:MaxTenuringThreshold=16 XX:+DisableExplicitGC XX:+CMSPermGenSweepingEnabled XX:+UseCMSCompactAtFullCollection XX:+UseCMSInitiatingOccupancyOnly XX:CMSInitiatingOccupancyFraction=60 XX:+CMSParallelRemarkEnabled =3600000 =3600000 verbose:gc XX:+PrintGCDetails XX:+PrintGCTimeStamps Xloggc:/tmp/server_gc$$.log 22 常見 GC算法 JRockit ?根據(jù)回收器，簡單分為： – XgcPrio:throughput 默認(rèn)算法，主要用于桌面應(yīng)用 – XgcPrio:pausetime XgcPrio:pausetime XpauseTarget:210ms 因為免費，所以最低只能設(shè)置到 200ms。 200ms是 RealTime JDK的分界線 – XgcPrio:deterministic 動態(tài)調(diào)整的垃圾收集策略 ?示例： – Xms1024m Xmx1024m Xgcprio:pausetime Xpausetarget=210ms XgcReport XgcPause Xverbose:memory 23 常見 GC算法 IBM ? 根據(jù)回收器，簡單分為： – Xgcpolicy:optthruput 默認(rèn)策略。對于吞吐量比短暫的 GC 停頓更重要的應(yīng)用程序，通常使用這種策略。每當(dāng)進行垃圾收集時，應(yīng)用程序都會停頓。 – Xgcpolicy:optavgpause 通過并發(fā)地執(zhí)行一部分垃圾收集，在高吞吐量和短 GC 停頓之間進行折中。應(yīng)用程序停頓的時間更短。 – Xgcpolicy:gencon 以不同方式處理短期存活的對象和長期存活的對象。采用這種策略時，具有許多短期存活對象的應(yīng)用程序會表現(xiàn)出更短的停頓時間，同時仍然產(chǎn)生很好的吞吐量。 – Xgcpolicy:subpool 采用與默認(rèn)策略相似的算法，但是采用一種比較適合多處理器計算機的分配策略。建議對于有 16 個或更多處理器的 SMP 計算機使用這種策略。這種策略只能在 IBM pSeries174。 和 zSeries174。 平臺上使用。需要擴展到大型計算機上的應(yīng)用程序可以從這種策略中受益。 ? 示例： – Xms768m Xmx1024m Xmn256m Xgcpolicy:gencon 24 選擇合適的 GC算法 ? 選擇 GC算法，遵循以下原則： – 評估程序類型 桌面應(yīng)用還是服務(wù)器端應(yīng)用 吞吐量優(yōu)先還是響應(yīng)時間優(yōu)先 – 僅適用 64位 JDK的算法 比如在 IBM AIX 64位 JDK環(huán)境下，當(dāng) heap區(qū)大于 16G后， subpool明顯性能提高 – 確定 GC算法之后，再逐步調(diào)整小參數(shù) Xmn(XX:NewSize XX:MaxNewSize) XX:SurvivorRatio XX:MaxTenuringThreshold ....... – 測試期間實時監(jiān)控 SUN、 HP、 JRockit都可以通過 jstat命令進行實時監(jiān)控 避免使用 jmap histo，原因是可能會造成 Full GC 25 小節(jié)回顧 ? GC概念 ? 常見 GC算法 ? 選擇合適的 GC算法 在本小節(jié)中，我們講述了以下內(nèi)容： 26 MENU ? 選擇合適的 Java虛擬機 ? Java內(nèi)存管理的基本概念 ? GC次數(shù)過多消耗時間過長的原因和癥狀 ? 內(nèi)存不足和內(nèi)存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 使用分析工具解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 預(yù)防內(nèi)存不足和內(nèi)存泄漏 ? OutOfMemory/Memory Leak錯誤實例 27 Java內(nèi)存問題的主要發(fā)生在 ?操作系統(tǒng)本身 ?Java內(nèi)存區(qū)： – heap堆內(nèi)存 – permanent區(qū) ?本地內(nèi)存區(qū)： – JVM進程內(nèi)存 – Java使用的第三方本地代碼 28 內(nèi)存不足和內(nèi)存泄漏錯誤的典型原因（ 1） ? 物理內(nèi)存不足 – 物理內(nèi)存有限，例如只有 1G – 物理內(nèi)存很大，但是應(yīng)用很多，占用太多內(nèi)存 ? Swap區(qū)大小不夠 ? Weblogic Server壓力太大 – 并發(fā)用戶太多 – 大數(shù)據(jù)量分配應(yīng)用，例如統(tǒng)計報表 ? Permanent區(qū)太小 ? 用戶代碼內(nèi)存不釋放 – session放置了大量對象 – 在內(nèi)存分配大量數(shù)據(jù) – 用戶自己創(chuàng)建太多線程 – 調(diào)用 AWT等畫圖接口 ? 用戶代碼內(nèi)存泄漏問題 – jdbc連接沒有 close – 分配好的對象沒有 close和釋放 29 內(nèi)存不足和內(nèi)存泄漏錯誤的典型原因（ 2） ? Weblogic Server配置不當(dāng) – 給 heap分配的內(nèi)存太多 – session timeout時間太長 – EJB pool和 Cache的太大 – JMS配置 ? Java內(nèi)存碎片 – 尤其在 IBM JDK上表現(xiàn)明顯 ? 第三方 Java應(yīng)用的內(nèi)存問題 – 第三方 Java應(yīng)用也存在內(nèi)存不足或者泄漏問題 ? 第三方本地代碼的內(nèi)存泄漏問題 – 第二類 JDBC驅(qū)動的內(nèi)存泄漏，例如 Oracle Oci Driver – 其他第三方本地代碼的內(nèi)存泄漏 ? JVM本身的內(nèi)存問題 – JIT技術(shù)需要消耗更多的本地內(nèi)存 – JVM本身的 Bug，例如 GC的 Bug 30 在 Java 堆中發(fā)生的 OOM 的故障癥狀 ? 如果 Java 堆發(fā)生 OOM/ML： – Weblogic Server運行緩慢，響應(yīng)速度很慢（ JVM在頻繁的做 GC，Java進程占用比較多的 CPU ） – 從 console的內(nèi)存監(jiān)控曲線看，一直徘徊在頂部 – 最終 JVM拋出 異常， stdout 或 stderr 中將顯示這則消息 – 通過 thread dump可以看到大部分時間 ? 所有線程都在 wait，只有 GC線程在工作 ? 很多線程都在申請內(nèi)存 – 線程可能會異常退出（即在 Thread Dump 中看不到這個線程，線程丟失） – 持續(xù)的 Java 堆 OOM/ML錯誤偶爾也會導(dǎo)致 JVM進程退出服務(wù)，通常伴隨會產(chǎn)生一個文本 Core文件 31 在本地內(nèi)存中發(fā)生的 OOM 的故障癥狀 ? 如果本地內(nèi)存 OOM/ML： – Weblogic Server運行緩慢，響應(yīng)速度很慢 – 通過操作系統(tǒng)觀察可以看到， Java進程內(nèi)存很大，而且一直在增長 – 通過 console或者 GC log可以看到， heap內(nèi)存通常還有富余 – JVM 的通常做法是：處理 OOM 狀態(tài)，記錄消息，然后退出進程。 – 如果 JVM 或任何其它已加載的模塊（例如， libc 或第 三方模塊）不處理異常， OS 將通過 sigabort 強制 JVM 退出。 – 通常會導(dǎo)致 JVM異常退出，通常會產(chǎn)生 JVM 文本 Core文件和二進制核心文件。 32 JVM退出時產(chǎn)生的文本 Core文件 ? 通常 JVM異常退出伴隨會產(chǎn)生一個文本 Core文件 – 除了 OOM， JVM也會因為其他原因異常退出 – IBM JDK javacore****.txt文件 – Sun amp。 Hp JDK hs_err_pid****.log文件 – JRockit JDK – jrockit.****.dump文件 ? 文本 Core文件包含 JVM退出時收到的信號量，并會用 *標(biāo)識導(dǎo)致退出的lib庫文件 – Signal 1 – Signal 0 – Signal 4 – Signal 10 – Signal 11 – 實踐表明，收到以上的信號量，通常但不絕對，表明 JVM的內(nèi)存出現(xiàn)問題 – 需要結(jié)合 thread dump或者 GC日志來分析 33 小節(jié)回顧 ? 內(nèi)存不足和內(nèi)存泄漏錯誤的典型原因 ? OOM 錯誤的類型及相關(guān)故障癥狀 ? 文本 Core文件 在本小節(jié)中，我們講述了以下內(nèi)容： 34 MENU ? 選擇合適的 Java虛擬機 ? Java內(nèi)存管理的基本概念 ? GC次數(shù)過多消耗時間過長的原因和癥狀 ? 內(nèi)存不足和內(nèi)存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 使用分析工具解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 預(yù)防內(nèi)存不足和內(nèi)存泄漏 ? OutOfMemory/Memory Leak錯誤實例 35 說在診斷和定位 OOM/ML錯誤 之前 ? 第一 – 所有 JDK的 OOM/ML都是類似的，原理是一樣的 – 診斷定位方法基本一致，除非特殊說明針對那個 JDK – 這里提及的診斷定位方法以 weblogic server為主，但是適用于任何應(yīng)用服務(wù)器（包括 tomcat,resin,IAS,websphere） ? 第二 – OOM/ML發(fā)生時間跨度大：短的 1個小時之內(nèi)，長的 10天甚至 1個月 – 問題解決可能需要耗費大量時間和精力 – 問題解決經(jīng)常會反復(fù)很多次檢查和跟蹤 – 注意保護現(xiàn)場，收集足夠多的信息 ? 第三 – 統(tǒng)計顯示 ： – OOM/ML 問題占 %， – 但平均處理時間 ，數(shù)倍于問題平均處理時間 36 探查 OOM/ML問題基本步驟 ? 1）確定是否 OOM/ML錯誤 ? 2）如果保留現(xiàn)場，立即查看 – 物理內(nèi)存大小 – Java進程內(nèi)存大小 – 剩余可用內(nèi)存大小 – Swap區(qū)大小 – 查看 GC log 或 進 console查看內(nèi)存使用曲線 – 并發(fā)用戶數(shù)量 /主要業(yè)務(wù)類型分析 – 立即做 thread dump幫助分析 ? 3）如果沒有保留現(xiàn)場，那么 – 加上 GC Flag，收集垃圾回收日志 – 直到再次發(fā)生 OOM/ML，分析 GC日志 ? 4）基本確定內(nèi)存問題類型 – 物理內(nèi)存不足 – 并發(fā)太多 /Java堆內(nèi)存不足 – 本地泄漏 – 其他原因 ? 5）采取相應(yīng)措施 ? 6）觀察，問題是否重現(xiàn) ? 7）重復(fù)定位 /問題解決 37 確定是否 OOM/ML錯誤 ? 明確的