Überwachen von TarMK | AEM 6.3 | OAK 1.6

* Die folgenden Informationen beziehen sich auf die Oak-Version 1.6+ und AEM 6.3+.

Problem
Aufgrund des begrenzten Speicherplatzes (ein- und aus-Stapel) überlädt sich der Cache, wenn die Repository der Instanz über ein bestimmtes Maß anwächst.
Folglich greift ein Großteil des Repositorys auf gelesene Daten direkt über die Festplatte zu, was viel langsamer ist und zu einem schlechten Benutzererlebnis führt.

Symptome
Die Instanz wird insgesamt langsam: Die Reaktionszeit erhöht sich und Online-Revisionen brauchen deutlich länger, wobei manchmal das zugeteilte Wartungsfenster überschritten wird.
Auf der Systemebene wird eine konstant hohe IO-Aktivität beobachtet.

Es gibt mehrere Endpunkte, die überwacht werden, um zu bestimmen, wann das System an IO-gebunden wird.  
In den folgenden Abschnitten werden die verfügbaren Endpunkte und Hauptindikatoren besprochen.

Es gibt verschiedene Endpunkte zur Überwachung von IO-bezogener Metrik in AEM, JVM und dem Betriebssystem. 

Zusammen stellen sie unterschiedliche Perspektiven über die gesamte Durchlaufleistung im System auf verschiedenen Schichten zur Verfügung: von JCR Sessions zu Commit in der TarMK bis zu Disk in IO der TarMK.

Zusammen mit Informationen, die über JVM und das Betriebssystem-Level-Werkzeug gesammelt wurden, bieten sie zahlreiche Informationen über die Gesundheit des Systems und helfen, Engpässe zu identifizieren.

• Jede Sitzung legt eine SessionMBean -Instanz offen, die bestimmte Werte wie die Anzahl und Rate von Lese-und Schreibvorgängen bei der Sitzung enthält.
• Die RepositoryStatsMBean offenbart Endpunkte, die die Anzahl der offenen Sitzungen, die Anmelderate für Sitzungen, das gesamte Laden der Lese- und Schreibvorgänge für alle Sitzungen, die Dauer der gesamten Lese- und Schreibvorgänge für allen Sitzungen und das gesamte Laden und die Zeiten für Anfragen und Beobachtungen enthält.
• SegmentNodeStoreStatsMBean offenbart Endpunkte, die Zuweisungen überwachen: Anzahl und Rate, Anzahl der in Warteschlange eingereihten Zuweisungen und Zeiten für die Warteschlangen.
• FileStoreStatsMBean offenbart Endpunkte, die die Anzahl der Daten auf der Diskette, die Anzahl der Tar-Dateien und den gesamten Platzbedarf auf der Festplatte reflektieren.

Zusätzlich zu diesen Endpunkten gibt es viele JVM- und Betriebssystem-spezifische Werkzeuge, mit denen Sie weitere Einblicke darüber enthalten, was das System beschäftigt:

• Java Mission Control (jmc) ist ein leistungsstarkes Werkzeug, mit dem Sie jeden Leistungsaspekt einer laufenden JVM erfassen. Seine Fähigkeit, jedes IO pro Java-Prozess aufzunehmen, kann von unschätzbarem Vorteil sein.
• Die Befehlszeilen-Werkzeuge jstat, jstack, und jmap sind nützlich, um in den JVM-Müllsammler, die JVM-Threads und den JVM-Stapel zu gelangen.
• Die Betriebssystem-Levelwerkzeuge vmstat und iostat verwendet man, um IO und die CPU-Nutzung auf dem betriebenen Systemlevel zu untersuchen.

Was: die Anzahl der Festplatten-Operationen (lesen/schreiben) pro Zeiteinheit (Sekunde)

Wie: Betriebssystem-Level-Einrichtung (beispielsweise: vmstat, iostat auf UNIX)

Normal: Geringes Level an Lesevorgängen auf der Festplatte (fast 0); eine konstant geringe Anzahl an Schreibvorgängen (siehe Bild). Spitzen während der Revisionsreinigung.

Warnung: Hohe und wachsende Levels von Festplatten-Lesevorgängen sind ein Zeichen dafür, dass der Speicher zu klein ist (siehe Bild).

HAFTUNGSAUSSCHLUSS: Ein hohes Volumen an Festplatten-IO wird durch Operationen, die im AEM laufen (beispielsweise: Elementaufnahme) oder durch andere Prozesse (beispielsweise: Scan nach Viren) verursacht. Stellen Sie also sicher, dass Sie andere Ursachen ausschließen, bevor Sie das Segment Tar als Schuldigen identifizieren. Im Allgemeinen ist der Trend über Tage relevanter als die kurze Spitzen.

• Was: Zeit, die die CPU zur Durchführung verschiedener Operationen benötigt, insbesondere das Warten auf IO.
• Wie: Betriebssystem-Level-Einrichtung (z.B.: vmstat auf UNIX). Nicht alle Werkzeuge melden dies (z. B.: oben).
• Normal: CPU wird hauptsächlich von der Anwendung auf Benutzerebene verwendet und die Wartezeit auf IO ist ein kleinerer Prozentsatz.
• Warnung: Die CPU verbringt mit zunehmender Tendenz die meisten Zyklen damit, auf IO zu warten, was zu Lasten der Benutzeranwendung geht.
• HAFTUNGSAUSSCHLUSS: Ein hoher Prozentsatz des CPU wartet auf IO, weil andere Vorgänge in AEM ausgeführt werden (zum Beispiel: Asset-Einnahme) oder durch einen anderen Prozess (zum Beispiel: Virenscan). Schließen Sie deshalb jede andere Ursache aus, bevor Sie „Segment Tar“ als den Schuldigen diagnostizieren. Im Allgemeinen ist der Trend über Tage relevanter als die kurze Spitzen.

• Was: Die Zuweisen-Warteschlange ist ein Pufferungsmechanismus, der von Segment Tar verwendet wird, wenn das eingehende Volumen von Zuweisungen höher als die Verarbeitungsgeschwindigkeit ist.
• Wie: Die Echtzeit Zuweisungs-Warteschlange wird über den JMX MBean angezeigt: org.apache.jackrabbit.oak: COMMIT_QUEUE_SIZE (Metriken) (/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUE_SIZE%2Ctype%3DMetrics). Der Zugriff erfolgt über http auf der Systemkonsole oder über einen JMX-Client.
• Normal: Eine leere Warteschlange (size=0) zeigt an, dass das System in einem gesunden Zustand ist und alle Zuweisungen in der Geschwindigkeit bearbeiten kann, in der sie kommen. Lokale Spitzen, die schnell verarbeitet werden, sind ebenfalls normal.
• Warnung: Eine konstante, nicht Null-Warteschlange, mit einem zunehmenden Trend bedeutet, dass Segment Tar die Zuweisungen bei der eingehenden Geschwindigkeit nicht verarbeiten kann. Es besteht das Risiko, dass die Warteschlange voll wird und neue Commits zurückgewiesen werden.
• HAFTUNGSAUSSCHLUSS: Eine vorübergehend volle Warteschlange (in der Spitze) ist auf einen intensiven Vorgang zurückzuführen (z. B. Replikation oder Rollout) oder hohen Datenverkehr. Stellen Sie daher sicher, dass Sie andere Ursachen ausschließen, bevor Sie das Segment-TAR als den Schuldigen diagnostizieren. Im Allgemeinen ist der Trend relevanter als lokale Spitzen.