Nach der Bereitstellung der AEM-Instanzen sind bestimmte Aufgaben erforderlich, um Betrieb, Leistung und Integrität zu überwachen und aufrechtzuerhalten.
Um potenzielle Probleme erkennen zu können, müssen Sie unbedingt wissen, wie Ihre Systeme unter normalen Bedingungen aussehen und sich verhalten. Dazu sollten Sie das System überwachen und über einen Zeitraum hinweg Daten erfassen.
Überprüfen Sie Folgendes | Besonderheiten | Kommentar/Aktionen |
---|---|---|
Backup-Plan. | Gehen Sie wie folgt vor, um ein Backup für Ihre Instanz zu erstellen. | |
Plan für die Notfallwiederherstellung | Richtlinien Ihres Unternehmens für die Notfallwiederherstellung. | |
Ein System zur Fehlersuche steht Ihnen für die Problemberichterstattung zur Verfügung. | Zum Beispiel Bugzilla, Jira oder eines von vielen anderen. | |
Dateisysteme werden überwacht. | Das CRX-Repository wird „eingeforen“, wenn nicht genügend freier Speicherplatz vorhanden ist. Es wird fortgesetzt, sobald Speicherplatz frei wird. | " *ERROR* LowDiskSpaceBlocker "-Meldungen können in der Protokolldatei angezeigt werden, wenn der freie Speicherplatz gering ist. |
Protokolldateien werden überwacht. | ||
Die Systemüberwachung wird (ständig) im Hintergrund ausgeführt. | Einschließlich CPU-, Arbeitsspeicher-, Festplatten- und Netzwerkauslastung. Verwendet wird z. B. iostat / vmstat / perfmon. | Protokollierte Daten werden angezeigt und können zum Nachverfolgen von Leistungsproblemen verwendet werden. Rohdaten sind ebenfalls verfügbar. |
Die AEM-Leistung wird überwacht. | Einschließlich Anfragezähler zur Überwachung des Traffic-Niveaus. | Bei großem oder anhaltendem Leistungsverlust sollte eine detaillierte Analyse erfolgen. |
Sie überwachen Ihre Replikationsagenten. | ||
Regelmäßige Bereinigung von Workflow-Instanzen. | Repository-Größe und Workflow-Leistung. | Siehe Regelmäßige Bereinigung von Workflow-Instanzen. |
Es hat sich bewährt, Backups für folgende Komponenten zu erstellen:
In Ihrem Unternehmen gibt es wahrscheinlich eine Sicherungsrichtlinie, die Sie einhalten müssen. Zusätzlich sollten Sie sich überlegen, welche Komponenten Sie wann sichern, z. B. anhand folgender Kriterien:
Oft werden in regelmäßigen Abständen (z. B. täglich, wöchentlich oder monatlich) vollständige Backups und zwischendurch (z. B. stündlich, täglich oder wöchentlich) inkrementelle Backups erstellt.
Wenn Sie Sicherungskopien der Produktionsinstanzen erstellt haben, müssen Sie Tests durchführen, um sicherzustellen, dass die Sicherungskopie erfolgreich wiederhergestellt werden kann.
Andernfalls ist das Backup womöglich nutzlos (im schlimmsten Fall).
Weitere Informationen zur Backup-Leistung finden Sie im Abschnitt Backup-Leistung.
Nach der Installation oder nach größeren Konfigurationsänderungen sollten Sie ein Backup der installierten Software erstellen.
Dazu müssen Sie erstein Backup des gesamten Repositorys erstellen und dann folgende Schritte ausführen:
<cq-installation-dir>
aus Ihrem Dateisystem.Falls Sie einen Anwendungsserver eines Drittanbieters verwenden, gibt es möglicherweise zusätzliche Ordner an anderen Speicherorten, die Sie ebenfalls sichern müssen. Informationen dazu, wie Sie Anwendungsserver installieren, finden Sie unter Installieren von AEM mit einem Anwendungsserver.
Das inkrementelle Sichern des Dateidatenspeichers wird unterstützt. Wenn Sie inkrementelle Backups anderer Komponenten (z. B. der Lucene-Indizes) erstellen möchten, stellen Sie sicher, dass gelöschte Dateien auch im Backup als gelöscht markiert sind.
Die Festplattenspiegelung kann als Sicherungsmethode eingesetzt werden.
Im Abschnitt Sicherung und Wiederherstellung der CRX-Dokumentation sind alle Aspekte der Sicherung des CRX-Repositorys abgedeckt.
Details zum Erstellen eines Hot-Backups im Online-Betrieb finden Sie unter Erstellen eines Online-Backups.
Das Tool Versionen bereinigen dient zum Bereinigen der Versionen eines Knotens oder einer Hierarchie von Knoten in Ihrem Repository. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.
In diesem Abschnitt werden die Wartungsaufgaben im Zusammenhang mit der Versionsfunktion von AEM behandelt. Mit dem Tool Versionsbereinigung können Sie Versionen eines Knotens oder eine Knotenhierarchie Ihres Repository bereinigen. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.
Das Tool Versionsbereinigung ist in der Tools-Konsole unter „Versionsverwaltung“ oder direkt unter folgender URL verfügbar:
https://<server>:<port>/etc/versioning/purge.html
Beginn PathEin absoluter Pfad, auf dem die Bereinigung durchgeführt werden muss. Sie können den Startpfadauswählen, indem Sie auf den Navigatorbaum im Repository klicken.
RekursivBeim Bereinigen von Daten können Sie zwischen der Ausführung des Vorgangs auf einer Node oder einer ganzen Hierarchie wählen, indem Sie Rekursiv auswählen. Im letzteren Fall definiert der angegebene Pfad den Stammknoten der Hierarchie.
Maximale Versionen, die beibehalten werden sollenDie maximale Anzahl von Versionen, die für einen Knoten beibehalten werden sollen. Wenn die Anzahl diesen Wert überschreitet, werden die ältesten Versionen gelöscht.
Maximales Alter der VersionDas maximale Alter der Version eines Knotens. Wenn das Alter einer Version diesen Wert überschreitet, wird sie gelöscht.
Dry RunDa das Entfernen von Inhaltsversionen definitiv ist und ohne Wiederherstellung einer Sicherung nicht rückgängig gemacht werden kann, stellt das Bereinigen-Werkzeug einen trockenen Ausführungsmodus bereit, mit dem Sie die bereinigten Versionen Vorschau haben. Klicken Sie auf Probelauf, um einen Probelauf des Bereinigungsvorgangs zu starten.
Bereinigen Bereinigen Sie die Bereinigung der Beginn auf dem Knoten, der durch den Pfad definiert wird.
Um Versionen einer Website zu löschen, gehen Sie folgendermaßen vor:
Navigieren Sie zur Tools-Konsole, wählen Sie „Versionsverwaltung“ aus und doppelklicken Sie auf „Versionen bereinigen“.
Legen Sie den Startpfad für den zu löschenden Inhalt fest (z. B. /content/geometrixx-outdoors
).
Legen Sie die maximale Anzahl von Versionen (für jeden Knoten) fest, die Sie beibehalten möchten. Lassen Sie das Feld frei, falls diese Einstellung nicht verwendet werden soll.
Legen Sie das maximale Versionsalter in Tagen (für jeden Knoten) fest, den Sie beibehalten möchten. Lassen Sie das Feld frei, falls diese Einstellung nicht verwendet werden soll.
Klicken Sie auf Probelauf, um eine Vorschau des Bereinigungsvorgangs anzuzeigen.
Klicken Sie auf Löschen, um den Vorgang zu starten.
Bereinigte Knoten können ohne Wiederherstellung des Repository nicht zurückgesetzt werden. Da eine fehlerfreie Konfiguration sehr wichtig ist, empfiehlt es sich, vor einer Bereinigung immer einen Probelauf durchzuführen.
Beim den Vorgängen Probelauf und Löschen werden alle Knoten aufgelistet, die verarbeitet werden. Während des Vorgangs kann ein Knoten einen der folgenden Statuswerte haben:
ignore (not versionnable)
: Der Knoten unterstützt keine Versionierung und wird während des Prozesses ignoriert.
ignore (no version)
: Für den Knoten sind keine Versionen vorhanden und er wird beim Bereinigungsvorgang ignoriert.
retained
: Der Knoten wurde nicht gelöscht.
purged
: die Node wird bereinigt.
Darüber hinaus stellt die Konsole nützliche Informationen zu den Versionen bereit:
V 1.0
: die Versionsnummer.
V 1.0.1
*: Der Stern gibt an, dass es sich um die aktuelle Version handelt.
Thu Mar 15 2012 08:37:32 GMT+0100
: Datum der Version.
Im folgenden ein Beispiel:
Auditdatensätze und Protokolldateien für Adobe Experience Manager (AEM) finden sich an diversen Speicherorten. Im Folgenden erhalten Sie einen Überblick, welche Dateien wo zu finden sind.
AEM WCM-System zeichnet detaillierte Protokolle auf. Wenn Sie Quickstart entpackt und gestartet haben, finden Sie Protokolle unter folgenden Pfaden:
<cq-installation-dir>/crx-quickstart/logs/
<cq-installation-dir>/crx-quickstart/repository/
Protokolldateirotation bezeichnet einen Vorgang, bei dem das Dateiwachstum durch das regelmäßige Erstellen einer neuen Datei beschränkt wird. In AEM wird die Protokolldatei error.log
täglich nach folgenden Regeln rotiert:
Die Datei error.log
wird entsprechend dem Muster {original_filename} .yyyy-MM-dd
umbenannt. Beispielsweise wird am 11. Juli 2010 die aktuelle Protokolldatei in error.log-2010-07-10
umbenannt und anschließend ein neuer error.og
erstellt.
Frühere Protokolldateien werden nicht gelöscht, daher ist es Ihre Verantwortung, alte Protokolldateien regelmäßig zu bereinigen, um die Datenträgernutzung zu begrenzen.
Wenn Sie Ihre AEM-Installation aktualisieren, verbleiben vorhandene Protokolldateien, die nicht mehr von AEM verwendet werden, auf der Festplatte. Sie können diese ohne Risiko löschen. Alle neuen Protokolleinträge werden in die neuen Protokolldateien geschrieben.
Diverse Protokolldateien werden auf dem Dateiserver gespeichert, auf dem Sie AEM installiert haben:
<cq-installation-dir>/crx-quickstart/logs
access.log
Hier werden alle Zugriffsanfragen an das AEM WCM-System und das Repository registriert.
audit.log
Moderationsaktionen werden hier registriert.
error.log
Hier werden Fehlermeldungen (mit unterschiedlichem Schweregrad) registriert.
ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
Dieses Protokoll wird nur verwendet, wenn es aktiviert Dynamic Media ist. Er enthält Statistiken und analytische Informationen, die zur Analyse des Verhaltens des internen ImageServer-Prozesses verwendet werden.
request.log
Hier werden alle Zugriffsanfragen zusammen mit der Antwort registriert.
s7access-<yyyy>-<mm>-<dd>.log
Dieses Protokoll wird nur verwendet, wenn es aktiviert Dynamic Media ist. Das s7access-Protokoll zeichnet jede Anforderung auf, die an Dynamic Media bis /is/image
und /is/content
gesendet wurde.
stderr.log
Enthält Fehlermeldungen (ebenfalls mit unterschiedlichem Schweregrad), die beim Starten generiert werden. Standardmäßig ist die Protokollierungsstufe auf
Warning
( WARN
)
stdout.log
Enthält Protokollmeldungen, die auf Ereignisse beim Starten verweisen.
upgrade.log
Bietet ein Protokoll aller Aktualisierungsvorgänge, die über die Variable
com.day.compat.codeupgrade
und com.adobe.cq.upgradesexecutor
Pakete.
<cq-installation-dir>/crx-quickstart/repository
revision.log
Die ImageServer- und s7access-Protokolle sind nicht im Download Full Package enthalten, das aus der system/console/status-bundlelist Seite generiert wurde. Wenn Sie Probleme mit Dynamic Media haben, hängen Sie bitte auch die ImageServer- und s7access-Protokolle an, wenn Sie den Kundensupport kontaktieren.
Die Standard-Protokollebene (Apache Sling-Protokollierungskonfiguration) ist „Information“, d. h. es werden keine Debugging-Meldungen protokolliert.
Um die Debugging-Protokollebene für eine Protokollierung zu aktivieren, müssen Sie für die Eigenschaften org.apache.sling.commons.log.level
im Repository den Wert „debug“ festlegen. Beispielsweise können Sie bei /libs/sling/config/org.apache.sling.commons.log.LogManager
das globale Apache Sling Logging](/docs/experience-manager-65/deploying/configuring/osgi-configuration-settings.html?lang=de#apacheslingloggingconfiguration) konfigurieren.[
Legen Sie für das Protokoll nur so lange wie erforderlich „debug“ fest, da eine große Anzahl an Protokolleinträgen erstellt wird, die Ressourcen verbrauchen.
Eine Zeile in der Debugging-Datei beginnt üblicherweise mit DEBUG, gefolgt von der Protokollebene, der Installationsaktion und der Protokollmeldung. Beispiel:
DEBUG 3 WebApp Panel: WebApp successfully deployed
Die Protokollebenen lauten wie folgt:
0 | Schwerwiegender Fehler | Die Aktion ist fehlgeschlagen und das Installationsprogramm kann nicht fortgesetzt werden. |
---|---|---|
1 | Fehler | Die Aktion ist fehlgeschlagen. Die Installation wird fortgesetzt, ein Teil des AEM WCM-Systems wird jedoch nicht richtig installiert und funktioniert nicht. |
2 | Warnung | Die Aktion war erfolgreich, stieß aber auf Probleme. Das AEM WCM-System funktioniert möglicherweise nicht ordnungsgemäß. |
3 | Informationen | Die Aktion war erfolgreich. |
Beim Arbeiten mit Adobe Experience Manager haben Sie mehrere Möglichkeiten, die Konfigurationseinstellungen für Dienste zu verwalten. Einzelheiten und empfohlene Vorgehensweisen finden Sie unter Konfigurieren von OSGi.
Unter bestimmten Umständen müssen Sie möglicherweise eine benutzerdefinierte Protokolldatei mit einer anderen Protokollebene erstellen. Gehen Sie dazu im Repository wie folgt vor:
Erstellen Sie, falls nicht bereits vorhanden, einen neuen Konfigurationsordner (sling:Folder
) für das Projekt /apps/<project-name>/config
.
Erstellen Sie unter /apps/<project-name>/config
einen Knoten für die neue Apache Sling Logging Logger-Konfiguration:
Name: org.apache.sling.commons.log.LogManager.factory.config-<identifier>
(da dies ein Logger ist)
wobei <identifier>
durch einen freien Text ersetzt wird, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information darf nicht weggelassen werden).
Beispiel: org.apache.sling.commons.log.LogManager.factory.config-MINE
Typ: sling:OsgiConfig
Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für <identifier>
einen eindeutigen Parameter zu verwenden.
Legen Sie die folgenden Eigenschaften des Knotens fest:
Name: org.apache.sling.commons.log.file
Typ: String
Wert: die Protokolldatei angeben; zum Beispiel logs/myLogFile.log
Name: org.apache.sling.commons.log.names
Typ: Zeichenfolge[] (Zeichenfolge + Multi)
Wert: Geben Sie die OSGi-Dienste an, für die die Protokollfunktion Meldungen protokollieren soll. zum Beispiel alle folgenden Elemente:
org.apache.sling
org.apache.felix
com.day
Name: org.apache.sling.commons.log.level
Typ: String
Wert: Geben Sie die erforderliche Protokollebene an ( debug
, info
, warn
oder error
); zum Beispiel debug
Konfigurieren Sie ggf. weitere Parameter:
Name: org.apache.sling.commons.log.pattern
Typ: String
Wert: das Muster der Protokollmeldung nach Bedarf angeben; zum Beispiel
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
org.apache.sling.commons.log.pattern
unterstützt bis zu sechs Argumente.
{0} Der Zeitstempel des Typs java.util.Date
{1} die Protokollmarkierung
{2} der Name des aktuellen Threads
{3} Name der Protokollfunktion
{4} die Protokollebene
{5} die Protokollmeldung
Falls der Protokollaufruf den Parameter Throwable
enthält, wird der StackTrace an die Meldung angefügt.
„org.apache.sling.commons.log.names“ muss einen Wert enthalten.
Die Protokollierungspfade sind vom Speicherort-crx-quickstart
abhängig.
Eine Protokolldatei wie:
logs/thelog.log
wird daher geschrieben in:
<cq-installation-dir>/crx-quickstart/logs/thelog.log
.
Und eine Protokolldatei wie:
../logs/thelog.log
wird in folgendes Verzeichnis geschrieben:
<cq-installation-dir>/logs/
(z. B. neben <cq-installation-dir>/crx-quickstart/
)
Dieser Schritt muss nur ausgeführt werden, wenn ein neuer Writer erforderlich ist (d. h. mit einer Konfiguration, die vom standardmäßigen Writer abweicht).
Eine neue Logging-Writer-Konfiguration ist nur erforderlich, wenn die vorhandene Standardkonfiguration nicht geeignet ist.
Wenn kein expliziter Writer konfiguriert ist, erstellt das System automatisch einen impliziten Writer auf Basis der Standardkonfiguration.
Erstellen Sie unter /apps/<project-name>/config
einen Knoten für die neue Apache Sling Logging Writer Configuration:
Name: org.apache.sling.commons.log.LogManager.factory.writer-<identifier>
(da dies ein Writer ist)
Wie beim Logger wird <identifier>
durch freien Text ersetzt, den Sie (müssen) eingeben, um die Instanz zu identifizieren (Sie können diese Informationen nicht weglassen). Beispiel: org.apache.sling.commons.log.LogManager.factory.writer-MINE
Typ: sling:OsgiConfig
Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für <identifier>
einen eindeutigen Parameter zu verwenden.
Legen Sie die folgenden Eigenschaften des Knotens fest:
Name: org.apache.sling.commons.log.file
Typ: String
Wert: Geben Sie die Protokolldatei so an, dass sie mit der im Protokollprogramm angegebenen Datei übereinstimmt.
für dieses Beispiel ../logs/myLogFile.log
.
Konfigurieren Sie ggf. weitere Parameter:
Name: org.apache.sling.commons.log.file.number
Typ: Long
Wert: die Anzahl der zu speichernden Protokolldateien angeben; zum Beispiel 5
Name: org.apache.sling.commons.log.file.size
Typ: String
Wert: müssen Sie die Dateidrehung nach Größe/Datum steuern. zum Beispiel '.'yyyy-MM-dd
org.apache.sling.commons.log.file.size
steuert die Rotation der Protokolldatei durch eine der folgenden Einstellungen:
um anzugeben, wann eine neue Datei erstellt wird (und die vorhandene Datei gemäß dem Namensmuster umbenannt wird).
KB
, MB
oder GB
(Groß-/Kleinschreibung wird ignoriert).java.util.SimpleDateFormat
-Muster angeben. Dieser gibt den Zeitraum an, in dem die Datei rotiert wird, sowie das Suffix, das an die rotierte Datei angehängt wurde (zur einfachen Identifizierung).Der Standardwert lautet '.'yyyy-MM-dd (für die tägliche Protokollrotation).
So wird beispielsweise um Mitternacht am 20. Januar 2010 (oder sobald die erste Protokollmeldung nach diesem Zeitpunkt ausgegeben wird), …/logs/error.log in …/logs/error.log.2010-01-20 umbenannt. Die Protokollierung für den 21. Januar erfolgt in (ein neues und leeres) …/logs/error.log und geht bei der nächsten Änderung zum nächsten Datum über.
'.'yyyy-MM |
Rotation zu Beginn jedes Monats |
---|---|
'.'yyyy-ww |
Rotation am ersten Wochentag (abhängig vom Gebietsschema). |
'.'yyyy-MM-dd |
Rotation jeden Tag um Mitternacht. |
'.'yyyy-MM-dd-a |
Rotation jeden Tages um Mitternacht und Mittag. |
'.'yyyy-MM-dd-HH |
Rotation am Anfang jeder Stunde. |
'.'yyyy-MM-dd-HH-mm |
Rotation am Anfang jeder Minute. |
Hinweis: Bei der Angabe einer Uhrzeit/eines Datums ist Folgendes zu beachten:
Dadurch soll verhindert werden, dass bestimmte Zeichen als Musterbuchstaben interpretiert werden.
Lesen Sie die neue Protokolldatei mit dem von Ihnen ausgewählten Tool.
Die mit diesem Beispiel erstellte Protokolldatei lautet ../crx-quickstart/logs/myLogFile.log
.
Die Felix-Konsole enthält auch Informationen zum Sling Log-Support unter ../system/console/slinglog
; beispielsweise https://localhost:4502/system/console/slinglog
.
Auditdatensätze werden als Nachweis darüber aufbewahrt, wer wann welche Aktion vorgenommen hat. Verschiedene Auditdatensätze werden für das AEM WCM-System und OSGi-Ereignisse generiert.
Öffnen Sie eine Seite.
Wählen Sie im Seitenmenü die Registerkarte mit dem Sperrsymbol aus und doppelklicken Sie auf Auditprotokoll…
Ein neues Fenster wird geöffnet, in dem die Liste der Auditdatensätze für die aktuelle Seite angezeigt werden.
Klicken Sie auf OK, wenn Sie das Fenster schließen möchten.
Innerhalb des Ordners /var/audit
werden die Prüfaufzeichnungen gemäß der Ressource gespeichert. Sie können ein Drilldown durchführen, bis einzelne Datensätze und die darin enthaltenen Informationen angezeigt werden.
Diese Einträge enthalten die gleichen Informationen wie sie beim Bearbeiten einer Seite angezeigt werden.
OSGi-Ereignisse generieren ebenfalls Auditdatensätze, die Sie in der AEM-Web-Konsole auf der Registerkarte Konfigurationsstatus unter Protokolldateien anzeigen können:
Sie können Replikations-Warteschlangen darauf überwachen, ob eine Warteschlange ausgefallen oder gesperrt ist. Dies kann wiederum auf ein Problem mit einer Veröffentlichungsinstanz oder einem externen System hinweisen:
Sind alle erforderlichen Warteschlangen aktiviert?
Sind alle deaktivierten Warteschlangen noch erforderlich?
alle enabled
-Warteschlangen müssen den Status idle
oder active
haben, der den normalen Betrieb angibt; keine Warteschlangen sollten blocked
sein, was häufig ein Zeichen für Probleme auf der Empfängerseite ist.
Wenn die Warteschlange im Laufe der Zeit größer wird, kann dies auf eine Blockierung hindeuten.
Gehen Sie wie folgt vor, um Replikationsagenten zu überwachen:
Wechseln Sie in AEM zur Registerkarte Tools.
Klicken Sie auf Replikation.
Doppelklicken Sie auf den Link zu den Agenten für die jeweilige Umgebung (entweder der linke oder der rechte Fensterbereich); z. B.Agenten für Autor.
Das daraufhin angezeigte Fenster gibt einen Überblick über alle Replikationsagenten für die Autorenumgebung, einschließlich ihrer Ziele und Status.
Klicken Sie auf den jeweiligen Agenten (der als Link dargestellt ist), um detaillierte Informationen zu diesem Agenten anzuzeigen:
Folgende Informationen/Optionen sind verfügbar:
Ob der Agent aktiviert ist.
Das Ziel einer beliebigen Replikation.
Ob die Replikations-Warteschlange derzeit aktiv (aktiviert) ist.
Ob die Warteschlange Elemente enthält.
Aktualisieren oder Löschen zum Aktualisieren der angezeigten Elemente in der Warteschlange. Mit diesen Optionen können Sie Elemente anzeigen, die in die Warteschlange gestellt werden oder diese verlassen.
Protokoll anzeigen für den Zugriff auf das Protokoll beliebiger Aktionen des Replikationsagenten.
Verbindung testen zum Testen der Verbindung mit der Zielinstanz.
Erneuten Versuch erzwingen, um einen erneuten Versuch auf beliebigen Elementen der Warteschlange zu erzwingen, falls erforderlich.
Verwenden Sie den Link „Verbindung testen“ nicht für den Postausgang der Rückwärtsreplikation auf der Veröffentlichungsinstanz.
Falls Sie eine Replikation für eine Warteschlange in einem Postausgang testen, werden alle Elemente, die älter als die Testreplikation sind, bei jeder Rückwärtsreplikation erneut verarbeitet.
Wenn solche Elemente bereits in einer Warteschlange vorhanden sind, können Sie mit der folgenden XPath JCR-Abfrage danach suchen und diese entfernen.
/jcr:root/var/replication/outbox/*[@cq:repActionType='TEST']
Nochmals können Sie eine Lösung entwickeln, um alle Replizierungsagenten (unter /etc/replication/author
oder /etc/replication/publish
) zu erkennen, und dann den Status des Agenten ( enabled
, disabled
) und die zugrunde liegende Warteschlange ( active
, idle
, blocked
) überprüfen.
Die Leistungsoptimierung ist ein interaktiver Vorgang, der bei der Entwicklung Priorität hat. Im Anschluss an die Bereitstellung wird die Leistung nach bestimmten Intervallen oder Ereignissen überprüft.
Die für das Erfassen von Informationen eingesetzten Methoden können auch zur kontinuierlichen Überwachung verwendet werden.
Spezifische Konfigurationen, die die Leistung verbessern, können ebenfalls überprüft werden.
Nachfolgend finden Sie eine Liste mit häufigen Leistungsproblemen und Vorschlägen, wie Sie diese erkennen und beheben.
Bereich | Symptom(e) | So steigern Sie Kapazitäten: | So reduzieren Sie Mengen: |
---|---|---|---|
Client | Hohe Auslastung der CPU durch den Client. | Installieren Sie eine Client-CPU mit höherer Leistung. | Vereinfachen Sie das (HTML-)Layout. |
Geringe CPU-Auslastung des Servers. | Aktualisieren Sie auf einen schnelleren Browser. | Optimieren Sie den Client-seitigen Cache. | |
Einige Clients sind schnell, andere langsamer. | |||
Server | |||
Netzwerk | Geringe CPU-Auslastung sowohl auf Servern als auch auf Clients. | Beseitigen Sie eventuelle Netzwerkengpässe. | Verbessern/optimieren Sie die Konfiguration des Client-Cache. |
Die lokale Suche auf dem Server ist (vergleichsweise) schnell. | Vergrößern Sie die Netzwerkbandbreite. | Verringern Sie das „Gewicht“ Ihrer Website (z. B. weniger Bilder, optimiertes HTML). | |
Webserver | Die CPU-Auslastung auf dem Webserver ist hoch. | Erstellen Sie Webserver-Cluster. | Reduzieren Sie die Treffer pro Seite (Aufruf). |
Verwenden Sie einen Hardware Load Balancer. | |||
Anwendung | Die CPU-Auslastung des Servers ist hoch. | Erstellen Sie Cluster Ihrer AEM-Instanzen. | Suchen Sie nach und beseitigen Sie CPU- und Arbeitsspeicherverschwendung (durch Überprüfung von Code, zeitliche Planung von Ausgaben usw.). |
Hoher Speicherverbrauch. | Verbessern Sie das Zwischenspeichern auf allen Ebenen. | ||
Kurze Antwortzeiten. | Optimieren Sie Vorlagen und Komponenten (z. B. Struktur, Logik). | ||
Repository | |||
Cache |
Leistungsprobleme können eine Reihe von Ursachen haben, die nichts mit Ihrer Website zu tun haben, z. B. eine vorübergehend langsamere Verbindungsgeschwindigkeit, CPU-Auslastung und vieles mehr.
Sie können sich auf alle Besucher oder nur bestimmte Benutzergruppen auswirken.
All diese Informationen müssen erfasst, sortiert und analysiert werden, bevor Sie die allgemeine Leistung optimieren oder gezielt Probleme lösen können.
Bevor es zu einem Leistungsproblem kommt:
Wenn es zu einem Leistungsproblem kommt:
Versuchen Sie, das Problem mit einem (oder vorzugsweise mehr als einem) Standard-Webbrowser, auf einem anderen leistungsstarken Client oder, falls möglich, direkt auf dem Server zu replizieren.
Überprüfen Sie, ob (am System) in einem bestimmten Zeitraum Änderungen aufgetreten sind und ob diese Änderungen die Leistung beeinträchtigen können.
Stellen Sie Fragen wie:
Sammeln Sie so viele Informationen wie möglich, um diese mit den Information zu vergleichen, die Sie zum System unter normalen Bedingungen haben:
Im Folgenden finden Sie einen kurzen Überblick über Tools, mit denen Sie die Leistung überwachen und analysieren können.
Einige von diesen sind von Ihrem Betriebssystem abhängig.
Tool | Zur Analyse genutzt: | Verwendung/Weitere Informationen: |
request.log | Antwortzeiten und parallele Verarbeitung. | Interpretieren von request.log. |
truss/strace | Seitenladenvorgänge | Unix-/Linux-Befehle zur Verfolgung von Systemaufrufen und Signalen. Erhöhen Sie die Protokollebene auf Analysieren Sie die Seitenladefrequenz pro Anforderung, welche Seiten geladen wurden usw. |
Thread-Dumps | Beobachten Sie die JVM-Threads. Identifizieren Sie Konflikte, Sperren und lange Ausführungszeiten. | Abhängig vom Betriebssystem: Analyse-Tools sind ebenso verfügbar, wie zum Beispiel TDA. |
Heap-Dumps | Probleme mit dem Speicher, die zu Leistungsverlusten führen. | hinzufügen Sie die Option: Siehe Anleitung zur Fehlersuche für Java SE 6 with HotSpot VM. |
Systemaufrufe | Erkennen von Zeitproblemen. | Aufrufe von Hinweis: Diese sollten implementiert werden, damit sie bei Bedarf aktiviert/deaktiviert werden können. Wenn ein System reibungslos läuft, können Sie den Mehraufwand für das Erfassen von Statistiken vermeiden. |
Apache Bench | Identifizieren Sie Speicherlecks, analysieren Sie selektiv Reaktionszeiten. | Grundlegende Verwendung:
Ausführliche Informationen finden Sie unter Apache Bench und ab man page. |
Rechercheanalyse | Führen Sie Suchabfragen offline aus, ermitteln Sie die Antwortzeit der Abfrage, testen und bestätigen Sie den Ergebnissatz. |
|
JMeter | Last- und Funktionstest. | https://jakarta.apache.org/jmeter/ |
JProfiler | Detaillierte CPU- und Speicherprofilerstellung. | https://www.ej-technologies.com/ |
JConsole | Beobachten Sie JVM-Metriken und -Threads. | Verwendungszweck: jconsole Siehe jconsole und Leistungsüberwachung mit JConsole. Hinweis: Bei JDK 1.6 ist JConsole durch Plug-ins erweiterbar; z. B. Top oder TDA (Thread Dump Analyzer). |
Java VisualVM | Beobachten Sie JVM-Metriken, Threads, Arbeitsspeicher und Profiling. | Verwendungszweck: jvisualvm oder visualvm Siehe jvisualvm, visualvm und Leistungsüberwachung mit (J)VisualVM. Hinweis: Bei JDK 1.6 ist VisualVM durch Plug-ins erweiterbar. |
truss/strace, Isof | Detaillierter Kernelaufruf und Prozessanalyse (Unix). | Unix-/Linux-Befehle. |
Zeitstatistiken | Siehe Zeitstatistiken für das Laden von Seiten. | Zum Anzeigen der Zeitstatistiken für die Seitenwiedergabe können Sie Strg-Umschalt-U zusammen mit |
CPU- und Speicher-Profiling-Tool |
Wird für die Analyse langsamer Anfragen während der Entwicklung verwendet. | Zum Beispiel YourKit. |
Informationserfassung | Der aktuelle Stand Ihrer Installation. | Wenn Sie möglichst viel über Ihre Installation wissen, kann Ihnen dies unter Umständen helfen, die Ursache für die Leistungsänderung herauszufinden und ob diese Änderungen sich begründen lassen. Diese Metriken müssen in regelmäßigen Abständen erfasst werden, sodass Sie signifikante Änderungen sofort sehen. |
In dieser Datei werden grundlegende Informationen zu allen Anforderungen an AEM registriert. Sie können daraus wertvolle Schlüsse ziehen.
request.log
ist eine integrierte Möglichkeit, herauszufinden, wie lange Anforderungen brauchen. Zu Entwicklungszwecken ist es hilfreich, den Befehl tail -f
auf request.log
anzuwenden und nach langen Systemreaktionen zu suchen. Für das Analysieren einer größeren request.log
empfiehlt sich die Verwendung von rlog.jar
, damit Sie nach Systemreaktionszeiten filtern und diese sortieren können.
Es wird empfohlen, „langsame“ Seiten aus request.log
zu isolieren und einzeln für eine bessere Leistung zu optimieren. Dazu können Sie Leistungsmetriken pro Komponente oder ein Leistungprofil-Tool wie [yourkit](https://www.yourkit.com/)
verwenden.
Im Anforderungsprotokoll werden alle Anfragen zusammen mit der jeweiligen Antwort registriert:
09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms
Durch Addieren aller GET-Einträge über einen bestimmten Zeitraum (z. B. über mehrere 24-Stunden-Zeiträume) erhalten Sie aussagekräftige Informationen zum durchschnittlichen Traffic auf Ihrer Website.
Ein guter Ausgangspunkt für Leistungsanalysen ist das Anforderungsprotokoll:
<cq-installation-dir>/crx-quickstart/logs/request.log
Das Protokoll sieht wie folgt aus (die Zeilen sind der Einfachheit halber gekürzt):
31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms
Dieses Protokoll enthält eine Zeile pro Anforderung oder Antwort mit:
dem Datum, an dem jede Anforderung oder Antwort erfolgte;
der Anzahl an Anforderungen, in eckigen Klammern; deren Zahl mit der Anfrage und der Antwort übereinstimmt;
einem Pfeil, der angibt, ob es sich um eine Anfrage (Pfeil nach rechts) oder eine Antwort (Pfeil nach links) handelt.
Bei Anforderungen enthält die Zeile:
Bei Antworten enthält die Zeile:
Anhand von kleinen Skripts können Sie die erforderlichen Informationen aus der Protokolldatei extrahieren und die gewünschten Statistiken erstellen. Daraus können Sie ersehen, welche Seiten oder Seitentypen langsam reagieren und ob die Gesamtleistung zufriedenstellend ist.
Suchanforderungen werden ebenfalls in der Protokolldatei registriert:
31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms
Wie oben bereits erwähnt, können Sie Skripts verwenden, um relevante Informationen zu extrahieren und Statistiken zu erstellen.
Wenn Sie die Antwortzeit bestimmt haben, müssen Sie möglicherweise analysieren, warum die Anforderung diese Zeit benötigt und wie sie diese verbessern können.
Sie können request.log
verwenden, um die gleichzeitige Nutzung und die Systemreaktion darauf zu überwachen.
Sie sollten testen, wie viele gleichzeitige Benutzer das System unterstützt, bevor es zu Leistungseinbußen kommt. Auch hier können Skripts verwendet werden, um die Ergebnisse aus der Protokolldatei zu extrahieren:
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms
AEM enthält verschiedene Hilfstools unter:
<cq-installation-dir>/crx-quickstart/opt/helpers
Eines dieser Tools, rlog.jar
, kann zum schnellen Sortieren von request.log
verwendet werden, sodass Anforderungen nach Dauer (längste bis kürzeste Zeit) angezeigt werden.
Der folgende Befehl zeigt die möglichen Argumente:
$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
java -jar rlog.jar [options] <filename>
Options:
-h Prints this usage.
-n <maxResults> Limits output to <maxResults> lines.
-m <maxRequests> Limits input to <maxRequest> requests.
-xdev Exclude POST request to CRXDE.
Beispielsweise können Sie das Tool mit der request.log
-Datei als Parameter ausführen und die ersten 10 Anforderungen mit der längsten Dauer anzeigen:
$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
Möglicherweise müssen Sie die einzelnen request.log
-Dateien verketten, falls Sie diesen Vorgang auf ein großes Datenbeispiel anwenden möchten.
Um die Auswirkungen von Sonderfällen (z. B. Bereinigung usw.) zu minimieren, wird empfohlen, ein Tool wie apachebench
zu verwenden (siehe z. B. die ab-Dokumentation), um Speicherlecks zu identifizieren und Antwortzeiten selektiv zu analysieren.
Apache Bench kann wie folgt verwendet werden:
$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503
Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes
Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106
Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)
Die obigen Zahlen stammen von einem MacBook Pro-Laptop (Mitte 2010), der auf die Unternehmensseite von Geometrixx zugreift, wie sie in einer Standardinstallation von AEM enthalten ist. Die Seite ist sehr einfach aufgebaut, aber nicht für Leistung optimiert.
apachebench
zeigt auch die Zeit pro Anforderung als Mittelwert für alle gleichzeitigen Anforderungen an; see Time per request: 54.595 [ms]
(Mittelwert für alle gleichzeitigen Anforderungen). Sie können den Wert des Gleichzeitigkeitsparameters -c
(Anzahl der gleichzeitig auszuführenden Anforderungen) ändern, um eventuelle Effekte anzuzeigen.
Informationen zum Anforderungs-Traffic (Anzahl der Anforderungen in einem bestimmten Zeitraum) geben Ihnen Aufschluss über die Last auf der Instanz. Sie können diese Informationen aus request.log extrahieren. Mit Zählern können Sie Daten jedoch automatisch erfassen und Folgendes analysieren:
Um die Datenerfassung zu automatisieren, können Sie auch Anforderungsfilter installieren, sodass ein Zähler bei jeder Anforderung erhöht wird. Mehrere Zähler können für verschiedene Zeiträume verwendet werden.
Informationen können erfasst werden, um Folgendes anzuzeigen:
Es wird empfohlen, dass jedes Projekt für die Serverleistung html comments
enthält. Es gibt viele gute Beispiele. Öffnen Sie eine Seite, zeigen Sie den Quelltext an und scrollen Sie zum Ende, dann wird ein Code wie der Folgende angezeigt:
</body>
</html>
<!--
Page took 58 milliseconds to be rendered by server
-->
Der Tool-Befehl jconsole
ist bei JDK verfügbar.
Starten Sie Ihre AEM-Instanz.
Ausführen jconsole.
Wählen Sie Ihre AEM-Instanz und Verbinden.
Klicken Sie in der Anwendung Local
bei Dublette-Klick auf com.day.crx.quickstart.Main
; Die Übersicht wird standardmäßig angezeigt:
Anschließend können Sie weitere Optionen auswählen.
Ab JDK 1.6 ist der Tool-Befehl jvisualvm
verfügbar. Wenn Sie JDK 1.6 installiert haben, können Sie folgende Schritte ausführen:
Starten Sie Ihre AEM-Instanz.
Bei Verwendung von Java 5 können Sie das -Dcom.sun.management.jmxremote
-Argument zur Java-Befehlszeile hinzufügen, die Ihre JVM Beginn. JMX ist bei Java 6 standardmäßig aktiviert.
Führen Sie einen der beiden Befehle aus:
jvisualvm
: im Ordner „bin“ von JDK 1.6 (getestete Version)visualvm
: kann von VisualVM heruntergeladen werden (allerneueste Version)Klicken Sie in der Anwendung Local
bei Dublette-Klick auf com.day.crx.quickstart.Main
; Die Übersicht wird standardmäßig angezeigt:
Danach können Sie noch weitere Optionen, einschließlich „Monitor“ auswählen:
Sie können dieses Tool zum Generieren von Thread-Dumps und Heap-Dump Speicherabbildern verwenden. Diese Informationen werden häufig vom technischen Support-Team angefordert.
Wenn Sie möglichst viele Informationen zur Installation haben, ist es einfacher herauszufinden, was die Leistungsänderung verursacht hat und ob diese Änderungen gerechtfertigt sind. Diese Metriken müssen in regelmäßigen Abständen erfasst werden, sodass Sie signifikante Änderungen sofort sehen.
Die folgenden Informationen können hilfreich sein:
Um die Anzahl der Autoren anzuzeigen, die das System seit der Installation verwendet haben, verwenden Sie folgende Befehlszeile:
cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l
Um die Anzahl der Autoren anzuzeigen, die an einem bestimmten Tag mit dem System arbeiten, verwenden Sie:
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l
Um die Gesamtzahl der Seitenaktivierungen ab der Serverinstallation anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:
Typ XPath
Pfad /
Abfrage /element(*, cq:AuditEvent)[@cq:type='Activate']
Ermitteln Sie die Anzahl der Tage seit der Installation, um den Durchschnitt zu berechnen.
Um die Anzahl der aktuellen Seiten auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:
Typ XPath
Pfad /
Abfrage /element(*, cq:Page)
Um die Gesamtzahl der Rollouts ab der Installation anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:
Typ XPath
Pfad /
Abfrage /element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
Ermitteln Sie die Anzahl der Monate seit der Installation, um den Durchschnitt zu berechnen.
Um die Gesamtzahl der Live Copies ab der Installation anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:
Typ XPath
Pfad /
Abfrage /element(*, cq:LiveSyncConfig)
Ermitteln Sie erneut die Anzahl der Monate seit der Installation, um den Durchschnitt zu berechnen.
Um anzuzeigen, wie viele DAM-Assets Sie derzeit unterhalten, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:
XPath
/
/jcr:root/content/dam/element(*, dam:Asset)
So bestimmen Sie die Gesamtgröße des Ordners /var/dam
:
Verwenden Sie WebDAV, um das Repository dem lokalen Dateisystem zuzuordnen.
Verwenden Sie folgende Befehlszeile:
cd /Volumes/localhost/var
du -sh dam/
Um die durchschnittliche Größe abzurufen, teilen Sie die globale Größe durch die Gesamtanzahl der Assets in /var/dam
(siehe oben).
Um die Anzahl der aktuellen Vorlagen auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:
XPath
/
/element(*, cq:Template)
Um die Anzahl der aktuellen Komponenten auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:
XPath
/
/element(*, cq:Component)
Bestimmen Sie die Anforderungen pro Stunde auf dem Autorensystem zu Spitzenzeiten:
Um die Gesamtzahl der Anforderungen seit der Installation zu ermitteln, verwenden Sie folgende Befehlszeile:
cd <cq-installation-dir>/crx-quickstart/logs
grep -R "\->" request.log | wc -l
Um die Start- und Enddaten zu ermitteln, verwenden Sie:
vim request.log
G / 1G: for the last/first lines
Verwenden Sie diese Werte, um die Anzahl der Stunden seit der Installation und dann die durchschnittliche Anzahl der Anforderungen pro Stunde zu berechnen.
Wiederholen Sie die obigen Schritte auf der Veröffentlichungsinstanz.
Im Folgenden finden Sie eine Liste mit Vorschlägen, was Sie überprüfen sollten, falls Sie gewisse Leistungsprobleme bemerken. Die Liste ist (leider) nicht vollständig.
In folgenden Artikeln finden Sie weitere Informationen:
Wenn die CPU-Auslastung des Systems ständig bei 100 % liegt, sehen Sie in folgender Dokumentation nach:
Wissensdatenbank:
Fehler dieser Art sollten zwar bereits bei der Entwicklung und beim Testen bemerkt werden, können aber in bestimmten Szenarien übersehen werden.
Falls das System nicht genügend Speicher hat, kann sich dies auf verschiedene Weise bemerkbar machen, u. a. durch Leistungsbeeinträchtigungen und Fehlermeldungen mit folgendem Subtext:
java.lang.OutOfMemoryError
In diesen Fällen müssen Sie Folgendes überprüfen:
Die für Beginn AEM verwendeten JVM-Einstellungen
Wissensdatenbank:
Falls das System keine Festplattenkapazität mehr hat oder Sie Festplatten-Trashing bemerken, überprüfen Sie Folgendes:
Haben Sie die Erfassung von Debugging-Daten deaktiviert? Diese Option kann in verschiedenen Komponenten konfiguriert werden, u. a.:
Haben Sie die Versionsbereinigung deaktiviert?
Wissensdatenbank:
Falls Sie nach jedem Neustart (ggf. eine Woche oder mehr nach dem Neustart) eine Leistungsverschlechterung der Instanz bemerken, können Sie Folgendes überprüfen:
Wissensdatenbank:
Java Virtual Machine (JVM) ist im Hinblick auf die Optimierung sehr verbessert worden (insbesondere seit Java 7). Daher sind eine vernünftige feste JVM-Größe und die Verwendung der Standardeinstellungen oft ausreichend.
Falls die Standardeinstellungen nicht geeignet sind, ist es wichtig, eine Methode festzulegen, um die GC-Leistung zu überwachen und zu bewerten, bevor Sie JVM optimieren. Überprüfen Sie z. B. Faktoren wie die Heap-Größe, Algorithmen und dergleichen.
Einige der Optionen sind:
VerboseGC:
-verbose:gc \
-Xloggc:$LOGS/verbosegc.log \
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps
Das entsprechende Protokoll kann mit einem GC-Visualizer erfasst werden:
[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)
Oder mit JConsole:
Diese Einstellungen gelten für eine "breite"JMX-Verbindung:
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8889 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false
Schließen Sie dann die JVM mit der JConsole an. siehe:
[https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)
Dies ist hilfreich, wenn Sie herausfinden möchten, wie viel Arbeitsspeicher belegt ist, welche GC-Algorithmen verwendet werden, wie lange diese ausgeführt werden und welche Auswirkung dies auf die Anwendungsleistung hat. Andernfalls ist die Abstimmung nur "zufällig drehende Knopf".
Informationen zu Oracle VM finden Sie unter:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html