記憶體效能
通常情況下，會在 ThingWorx 應用程式的總記憶體利用率中發現效能問題。如果應用程式大量使用 Java 記憶體堆集，並持續建立及捨棄大型記憶體物件，您會在此系統的記憶體指標中看到一些效能不佳指示器。Java 記憶體回收的頻率與持續時間在系統的整體回應中扮演著重要的角色。如果您有連續的記憶體回收迴圈，應用程式會對記憶體造成壓力，而且這可能會使您的整個 ThingWorx 平台完全沒有回應。
如果想要監視一段時間內的記憶體使用量與記憶體回收情況，建議您啟用 GC 記錄。例如 PSM 或 VisualVM 之類的工具也會顯示記憶體使用率資訊。不過，如果 JVM 因完整的 GC 迴圈而沒有回應，這些外部應用程式可能無法擷取資料來顯示記憶體問題。
請注意，當您在作業系統層級監視記憶體時，它不會提供有關 ThingWorx 應用程式如何使用分配給它的記憶體的相關資訊。監視工具會擷取 Java 從作業系統請求了多少記憶體的相關資料，但不會顯示 Java 是如何使用記憶體的。大多數效能問題都是因 Java 堆集空間中的內部記憶體使用量所致，跟作業系統的記憶體分配沒有關係。
分配給 Java 的總記憶體由在執行時間載入的 -Xms (最小) 與 -Xmx (最大) 參數決定。如果使用 tomcat8w 組態面板配置 Tomcat，-Xms 與 -Xmx 參數會指定初始及最大記憶體集區大小。
如果在啟動時未指定最小值或最大值，Java 流程在啟動時會使用啟發學習法來預先分配這些數量。依預設，Java 會嘗試分配作業系統中總可用 RAM 的四分之一。
導致記憶體問題的操作
您必須監視以下可能會導致記憶體問題的操作：
• 持續時間超過 45 秒的超長頻繁完整 GC 操作 - 建議不要執行完整 GC，因為這些操作是停止所有執行緒的操作。JVM 暫停的時間越長，記憶體問題就越多：
◦ 當 JVM 嘗試產生更多可用記憶體時，其他所有使用中執行緒程都會停止。
◦ 完整 GC 會花費相當長的時間，有時會耗時數分鐘之久，應用程式在此期間可能會變為沒有回應。
• 在迴圈中發生的完整 GC - 快速連續發生的完整 GC 叫做完整 GC 迴圈。它們可能會導致下列問題：
◦ 如果 JVM 無法清理其他任何記憶體，迴圈可能會無限期繼續。
◦ 當迴圈繼續時，使用者無法使用 ThingWorx 應用程式。
• 記憶體流失 - 當記憶體中保留的物件數不斷增加時，就會發生記憶體流失。無論 JVM 執行的記憶體回收類型為何，都無法清除這些物件。
◦ 當您檢查一段時間內記憶體耗用量時，記憶體流失會顯示為從未回收的恆會增加的記憶體使用量。
◦ 無論所設定的上限為何，伺服器最終都會用盡記憶體。