分析記憶體回收行程 (GC) 的記錄檔以監視記憶體問題
建議您在生產環境啟用 GC 記錄。如需有關如何啟用 GC 記錄的詳細資訊,請參閱
監視 ThingWorx 伺服器的記憶體使用量部份。啟用 GC 記錄之後,會記錄伺服器的所有 GC 活動。如果 JVM 長時間沒有回應,外部工具 (例如 VisualVM) 可能無法收集記憶體資料。不過,JVM 可以列印 GC 活動,這可協助您找出記憶體問題的原因。
閱讀 GC 記錄檔
您可使用例如 GCEasy.io 與 Chewiebug GC Viewer 這類的工具分析 GC 記錄檔。您也可以使用文字編輯器針對常見問題手動分析 GC 記錄檔。
每個記憶體清理操作一般都會如以下範例所示的方式列印。
1. 自 JVM 啟動以來的時間
2. GC 的類型
3. GC 的原因
4. 從 549M 清理至 4M 的新世代
5. 總計新世代大小
6. GC 完成的總時間
7. 已分配的堆集
8. Java 清除之解決方案的總記憶體
如需有關 GC 操作的詳細資訊, 請參閱 Oracle 文件集。
GC 分析工具會將清理情況的文字表示轉換為更容易看懂的圖形。
分析 GC 記錄檔中的資料可協助您識別下列指示 ThingWorx 解決方案中記憶體問題的情境。
• 超長的完整 GC 操作 (45 秒+) - 這些操作是停止所有執行緒的操作,建議不要執行這些操作。例如,下列完整 GC 會花費 46 秒。在此期間,其他所有使用者活動都會停止:
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• 在迴圈中發生的完整 GC - 這些是快速連續發生的完整 GC。
例如,下列四個連續記憶體回收幾乎要花費兩分鐘的時間來解決:
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• 在下圖中,圖形波峰上的紅色三角形以視覺化方式表示了在迴圈中發了完整 GC。
• 記憶體流失 - 當記憶體中的物件數不斷增加,且記憶體無法清除時,就會發生這種情況。
在下列範例中,無論記憶體回收行程如何,記憶體都穩定增加:
建議 - 如果沒有自動工具來監視並記錄記憶體在一段時間內的使用量,請每天查看 GC 記錄檔,瞭解是否存在記憶體問題。若發生記憶體問題,請收集 JVM 執行緒傾印或堆集傾印,以識別長時間執行的操作。這些操作會觸發 ThingWorx 解決方案中的基礎記憶體問題。