分析記憶體回收行程 (GC) 的記錄檔以監視記憶體問題
建議您在生產環境啟用 GC 記錄。如需有關如何啟用 GC 記錄的詳細資訊，請參閱
監視 ThingWorx 伺服器的記憶體使用量部份。啟用 GC 記錄之後，會記錄伺服器的所有 GC 活動。如果 JVM 長時間沒有回應，外部工具 (例如 PSM 或 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]
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。
• 記憶體流失 - 當記憶體中的物件數不斷增加，且記憶體無法清除時，就會發生這種情況。
在下列範例中，無論記憶體回收行程如何，記憶體都穩定增加：
建議 - 如果沒有例如 PSM 這類的自動工具來監視並記錄記憶體在一段時間內的使用量，請每天查看 GC 記錄檔，瞭解是否存在記憶體問題。若發生記憶體問題，請收集 JVM 執行緒傾印或堆集傾印，以識別長時間執行的操作。這些操作會觸發 ThingWorx 應用程式中的基礎記憶體問題。