Arbeitsspeicherleistung
Leistungsprobleme werden im Allgemeinen in der Gesamtarbeitsspeicherverwendung von ThingWorx Lösungen angezeigt. Wenn Ihre Lösung den Java-Arbeitsspeicher-Heap aggressiv verwendet und ständig große Arbeitsspeicherobjekte erstellt und verwirft, sehen Sie einige schlechte Leistungsindikatoren in den Arbeitsspeichermetriken für dieses System. Häufigkeit und Dauer von Java Garbage Collections spielen eine wichtige Rolle bei der Gesamtreaktionsfähigkeit des Systems. Wenn Sie kontinuierliche Garbage Collection-Schleifen haben, wird die Lösung in Bezug auf Arbeitsspeicher stark beansprucht. Dies kann dazu führen, dass die gesamte ThingWorx Plattform nicht reagiert.
Um die Java-Arbeitsspeicherverwendung und Garbage Collection zu überwachen, wird empfohlen, die GC-Protokollierung zu aktivieren. Tools wie VisualVM zeigen auch Informationen zur Arbeitsspeichernutzung an. Wenn die JVM jedoch aufgrund von vollständigen GC-Schleifen nicht reagiert, können diese externen Lösungen möglicherweise keine Daten abrufen, um die Arbeitsspeicherprobleme anzuzeigen.
Beachten Sie, dass beim Überwachen des Arbeitsspeichers auf Betriebssystemebene keine Informationen darüber bereitgestellt werden, wie Ihre ThingWorx Lösung den ihr zugeordneten Arbeitsspeicher verwendet. Das Tool zur Überwachung ruft Daten darüber ab, wie viel Arbeitsspeicher Java vom Betriebssystem angefordert hat, zeigt jedoch nicht an, wie Java den Arbeitsspeicher verwendet. Die meisten Leistungsprobleme sind auf die interne Arbeitsspeicherverwendung im Java-Heap-Speicherplatz zurückzuführen, nicht auf die Arbeitsspeicherzuordnungen des Betriebssystems.
Der Gesamtarbeitsspeicher, der Java zugeordnet ist, wird durch die Parameter -Xms (Minimum) und -Xmx (Maximum) bestimmt, die zur Laufzeit geladen werden. Die Parameter -Xms und -Xmx geben die ursprüngliche und maximale Arbeitsspeicherpool-Größe an, wenn Tomcat mit dem tomcat8w-Konfigurationsfensterbereich konfiguriert wird.
Wenn beim Start keine Mindest- oder Höchstwerte angegeben werden, verwendet der Java-Prozess eine Heuristik, um diese Werte vorab zuzuordnen. Standardmäßig versucht Java, ein Viertel des im Betriebssystem verfügbaren gesamten RAMs zuzuordnen.
Operationen, die Arbeitsspeicherprobleme verursachen
Sie müssen die folgenden Operationen überwachen, die Arbeitsspeicherprobleme verursachen können:
• Extrem lange und häufige vollständige GC-Operationen mit einer Dauer von mehr als 45 Sekunden – Vollständige GCs sind unerwünscht, da es sich um Stop-the-World-Operationen handelt. Je länger die JVM pausiert, desto mehr Arbeitsspeicherprobleme treten auf:
◦ Alle anderen aktiven Threads werden angehalten, während die JVM versucht, mehr Arbeitsspeicher zur Verfügung zu stellen.
◦ Vollständige GCs dauern lange, manchmal Minuten, in denen die Lösung möglicherweise nicht reagiert.
• Vollständige GCs in einer Schleife – Vollständige GCs, die in schneller Folge auftreten, werden als vollständige GC-Schleifen bezeichnet. Sie können die folgenden Probleme verursachen:
◦ Wenn die JVM keinen zusätzlichen Arbeitsspeicher bereinigen kann, kann die Schleife endlos sein.
◦ Die ThingWorx Lösung steht Benutzern nicht zur Verfügung, während die Schleife fortgesetzt wird.
• Arbeitsspeicherlecks – Arbeitsspeicherlecks treten in der Lösung auf, wenn eine zunehmende Anzahl von Objekten im Arbeitsspeicher beibehalten wird. Diese Objekte können nicht bereinigt werden, unabhängig vom Typ der Garbage Collection, die die JVM durchführt.
◦ Wenn Sie den Arbeitsspeicherverbrauch prüfen, wird ein Arbeitsspeicherleck als eine stetig zunehmende Arbeitsspeicherverwendung angezeigt, die nie zurückgefordert wurde.
◦ Dem Server geht schließlich der Arbeitsspeicher aus, unabhängig von den festgelegten Obergrenzen.