内存性能
性能问题通常显示在 ThingWorx 应用程序的整体内存利用率中。如果您的应用程序主动使用 Java 内存堆并持续创建并放弃大量内存对象，则您会在此系统的内存指标中看到一些不良性能指标。Java 无用单元收集的频率和持续时间在系统的整体响应中发挥着重要作用。如果具有连续的无用单元收集循环，则应用程序会变得内存紧张，从而导致整个 ThingWorx 平台完全无响应。
要一直监控 Java 内存使用率和无用单元收集，建议启用 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 所执行的无用单元收集的类型为何，都无法清理这些对象。
◦ 当您检查内存随时间的消耗情况时，内存泄漏会显示为从未回收过的不断增加的内存使用率。
◦ 无论上限设置为何，服务器终会耗尽内存。