DokumentationAEM 6.4Implementierungshandbuch

Speicherelemente in AEM 6.4 storage-elements-in-aem

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Erstellt für:

  • Developer
CAUTION
AEM 6.4 hat das Ende der erweiterten Unterstützung erreicht und diese Dokumentation wird nicht mehr aktualisiert. Weitere Informationen finden Sie in unserer technische Unterstützung. Unterstützte Versionen suchen here.

In diesem Artikel werden folgende Themen behandelt:

Überblick über Speicher in AEM 6 overview-of-storage-in-aem

Eine der wichtigsten Änderungen in AEM 6 sind die Innovationen auf Repository-Ebene.

Derzeit sind in AEM6 zwei Implementierungen für den Knotenspeicher verfügbar: Tar-Speicher und MongoDB-Speicher.

Tar-Speicher tar-storage

Ausführen einer neu installierten AEM-Instanz mit TAR-Speicher running-a-freshly-installed-aem-instance-with-tar-storage

CAUTION
Die PID für den Segment-Knotenspeicher wurde von org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService in vorherigen Versionen von AEM 6 in org.apache.jackrabbit.oak.segment.SegmentNodeStoreService in AEM 6.3 geändert. Vergessen Sie nicht, die Konfiguration an diese Änderungen anzupassen.

Standardmäßig verwendet AEM 6 den TAR-Speicher zum Speichern von Knoten und Binärdateien und verwendet dabei die Standardkonfigurationsoptionen. Gehen Sie wie folgt vor, um die Speichereinstellungen manuell zu konfigurieren:

  1. Laden Sie die AEM 6-Schnellstart-JAR herunter und legen Sie sie in einem neuen Ordner ab.

  2. Entpacken Sie AEM durch Ausführen:

    java -jar cq-quickstart-6.jar -unpack

  3. Erstellen Sie den Ordner crx-quickstart\install im Installationsverzeichnis.

  4. Erstellen Sie die Datei org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.cfg im neu erstellten Ordner.

  5. Bearbeiten Sie die Datei und legen Sie die Konfigurationsoptionen fest. Die folgenden Optionen sind für den Segment-Knotenspeicher verfügbar, der die Grundlage für AEM Tar-Speicherimplementierung bildet:

    • repository.home: Pfad zum Repository-Stammverzeichnis, in dem diverse Repository-bezogene Daten gespeichert werden. Standardmäßig werden Segmentdateien im Verzeichnis crx-quickstart/segmentstore gespeichert.
    • tarmk.size: Maximale Größe eines Segments in MB. Die Standardgröße ist 256 MB.

  6. Starten Sie AEM.

Mongo-Speicher mongo-storage

Ausführen einer neu installierten AEM-Instanz mit Mongo-Speicher running-a-freshly-installed-aem-instance-with-mongo-storage

AEM 6 kann für die Ausführung mit MongoDB-Speicher konfiguriert werden, wie nachfolgend beschrieben:

  1. Laden Sie die AEM 6-Schnellstart-JAR herunter und legen Sie sie in einem neuen Ordner ab.

  2. Entpacken Sie AEM, indem Sie den folgenden Befehl ausführen:

    java -jar cq-quickstart-6.jar -unpack

  3. Vergewissern Sie sich, dass MongoDB installiert ist und eine Instanz von mongod ausgeführt wird. Weitere Informationen finden Sie unter Installieren von MongoDB.

  4. Erstellen Sie den Ordner crx-quickstart\install im Installationsverzeichnis.

  5. Konfigurieren Sie den Knotenspeicher. Erstellen Sie dazu eine Konfigurationsdatei mit dem Namen der Konfiguration, die Sie im Verzeichnis crx-quickstart\install verwenden möchten.

    Der Document-Knotenspeicher (auf dem die Implementierung von MongoDB-Speicher in AEM basiert) verwendet die Datei org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.cfg.

  6. Bearbeiten Sie die Datei und legen Sie die Konfigurationsoptionen fest. Die folgenden Optionen sind verfügbar:

    • mongouri: Die für die Verbindung mit der Mongo-Datenbank erforderliche MongoURI. Standard: mongodb://localhost:27017
    • db: Name der Mongo-Datenbank. Standardmäßig wird bei AEM 6-Installationen aem-author als Datenbankname verwendet.
    • cache: Cache-Größe in MB. Dieser Wert verteilt sich auf die verschiedenen in DocumentNodeStore verwendeten Caches. Der Standardwert lautet 256.
    • changesSize: Größe (in MB) der begrenzten Sammlung, die in Mongo zum Caching unterschiedlicher Ausgaben verwendet wird. Der Standardwert lautet 256.
    • customBlobStore: Boolescher Wert, der angibt, dass ein benutzerdefinierter Datenspeicher verwendet wird. Der Standardwert ist "false".

  7. Erstellen Sie eine Konfigurationsdatei mit der PID des Datenspeichers, den Sie verwenden möchten, und bearbeiten Sie die Datei, um die Konfigurationsoptionen festzulegen. Weitere Informationen finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern.

  8. Starten Sie die JAR-Datei von AEM 6 mit einem MongoDB-Speicher-Backend, indem Sie Folgendes ausführen:

    code language-shell 
    java -jar cq-quickstart-6.jar -r crx3,crx3mongo

    Dabei ist -r der Backend-Ausführungsmodus. In diesem Beispiel beginnt dieser mit MongoDB-Unterstützung.

Deaktivieren von Transparent Huge Pages disabling-transparent-huge-pages

Red Hat Linux nutzt einen Speicherverwaltungsalgorithmus mit der Bezeichnung THP (Transparent Huge Pages). Während AEM feinkörnige Lese- und Schreibvorgänge durchführt, ist THP für große Operationen optimiert. Aus diesem Grund wird empfohlen, dass Sie THP auf Tar- und Mongospeicher deaktivieren. Gehen Sie wie folgt vor, um den Algorithmus zu deaktivieren:

  1. Öffnen Sie die Datei /etc/grub.conf in einem beliebigen Texteditor.

  2. Fügen Sie der Datei grub.conf die folgende Zeile hinzu:

    code language-none 
    transparent_hugepage=never

  3. Überprüfen Sie abschließend, ob die Einstellung wirksam wurde, indem Sie Folgendes ausführen:

    code language-none 
    cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

    Wenn THP deaktiviert ist, sollte die Ausgabe des obigen Befehls wie folgt lauten:

    code language-none 
    always madvise [never]
NOTE
Zusätzlich können Sie auch die folgenden Ressourcen konsultieren:
  • Weitere Informationen zu Transparent Huge Pages unter Red Hat Linux finden Sie in diesem Artikel.
  • Tipps zum Linux-Tuning finden Sie in diesem Artikel.

Warten von Repositorys maintaining-the-repository

Bei jeder Repository-Aktualisierung wird eine neue Inhaltsrevision erstellt. Daher wächst das Repository nach jeder Aktualisierung. Um ein unkontrolliertes Repository-Wachstum zu vermeiden, müssen alte Revisionen bereinigt werden, um Festplattenressourcen freizugeben. Diese Wartungsfunktionalität wird als Revisionsbereinigung bezeichnet. Bei der Revisionsbereinigung wird durch Löschen veralteter Daten aus dem Repository Festplattenspeicher zurückgewonnen. Weitere Informationen zur Revisionsbereinigung finden Sie auf der Seite über die Revisionsbereinigung.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56