How to tune the Lucene index within AEM is a multistep process. Learn what you need to do to optimise your index.
Head of Operations and Support
Aug 26, 2017
The index is a core component and one that should be quick in answering any queries you fire at it. In many cases, it also grows significantly and sometimes it’s unclear why it is growing or slow. How to tune the Lucene index within AEM is a multi step process, which is briefly described in this blog article. Additionally, we will look at query analysis and traversals, and how to mitigate them to ensure that queries run fast.
When it comes to running an AEM instance in production, the index is always present. Adobe recommends some steps to tune the index further. Some are listed below, but also further extended information and documentation can be found, as the steps may not always be clear. Before trying anything like this on a production instance, make sure you do the testing on an exact copy, as this allows you to gather important information on how long the tasks take and also permits you to calculate for downtimes properly. If you are doing the tuning on a publish instance and have multiple ones to do this on, and you are running in a cloud or cloud-like infrastructure with fast snapshot capability, I recommend that you perform this on one publish, buffer the replication nodes temporarily for the others, and clone the instance. This will save much time, and in the end, you will achieve a much more equal setup.
Details on the functionality and architecture of the index can be found here
Enable Prefetch Index Files
Increase the thread count (5 is the default, suggested is 20)
To check if the index is working properly
Tail the error log and ensure the indexing is running
After the above settings are applied, ensure that the index folder is created and being filled
Check the following mbeans for progress
org.apache.jackrabbit.oak: "IndexCopier support statistics" ("IndexCopierStats")
org.apache.jackrabbit.oak: "async" ("IndexStats")
org.apache.jackrabbit.oak: "Lucene Index statistics" ("LuceneIndex")
The Lucene index statistics will start showing separate indexes once the initial indexing is finished.
In many cases traversals can occur if an index is not deemed to be useful to use. This can be quite a performance killer and, therefore, it is advisable to create custom indexes when needed. A great tool to use is the index generator. Simply create an index configuration from your xpath query and deploy it.
Removing specific things to not index
You can set a property on an index node as follows:
This can be set on the Lucene or also the cqPageLucene index.
Additionally, ensure the value rep:Token is added to the declaringNodeTypes properties (multi string property) for the nodetype index.
Checking your index config for duplicate aggregates
Double check your index config. Especially if there are duplicates for aggregation, there is a chance that this is wrong. The root cause for this misconfiguration at this time is unclear, but removing them and changing it to default behaviour reduces the size drastically.
Initially the log can be fairly quiet as the copying is taking place, so it is better to watch the filesystem during this time.
After a while, the regular indexing will start.
Once it is completed, stop AEM.
Run an offline compaction.
Run a datastore garbage collection.
Delete all the files beneath the crx-quickstart/repository/index/ directory.
Start AEM and watch the logs. Initially the log can be fairly quiet as the copying is taking place of the newly created index. The size should be smaller afterwards depending on what adjustments were made.
Once it is completed, AEM is back up and running.
Just because it was so nice, you can run another tar compaction and then datastore garbage collection approximately 24h after the indexing finished completely - unless it is run, the old index will be kept in the datastore simply using up space even though it is not used anymore. By default, a datastore garbage collection has a max deleted time of 24h.
Check the index size after, on the file system or via JMX within the Lucene Index statistics, and compare to details noted below step 3
When the CopyOnRead is enabled, it only gets extended but never reduced. This is the reason why a deletion of the index on the file system is needed, so the tuned index can be copied to disk.
To reduce size of the Lucene index, the above steps must be followed including the adjusted tika config. This is time consuming and possibly, if you want to reduce the size of the index on the filesystem for a publish, it may be easier to simply disable the CopyOnRead and CopyOnWrite functionality. Check with your architect if the indexes are heavily used on the publish side or not before!
JVM Options for ensuring smooth operation
The following JVM parameters have shown much more stable performance on production systems. Ensure that these JVM parameters are in the AEM start script to prevent expensive queries from overloading the systems.
There are many things to look out for when operating an AEM instance. Not only regular maintenance tasks like a Datastore Garbage Collection or others as detailed in a previous article are important. Tar compactions are the key to reducing repository growth. Datastore garbage collections after a compaction yield the best results in reducing the datastore size. Also as noted above, optimizing your Lucene index is a good solution to further reducing the resource footprint. Additionally, it does make sense to disable specific configurations like the CopyOnRead or CopyOnWrite where they are not needed, for example, on Publish instances where search is not leveraged much.
Other great resources for index optimizations or finding out why queries don’t work as they should are contained in the ACS tools, for example, the index manager. as well as the query explainer.
One Netcentric’s co-founders, Stefan is an expert in shaping solutions for clients - from requirements analysis to project specification and more. Stefan sees himself as the link between business and technology and, for over ten years now, he has filled various roles as architect, project lead and lead consultant. Stefan's focus is on the Adobe Marketing Cloud and AEM, to which he is strongly connected from his days at Day Software and Adobe. He says that co-founding Netcentric was one of the best choices in his professional life. Never before been able to work with so many brilliant people.