Sie sehen sich Hilfeinhalte der folgenden Version an:

Nach der Bereitstellung der CQ-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 wissen, wie Ihre Systeme unter normalen Bedingungen aussehen und sich verhalten. Dazu sollten Sie das System überwachen und über einen Zeitraum hinweg Daten erfassen.

Prüfung Überlegungen Kommentar/Aktionen
Sicherungsplan.   Lesen Sie die Informationen unter Sichern der CQ-Instanz.
Plan für die Notfallwiederherstellung. Richtlinien Ihres Unternehmens für die Notfallwiederherstellung.  
Ein Fehlernachverfolgungssystem ist für das Melden von Problemen verfügbar. Beispielsweise bugzilla, jira oder viele andere.  
Dateisysteme werden überwacht. Das CRX-Repository stürzt ab, wenn kein ausreichender Festplattenspeicher vorhanden ist. Es wird fortgesetzt, sobald Speicherplatz frei wird. "*ERROR* LowDiskSpaceBlocker"-Meldungen werden in der Protokolldatei angezeigt, wenn der Speicherplatz gering ist.
Protokolldateien werden überwacht.    
Systemüberwachung läuft (konstant) im Hintergrund. 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.
CQ-Performance wird überwacht. Einschließlich Anforderungszähler zum Überwachen von Traffic-Volumen. Bei großem oder anhaltendem Leistungsverlust sollte eine detaillierte Analyse erfolgen.
Sie überwachen Ihre Replikationsagenten.    
Workflow-Instanzen regelmäßig löschen. Repository-Größe und Workflow-Leistung. Siehe Regelmäßiges Löschen von Workflow-Instanzen.

Sicherungskopien

Es hat sich bewährt, Sicherungskopien folgender Komponenten zu erstellen:

  • Der installierten Software: vor/nach wichtigen Konfigurationsänderungen
  • Des Repository-Inhalts: regelmäßig

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:

  • Wie wichtig das System und die Daten sind
  • Wie oft Änderungen an der Software oder an den Daten vorgenommen werden
  • Datenmenge; Kapazität kann u. U. ein Problem sein, ebenso die für das Erstellen von Sicherungskopien benötigte Zeit
  • Ob die Sicherung durchgeführt werden kann, während Benutzer online sind, und welche Auswirkungen auf die Leistung zu erwarten sind
  • Die geografische Verteilung von Benutzern. Wann ist z. B. die beste Zeit für die Sicherung (um Auswirkungen so gering wie möglich zu halten)?
  • Die Richtlinie Ihres Unternehmens für die Notfallwiederherstellung. Es gibt Richtlinien, wo gesicherte Daten gespeichert werden müssen (z. B. an externen Standorten, auf bestimmten Medien und dergleichen).

Oft werden eine vollständige Sicherungskopie in regelmäßigen Abständen (z. B. täglich, wöchentlich oder monatlich) und inkrementelle Sicherungskopien zwischendurch erstellt (z. B. stündlich, täglich oder wöchentlich).

Vorsicht:

Wenn Sie Sicherungskopien der Produktionsinstanzen erstellt haben, müssen Sie Tests durchführen, um sicherzustellen, dass die Sicherungskopie erfolgreich wiederhergestellt werden kann.

Andernfalls ist die Sicherungskopie womöglich nutzlos (im schlimmsten Fall).

Hinweis:

Weitere Informationen zur Leistung von Sicherungskopien finden Sie im Abschnitt Leistung von Sicherungskopien.

Erstellen einer Sicherungskopie der installierten Software

Nach der Installation oder nach größeren Konfigurationsänderungen sollten Sie eine Sicherungskopie der installierten Software erstellen.

Dazu müssen Sie eine Sicherungskopie des gesamten Repositorys erstellen und dann wie folgt vorgehen:

  1. Beenden Sie CQ.

  2. Erstellen Sie eine Sicherungskopie des gesamten CQ-Installationsverzeichnisses vom Dateisystem aus.

Vorsicht:

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.

Vorsicht:

Das inkrementelle Sichern des Dateidatenspeichers wird unterstützt. Wenn Sie inkrementelle Sicherungskopien anderer Komponenten (z. B. der Lucene-Indizes) erstellen möchten, stellen Sie sicher, dass gelöschte Dateien auch in der Sicherungskopie als gelöscht markiert sind.

Hinweis:

Die Festplattenspiegelung kann als Sicherungsmethode eingesetzt werden.

Erstellen einer Sicherungskopie des Repositorys

Im Abschnitt Sicherung und Wiederherstellung der CRX-Dokumentation sind alle Aspekte der Sicherung des CRX-Repositorys abgedeckt.

Details zum Erstellen einer Hot-Sicherungskopie im Online-Betrieb finden Sie unter Erstellen einer Online-Sicherungskopie.

Versionsbereinigung

Mit dem Tool für die Versionsbereinigung können Sie Versionen eines Knotens oder eine Knotenhierarchie im Repository bereinigen. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.

In diesem Abschnitt werden die Wartungsaufgaben im Hinblick auf die Versionsfunktion von CQ behandelt. Mit dem Tool für die Versionsbereinigung können Sie Versionen eines Knotens oder eine Knotenhierarchie im Repository bereinigen. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.

Überblick

Das Tool für die Versionsbereinigung ist in der Tools-Konsole unter Versioning oder direkt unter folgender URL verfügbar:

http://<Server>:<Port>/etc/versioning/purge.html

screen_shot_2012-03-15at14418pm

Startpfad

Ein absoluter Pfad, an dem die Bereinigung ausgeführt werden muss. Sie können den Startpfad auswählen, indem Sie im Navigator der Repository-Struktur klicken.

Rekursiv

Wenn Sie Daten bereinigen, können Sie den Vorgang an einem Knoten oder in der ganzen Hierarchie ausführen. Aktivieren Sie hierfür die Option Rekursiv. Im letzteren Fall definiert der angegebene Pfad den Stammknoten der Hierarchie.

Maximale Anzahl der zu speichernden Versionen

Die maximale Anzahl der Versionen, die für einen Knoten beibehalten werden sollen. Wenn die Anzahl diesen Wert überschreitet, werden die ältesten Versionen gelöscht.

Maximales Versionsalter

Das Höchstalter der Version eines Knotens. Wenn das Alter einer Version diesen Wert überschreitet, wird sie gelöscht.

Probelauf

Da das Entfernen von Versionen endgültig ist und nur durch Wiederherstellen einer Sicherungskopie rückgängig gemacht werden kann, ist beim Tool für die Versionsbereinigung ein Probelauf-Modus verfügbar, in dem Sie eine Vorschau der bereinigten Versionen anzeigen können. Um einen Probelauf des Bereinigungsvorgangs zu starten, klicken Sie auf Probelauf.

Bereinigen

Starten Sie das Bereinigen der Versionen auf dem Knoten, der durch den Startpfad definiert ist.

Bereinigen von Versionen einer Website

Um Versionen einer Website zu löschen, gehen Sie wie folgt vor:

  1. Navigieren Sie zur Tools-Konsole, wählen Sie Versioning aus und doppelklicken Sie auf Versionen bereinigen.

  2. Legen Sie den Startpfad für den zu löschenden Inhalt fest (z. B. /content/geometrixx-outdoors).

    • Falls Sie nur den durch den Pfad definierten Knoten löschen möchten, deaktivieren Sie die Option Rekursiv.
    • Falls Sie den durch den Pfad definierten Knoten und alle untergeordneten Knoten löschen möchten, aktivieren Sie die Option Rekursiv.
  3. 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.

  4. 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.

  5. Klicken Sie auf Probelauf, um eine Vorschau des Bereinigungsvorgangs anzuzeigen.

  6. Klicken Sie auf Löschen, um den Vorgang zu starten.

Vorsicht:

Gelöschte Knoten können nur zurückgesetzt werden, indem Sie das Repository wiederherstellen. Da eine fehlerfreie Konfiguration sehr wichtig ist, empfiehlt es sich, vor einer Bereinigung immer einen Probelauf durchzuführen.

Analysieren der Konsole

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 beim Bereinigungsvorgang 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: Der Knoten wurde gelöscht.

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: das Datum der Version.

Im folgenden ein Beispiel:

  • Die Versionen unter Hemden werden gelöscht, da sie älter als 2 Tage sind.
  • Die Versionen unter Tonga Fashions! werden gelöscht, da die Anzahl der Versionen größer als 5 ist.
global_version_screenshot

Arbeiten mit Auditdatensätzen und Protokolldateien

Auditdatensätze und Protokolldateien für Adobe Experience Manager (AEM) befinden sich an diversen Speicherorten. Im Folgenden erhalten Sie einen Überblick, welche Dateien wo zu finden sind.

Arbeiten mit Protokollen

AEM WCM zeichnet detaillierte Protokolle auf. Wenn Sie Quickstart entpackt und gestartet haben, finden Sie Protokolle unter folgenden Pfaden:

  • <CQ-Installationsverzeichnis>/crx-quickstart/logs/
  • <CQ-Installationsverzeichnis>/crx-quickstart/repository/

Protokolldateirotation

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 nach dem Muster {Original_Dateiname}.jjjj-MM-tt umbenannt. Beispielsweise wird die aktuelle Protokolldatei am 11. Juni 2010 umbenannt in error.log-2010-07-10 und anschließend wird eine neue error.log erstellt.
  • Vorherige Protokolldateien werden nicht gelöscht. Sie sind dafür verantwortlich, alte Protokolldateien regelmäßig zu löschen, um den Speicherbedarf zu beschränken.

Hinweis:

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.

Suchen nach Protokolldateien

Diverse Protokolldateien werden auf dem Dateiserver gespeichert, auf dem Sie AEM installiert haben:

  • <CQ-Installationsverzeichnis>/crx-quickstart/logs
    • access.log
      Hier werden alle Zugriffsanforderungen an AEM WCM und das Repository registriert.
    • audit.log
      Hier werden Moderationsaktionen registriert.
    • error.log
      Hier werden Fehlermeldungen (mit unterschiedlichem Schweregrad) registriert.
    • ImageServer-<Port-ID>-<jjjj>-<mm>-<tt>.log
      Dieses Protokoll wird nur verwendet, wenn dynamische Medien aktiviert sind. Es stellt die Statistiken und analytische Informationen bereit, die für die Analyse des Verhaltens des internen ImageServer-Prozesses verwendet werden. 
    • request.log
      Hier werden alle Zugriffsanforderungen zusammen mit der Antwort registriert.
    • s7access-<jjjj>-<mm>-<tt>.log
      Dieses Protokoll wird nur verwendet, wenn dynamische Medien aktiviert sind. Im Protokoll „s7access“ werden alle Anforderungen an dynamische Medien über /is/image und /is/content aufgezeichnet.
    • stderr.log
      Enthält Fehlermeldungen (ebenfalls mit unterschiedlichem Schweregrad), die beim Starten generiert werden. Standardmäßig wird für die Protokollebene Warnung (WARN) festgelegt
      .
    • stdout.log
      Enthält Protokollmeldungen, die auf Ereignisse beim Starten verweisen.
    • upgrade.log
      Liefert ein Protokoll aller Aktualisierungsvorgänge, das von den Paketen com.day.compat.codeupgrade und com.adobe.cq.upgradesexecutor aus ausgeführt wird.
  • <CQ-Installationsverzeichnis>/crx-quickstart/repository
    • revision.log
      Zeigt Daten des Revisionsjournals an.

Hinweis:

Die Protokolle „ImageServer“ und „s7access“ sind nicht im Paket Alles herunterladen enthalten, das von der Seite system/console/status-Bundlelist aus erstellt wird. Wenn Sie sich aufgrund von Problemen mit dynamischen Medien an den Support wenden, hängen Sie die Protokolle „ImageServer“ und „s7access“ an. 

Aktivieren der Protokollebene „DEBUG“

Die Standard-Protokollebene (Apache Sling-Protokollierungskonfiguration) ist „Information“, sodass keine Debugging-Meldungen protokolliert werden.

Um die Debugging-Protokollebene für eine Protokollierung zu aktivieren, legen Sie für die Eigenschaften org.apache.sling.commons.log.level im Repository den Wert „debug“ fest. Beispielsweise auf /libs/sling/config/org.apache.sling.commons.log.LogManager, um die globale Apache Sling-Protokollierung zu aktivieren.

Vorsicht:

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, die Installation kann nicht fortgesetzt werden.
1 Fehler Die Aktion ist fehlgeschlagen. Die Installation wird fortgesetzt, ein Teil von AEM WCM wird jedoch nicht richtig installiert und funktioniert nicht.
2 Warnung Die Aktion wurde ausgeführt, es sind jedoch Probleme aufgetreten. AEM WCM funktioniert möglicherweise nicht ordnungsgemäß.
3 Information Die Aktion war erfolgreich.

Erstellen einer benutzerdefinierten Protokolldatei

Hinweis:

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:

  1. Falls nicht bereits vorhanden, erstellen Sie einen neuen Konfigurationsordner (sling:Folder) für das Projekt /apps/<Projekt-Name>/config.

  2. Erstellen Sie unter /apps/<Projekt-Name>/config einen Knoten für die neue Apache Sling Logging-Protokollierungs-Konfiguration:

    • Name: org.apache.sling.commons.log.LogManager.factory.config-<Kennung> (da dies eine Protokollierung ist)
      Dabei wird <Kennung> durch freien Text ersetzt, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information muss angegeben werden). Beispielsweise org.apache.sling.commons.log.LogManager.factory.config-MINE
    • Typ: sling:OsgiConfig

    Hinweis:

    Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für die <Kennung> einen eindeutigen Parameter zu verwenden.

  3. Legen Sie die folgenden Eigenschaften auf diesem Knoten fest:

    • Name: org.apache.sling.commons.log.file
      Typ: String
      Wert: Geben Sie die Protokolldatei an, z. B. logs/myLogFile.log

    • Name: org.apache.sling.commons.log.names
      Typ: String[] (String + Multi)
      Wert: Geben Sie die OSGi-Dienste an, für die die Protokollierung Meldungen protokollieren soll, beispielsweise alle Folgenden:
      • 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); z. B. debug
    • Konfigurieren Sie ggf. weitere Parameter:
      • Name: org.apache.sling.commons.log.pattern
        Typ: String
        Wert: Geben Sie das erforderliche Muster der Protokollmeldung an, z. B.
        {0,datum,tt.MM.jjjj HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    Hinweis:

    org.apache.sling.commons.log.pattern unterstützt bis zu sechs Argumente.

    {0} Zeitstempel vom Typ java.util.Date
    {1} Protokollmarkierung
    {2} Name des aktuellen Thread
    {3} Name der Protokollierung
    {4} Protokollebene
    {5} Protokollmeldung

    Falls der Protokollaufruf den Parameter Throwable enthält, wird der StackTrace an die Meldung angefügt.

    Vorsicht:

    „org.apache.sling.commons.log.names“ muss einen Wert enthalten.

    Hinweis:

    Protokollschreibpfade sind vom crx-quickstart-Speicherort abhängig.

    Eine Protokolldatei wie:

        logs/thelog.log

    wird daher geschrieben in:

        <CQ-Installationsverzeichnis>/crx-quickstart/logs/thelog.log.

    Und eine Protokolldatei wie:

        ../logs/thelog.log

    wird in folgendes Verzeichnis geschrieben:

        <CQ-Installationsverzeichnis>/logs/
        (neben  <CQ-Installationsverzeichnis>/crx-quickstart/)

  4. Dieser Schritt muss nur ausgeführt werden, wenn ein neuer Writer erforderlich ist (d. h. mit einer Konfiguration, die vom standardmäßigen Writer abweicht).

    Vorsicht:

    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/<Projekt-Name>/config einen Knoten für die neue Apache Sling Logging-Writer-Konfiguration:

    • Name: org.apache.sling.commons.log.LogManager.factory.writer-<Kennung> (da dies ein Writer ist)
      Wie bei der Protokollierung wird der Parameter <Kennung> durch freien Text ersetzt, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information muss angegeben werden). Beispielsweise org.apache.sling.commons.log.LogManager.factory.writer-MINE
    • Typ: sling:OsgiConfig

    Hinweis:

    Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für die <Kennung> einen eindeutigen Parameter zu verwenden.

    Legen Sie die folgenden Eigenschaften auf diesem Knoten fest:

    • Name: org.apache.sling.commons.log.file
      Typ: String
      Wert: Geben Sie die gleiche Protokolldatei wie in der Protokollierung an;
                beispielsweise ../logs/myLogFile.log.
    • Konfigurieren Sie ggf. weitere Parameter:
      • Name: org.apache.sling.commons.log.file.number
        Typ: Long
        Wert: Geben Sie die Anzahl der Protokolldateien an, die Sie beibehalten möchten; beispielsweise 5
      • Name: org.apache.sling.commons.log.file.size
        Typ: String
        Wert: Geben Sie diesen wie erforderlich an, um die Dateirotation nach Größe/Datum zu steuern; beispielsweise '.'dd.MM.yyyy

    Hinweis:

    org.apache.sling.commons.log.file.size steuert die Rotation der Protokolldatei durch Einstellungen für:

    • eine maximale Dateigröße oder
    • einen Zeit-/Terminplan

    und gibt so an, wann eine neue Datei erstellt wird (und die vorhandene Datei gemäß dem Namensmuster umbenannt wird).

    • Eine Größenbeschränkung kann mit einer Zahl angegeben werden. Falls kein Größenindikator angegeben ist, gilt die Anzahl der Bytes oder Sie können einen der folgenden Indikatoren hinzufügen: KB, MB oder GB (Groß-/Kleinschreibung wird ignoriert).
    • Sie können einen Zeit-/Terminplan nach dem java.util.SimpleDateFormat-Muster angeben. Dieser gibt den Zeitraum an, in dem die Datei rotiert wird, und hängt ein Suffix an die rotierte Datei an (zur einfachen Identifizierung).
      Der Standard ist '.'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 Tag jeder Woche (hängt von dem Gebietsschema ab).
      '.'dd.MM.yyyy Rotation täglich um Mitternacht.
      '.'yyyy-MM-dd-a Rotation täglich um Mitternacht und am Mittag.
      '.'yyyy-MM-dd-HH Rotation zu jeder vollen Stunde.
      '.'yyyy-MM-dd-HH-mm Rotation zu Beginn jeder Minute.
      Bei der Angabe einer Uhrzeit/eines Datums ist Folgendes zu beachten:
          1. Sie sollten reinen Text durch einzelne Anführungszeichen (' ') schützen;
              dadurch wird verhindert, dass bestimmte Zeichen als Musterzeichenfolge interpretiert werden.
          2. Verwenden Sie nur Zeichen, die für einen gültigen Dateinamen im Optionsfeld zulässig sind.

  5. Lesen Sie die neue Protokolldatei mit dem von Ihnen ausgewählten Tool.

    Die für dieses Beispiel erstellte Protokolldatei ist ../crx-quickstart/logs/myLogFile.log.

Die Felix-Konsole enthält auch Informationen zum Sling Log-Support unter ../system/console/slinglog; beispielsweise http://localhost:4502/system/console/slinglog.

Suchen nach Auditdatensätzen

Auditdatensätze werden als Nachweis darüber aufbewahrt, wer wann welche Aktion vorgenommen hat. Verschiedene Auditdatensätze werden für AEM WCM und OSGi-Ereignisse generiert.

Bei der Seitenbearbeitung angezeigte AEM WCM-Auditdatensätze

  1. Öffnen Sie die Seite.

  2. Wählen Sie im Sidekick die Registerkarte mit dem Sperrsymbol aus und doppelklicken Sie auf Auditprotokoll...

  3. Ein neues Fenster wird geöffnet, in dem die Liste der Auditdatensätze für die aktuelle Seite angezeigt werden.

    screen_shot_2012-02-02at43601pm
  4. Klicken Sie auf OK, wenn Sie das Fenster schließen möchten.

AEM WCM-Auditdatensätze im Repository

Auditdatensätze werden im Ordner /var/audit je nach 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, die beim Bearbeiten einer Seite angezeigt werden.

OSGi-Auditdatensätze aus der Web-Konsole

OSGi-Ereignisse generieren ebenfalls Auditdatensätze, die Sie auf der Seite Konfigurationsstatus unter der Registerkarte Protokolldateien in der Adobe CQ-Web-Konsole anzeigen können:

screen_shot_2012-02-13at50346pm

Überwachen der Replikationsagenten

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 aktivierten Warteschlangen sollten den Status Im Leerlauf oder Aktiv aufweisen, was einem normalem Betrieb entspricht. Keine der Warteschlangen sollte den Status Blockiert aufweisen, da dies oft auf Probleme auf Empfängerseite hinweist.
  • Wenn die Warteschlange im Laufe der Zeit größer wird, kann dies auf eine Blockierung hindeuten.

Überwachen eines Replikationsagenten:

  1. Wechseln Sie in AEM zur Registerkarte Tools.

  2. Klicken Sie auf Replikation.

  3. Doppelklicken Sie auf den Link für die 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.

  4. Klicken Sie auf den jeweiligen Agenten (der als Link dargestellt ist), um detaillierte Informationen zu diesem Agenten anzuzeigen:

    chlimage_1

    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.

    Vorsicht:

    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'] 

Auch hier können Sie eine Lösung entwickeln, um alle Replikationsagenten (unter /etc/replication/author oder /etc/replication/publish) zu erkennen und den Status des jeweiligen Agenten (aktiviert, deaktiviert) sowie der zugrundeliegenden Warteschlange (aktiv, leer, blockiert) zu überprüfen.

Überwachen der Leistung

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 für die kontinuierliche Überwachung verwendet werden.

Hinweis:

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) Für mehr Kapazität... Für kleinere Datenmengen...
Client Hohe Client-CPU-Auslastung. Installieren Sie eine Client-CPU mit höherer Leistung. Vereinfachen Sie das (HTML-)Layout.
  Geringe Server-CPU-Auslastung. Aktualisieren Sie auf einen schnelleren Browser. Optimieren Sie den clientseitigen Cache.
  Einige Clients sind schnell, einige langsam.    
Server      
Netzwerk Geringe CPU-Auslastung auf Servern und Clients. Beseitigen Sie Netzwerkengpässe. Verbessern/optimieren Sie die Konfiguration des Client-Cache.
  Lokales Browsen auf dem Server ist (vergleichsweise) schnell. Vergrößern Sie die Netzwerkbandbreite. Komprimieren Sie Ihre Webseiten (z. B. weniger Bilder, optimiertes HTML).
Webserver Hohe CPU-Auslastung auf dem Webserver. Erstellen Sie Webserver-Cluster. Reduzieren Sie die Treffer pro Seite (Aufruf).
    Verwenden Sie einen Hardware-Lastausgleich.  
Anwendung Hohe CPU-Auslastung auf dem Server. Erstellen Sie Cluster der CQ5-Instanzen. Suchen Sie nach und beseitigen Sie CPU- und Arbeitsspeicherverschwendung (mithilfe von Code Review, Timing-Ausgaben usw.).
  Hoher Speicherverbrauch.   Verbessern Sie das Caching auf allen Ebenen.
  Langsame Systemreaktion.   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-Lasten und vieles mehr.

Sie können sich auf alle Besucher oder nur bestimmte Benutzergruppen auswirken.

Sie müssen all diese Informationen erfassen, sortieren und analysieren, bevor Sie die allgemeine Leistung optimieren oder gezielt Probleme lösen können.

  • Bevor ein Leistungsproblem auftritt:
    • Sammeln Sie so viele Informationen wie möglich, um sich ein gutes Bild des Systems unter normalen Bedingungen zu machen.
  • Wenn ein Leistungsproblem auftritt:
    • 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:
      • Tritt das Problem nur zu bestimmten Zeitpunkten auf?
      • Tritt das Problem nur auf bestimmten Seiten auf?
      • Sind andere Anforderungen davon betroffen?
    • Sammeln Sie so viele Informationen wie möglich, um diese mit den Information zu vergleichen, die Sie zum System unter normalen Bedingungen haben:

Tools für die Leistungsüberwachung und -analyse

Im Folgenden finden Sie einen kurzen Überblick über Tools, mit denen Sie die Leistung überwachen und analysieren können.

Einige von diesen richten sich nach Ihrem Betriebssystem.

Tool Für die Analyse von... Einsatz/Weitere Informationen...
request.log Systemreaktion und gleichzeitige Nutzung. Interpretieren von request.log.
truss/strace Seitenladefrequenzen

Unix-/Linux-Befehle zum Nachverfolgen von Systemaufrufen und -signalen. Erhöhen Sie die Protokollebene auf INFO.

Analysieren Sie die Seitenladefrequenz pro Anforderung, welche Seiten geladen wurden usw.

Thread-Dumps Überwachen Sie die JVM-Threads. Identifizieren Sie Konflikte, Sperren und lange Ausführungszeiten.

Je nach Betriebssystem:
- Unix/Linux: kill -QUIT <pid>
- Windows (Konsolenmodus): STRG-UNTBR

Analysetools sind auch verfügbar wie TDA.

Heap-Dumps Unzureichender Speicher verursacht Leistungsprobleme.

Fügen Sie die Option:
    -XX:+HeapDumpOnOutOfMemoryError
zum Java-Aufruf an CQ hinzu.

Siehe Leitfaden zur Fehlerbehebung bei Java SE 6 mit HotSpot VM (nur in englischer Sprache verfügbar).

Systemaufrufe Identifizieren von Timing-Problemen.

Aufrufe an System.currentTimeMillis() oder com.day.util.Timing werden zum Erstellen von Zeitstempeln aus dem Code oder über HTML-Kommentare verwendet.

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 von Speicherlecks, wahlweise Analysieren der Systemreaktion.

Grundlegende Verwendung:

ab -k -n <requests> -c <concurrency> <url>

Einzelheiten unter Apache Bench und auf derab man-Seite.

Suchanalysen   Führen Sie Suchabfragen offline aus, identifizieren Sie die Reaktionszeit auf Abfragen, testen und bestätigen Sie Ergebnisse.
JMeter Lade- und Funktionstests. http://jakarta.apache.org/jmeter/
JProfiler Detaillierte CPU- und Speicherprofile. http://www.ej-technologies.com/
JConsole Überwachen von JVM-Metriken und Threads.

Verwendung: 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 Überwachen von JVM-Metriken, Threads, Speicher und Profilen.

Verwendung: 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, lsof Detaillierte Analysen von Kernel-Aufrufen und Prozessen (Unix). Unix-/Linux-Befehle.
Timing-Statistiken Siehe Timing-Statistiken für die Seitenwiedergabe

Sie können Timing-Statistiken für die Seitenwiedergabe mit Strg-Umschalt-U und dem Befehl ?debugClientLibs=true in der URL anzeigen.

CPU- und Speicherprofil-Tool
Für die Analyse von langsamen Anforderungen bei der Entwicklung. Beispiel:YourKit.
Informationserfassung Kontinuierliche Statuserfassung der Installation. 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.

Interpretieren von request.log

In dieser Datei werden grundlegende Informationen zu allen Anforderungen an CQ 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 verwenden.

Überwachen von Website-Traffic

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 für einen bestimmten Zeitraum (z. B. über mehrere 24-Stunden-Zeiträume) erhalten Sie aussagekräftige Informationen zum durchschnittlichen Traffic auf Ihrer Website.

Überwachen der Systemreaktion mit CQ request.log

Ein guter Ausgangspunkt für Leistungsanalysen ist das Anforderungsprotokoll:

    <CQ-Installationsverzeichnis>/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 der Anforderungen, in eckigen Klammern; diese Zahl stimmt für Anforderungen und Antworten überein;
  • 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:
    • die Methode (in der Regel GET, HEAD oder POST);
    • die angeforderte Seite;
    • das Protokoll.
  • Bei Antworten enthält die Zeile:
    • den Statuscode (200 steht für „Erfolg“, 404 steht für „Seite nicht gefunden“);
    • den MIME-Typ;
    • die Antwortzeit.

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.

Überwachen von Suchantwortzeiten mit CQ5 request.log

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. 

Überwachen der Anzahl und Auswirkung gleichzeitiger Benutzer

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:

  • Überwachen Sie, wie viele Anforderungen in einem bestimmten Zeitraum erfolgen, z. B. in einer Minute.
  • Testen Sie die Auswirkungen, wenn eine bestimmte Anzahl Benutzer die gleiche Anforderung zur (möglichst) gleichen Zeit senden; z. B. 30 Benutzer klicken gleichzeitig auf Speichern.
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

Verwenden von rlog.jar bei der Suche nach Anforderungen mit langer Dauer

CQ beinhaltet verschiedene Hilfs-Tools unter:
    <CQ-Installationsverzeichnis>/crx-quickstart/opt/helpers

Eines dieses 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.

Apache Bench

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 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://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 (CG 5.6.1. Standardinstallation). Die Seite ist sehr einfach aufgebaut, aber nicht für Leistung optimiert.

apachebench zeigt auch die durchschnittliche Zeit pro Anforderung für alle gleichzeitigen Anforderungen an; siehe Time per request: 54.595 [ms] (Durchschnitt aller gleichzeitigen Anforderungen). Sie können den Wert des Parameters für gleichzeitige Nutzung -c (Anzahl mehrerer gleichzeitig auszuführender Anforderungen) ändern, um die Auswirkungen anzuzeigen.

Anforderungszähler

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:

  • Erhebliche Unterschiede bei Aktivitäten (z. B. „viele Anforderungen“ im Vergleich zu „geringer Aktivität“)
  • Ob eine Instanz nicht verwendet wird
  • Alle Neustarts (Zähler wird auf 0 zurückgesetzt)

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:

  • Beträchtlich geänderte Aktivitäten
  • Eine redundante Instanz
  • Alle Neustarts (der Zähler wird auf 0 zurückgesetzt)

HTML-Kommentare

Es wird empfohlen, dass jedes Projekt HTML-Kommentare zur Serverleistung enthält. Es gibt viele gute Beispiele. Öffnen Sie eine Seite, zeigen Sie den Quelltext an und scrollen Sie zum Ende. Code wie der folgende wird angezeigt:

</body>
  </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Überwachen der Leistung mit JConsole

Der Tool-Befehl jconsole ist bei JDK verfügbar.

  1. Starten Sie die CQ5-Instanz.

  2. Führen Sie jconsole aus.

  3. Wählen Sie die CQ-Instanz aus und klicken Sie auf Verbinden.

  4. Doppelklicken Sie in der lokalen Anwendung auf com.day.crx.quickstart.Main. Standardmäßig wird folgende Übersicht angezeigt:

    chlimage_1

    Anschließend können Sie weitere Optionen auswählen.

Überwachen der Leistung mit (J)VisualVM

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:

  1. Starten Sie die CQ5-Instanz.

    Hinweis:

    Mit Java 5 können Sie das -Dcom.sun.management.jmxremote-Argument zur Java-Befehlszeile hinzufügen, mit der JVM gestartet wird. JMX ist standardmäßig bei Java 6 aktiviert.

  2. 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)
  3. Doppelklicken Sie in der lokalen Anwendung auf com.day.crx.quickstart.Main. Standardmäßig wird folgende Übersicht angezeigt:

    chlimage_1

    Danach können Sie noch weitere Optionen einschließlich der Überwachungsoption „Monitor“ auswählen:

    chlimage_1

Sie können dieses Tool zum Generieren von Thread-Dumps und Speicher-Heap-Dumps verwenden. Diese Informationen werden häufig vom technischen Support-Team angefordert.

Informationserfassung

Wie viele Autoren arbeiten mit dem System?

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 bestimmt Tag mit dem System arbeiten, verwenden Sie:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Wie viele Seiten werden im Durchschnitt pro Tag aktiviert?

Um die Gesamtzahl der Seitenaktivierungen ab der Serverinstallation anzuzeigen, verwenden Sie eine Repository-Abfrage über 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.

Wie viele Seiten unterhalten Sie derzeit auf diesem System?

Um die Anzahl der aktuellen Seiten auf dem Server anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

  • Typ XPath
  • Pfad /
  • Abfrage //element(*, cq:Page)

Falls Sie MSM verwenden, wie viele Rollouts pro Monat erfolgen im Durchschnitt?

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.

Wie viele Live Copies pro Monat gibt es im Durchschnitt?

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.

Falls Sie CQ DAM verwenden, wie viele Assets unterhalten Sie derzeit in CQ DAM?

Um anzuzeigen, wie viele DAM-Assets Sie derzeit unterhalten, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

  • Typ XPath
  • Pfad /
  • Abfrage /jcr:root/content/dam//element(*, dam:Asset)

Wie groß sind die Assets im Durchschnitt?

Um die Gesamtgröße des Ordners /var/dam anzuzeigen:

  1. verwenden Sie WebDAV, um das CQ-Repository dem lokalen Dateisystem zuzuordnen.

  2. Verwenden Sie folgende Befehlszeile:

    cd /Volumes/localhost/var
    du -sh dam/

    Um die durchschnittliche Größe zu berechnen, teilen Sie die Gesamtgröße durch die Anzahl der Assets im Ordner /var/dam (oben ermittelt).

Wie viele Vorlagen werden derzeit verwendet?

Um die Anzahl der aktuellen Vorlagen auf dem Server anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

  • Typ XPath
  • Pfad /
  • Abfrage //element(*, cq:Template)

Wie viele Komponenten werden derzeit verwendet?

Um die Anzahl der aktuellen Komponenten auf dem Server anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

  • Typ XPath
  • Pfad /
  • Abfrage //element(*, cq:Component)

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Autorensystem?

Bestimmen der Anforderungen pro Stunde auf dem Autorensystem zu Spitzenzeiten:

  1. 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
  2. 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.

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Veröffentlichungssystem?

Wiederholen Sie die obigen Schritte auf der Veröffentlichungsinstanz.

Analyse spezieller Szenarien

Im Folgenden finden Sie eine Liste mit Vorschlägen, was Sie überprüfen sollten, falls Sie CQ-Leistungsprobleme bemerken. Die Liste ist (leider) nicht vollständig.

CPU bei 100 %

Wenn die CPU-Auslastung des Systems ständig bei 100 % liegt, sehen Sie in folgender Dokumentation nach:

Unzureichender Speicher

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:

Festplatten-I/O

Falls das System keine Festplattenkapazität mehr hat oder Sie Festplatten-Trashing bemerken, überprüfen Sie Folgendes:

Normale Leistungsbeeinträchtigung

Falls Sie nach jedem Neustart (ggf. eine Woche oder mehr nach dem Neustart) eine Leistungsverschlechterung der Instanz bemerken, können Sie Folgendes überprüfen:

JVM-Optimierung

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:

http://www.ibm.com/developerworks/library/j-ibmtools2/

Oder mit JConsole:

  • Diese Einstellungen gelten für eine JMX-Verbindung vom Typ „wide open“:
    -Dcom.sun.management.jmxremote \
    -Dcom.sun.management.jmxremote.port=8889 \
    -Dcom.sun.management.jmxremote.authenticate=false \
    -Dcom.sun.management.jmxremote.ssl=false
  • Stellen Sie dann mit JConsole eine Verbindung zu JVM her; siehe:
    http://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.  Ohne diese Daten bleibt die Optimierung dem Zufall überlassen.

Hinweis:

Informationen zu Oracle VM finden Sie unter:

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie