Storage Elements in AEM 6.4

In this article, we will cover:

• Overview of Storage in AEM 6
• Maintaining the Repository

Overview of Storage in AEM 6

One of the most important changes in AEM 6 are the innovations at the repository level.

Currently, there are two node storage implementations available in AEM6: Tar storage, and MongoDB storage.

Tar Storage

Running a freshly installed AEM instance with Tar Storage

By default, AEM 6 uses the Tar storage to store nodes and binaries, using the default configuration options. To manually configured its storage settings, follow the below procedure:

1. Download the AEM 6 quickstart jar and place it in a new folder.

2. Unpack AEM by running:

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

3. Create a folder named crx-quickstart\install in the installation directory.

4. Create a file called org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.cfg in the newly created folder.

5. Edit the file and set the configuration options. The following options are available for Segment Node Store, which is the basis of AEM’s Tar storage implementation:

   • repository.home: Path to repository home under which various repository related data is stored. By default segment files would be stored under the crx-quickstart/segmentstore directory.
   • tarmk.size: Maximum size of a segment in MB. The default is 256MB.

6. Start AEM.

Mongo Storage

Running a freshly installed AEM instance with Mongo Storage

AEM 6 can be configured to run with MongoDB storage by following the below procedure:

1. Download the AEM 6 quickstart jar and place it into a new folder.

2. Unpack AEM by running the following command:

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

3. Make sure that MongoDB is installed and an instance of mongod is running. For more info, see Installing MongoDB.

4. Create a folder named crx-quickstart\install in the installation directory.

5. Configure the node store by creating a configuration file with the name of the configuration you want to use in the crx-quickstart\install directory.

   The Document Node Store (which is the basis for AEM’s MongoDB storage implementation) uses a file called org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.cfg

6. Edit the file and set your configuration options. The following options are available:

   • mongouri: The MongoURI required to connect to Mongo Database. The default is mongodb://localhost:27017
   • db: Name of the Mongo database. By default new AEM 6 installations use aem-author as the database name.
   • cache: The cache size in MB. This is distributed among various caches used in DocumentNodeStore. The default is 256.
   • changesSize: Size in MB of capped collection used in Mongo for caching the diff output. The default is 256.
   • customBlobStore: Boolean value indicating that a custom data store will be used. The default is false.

7. Create a configuration file with the PID of the data store you wish to use and edit the file in order to set the configuration options. For more info, please see Configuring Node Stores and Data Stores.

8. Start the AEM 6 jar with a MongoDB storage backend by running:

   java -jar cq-quickstart-6.jar -r crx3,crx3mongo
   

   Where -r is the backend runmode. In this example, it will start with MongoDB support.

Disabling Transparent Huge Pages

Red Hat Linux uses a memory management algorithm called Transparent Huge Pages (THP). While AEM performs fine-grained reads and writes, THP is optimized for large operations. Because of this, it is recommended that you disable THP both on Tar and Mongo storage. To disable the algorithm, follow these steps:

1. Open the /etc/grub.conf file in the text editor of your choice.

2. Add the following line to the grub.conf file:

   transparent_hugepage=never
   

3. Finally, check if the setting has taken effect by running:

   cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
   

   If THP is disabled, the output of the above command should be:

   always madvise [never]
   

Maintaining the Repository

Each update to the repository creates a new content revision. As a result, with each update the size of the repository grows. To avoid uncontrolled repository growth, old revisions need to be be cleaned up to free disk resources. This maintenance functionality is called Revision Cleanup. The Revision Cleanup mechanism will reclaim disk space by removing obsolete data from the repository. For further details about Revision Cleanup, read the Revision Cleanup page.