The most straightforward approach to defining the proper memory allocation of the directory server components is to use the Directory Server setup command on hardware that represents the target production platform, especially with regard to process and memory, and the largest heap size that the setup tool will allow. After running setup, any schema and production database settings should be defined in preparation for the database import using the import-ldif tool.

Note: At the moment after an import-ldif, the database is at its most optimized state on disk with no inactive records. Over time, the on-disk representation of the database will grow as much as 25-50% as inactive records accumulate before being removed by the server’s cleaner thread.

After the database is imported, the server should be started and a configuration change made to the backend. In this scenario, set the prime-method to "preload" on the userRoot backend configuration. Once the change is made, re-start the Directory Server and watch for a successful preload message at the end of startup. If preloading did not complete, the server should be stopped. The start-server.java-args entry in the config/java.properties file should be edited to use larger values for -Xmx and -Xms arguments. Then run the bin/dsjavaproperties command and restart the server. If preloading completed successfully, the database cache utilization percentage will be of interest. The status command will display something like the following:

             --- JE Environment --- 
ID   	: Cache Full : Cache  : On-Disk : Alert 
---------:------------:--------:---------:------ 
userRoot : 30%	    : 1.1 gb : 868.6mb : None

Looking at the above output and knowing that the database is fully loaded into cache, the 30% utilization is comfortable cushion for future database growth. In general, it is best to leave at least 10-20% cache headroom available.

During this scenario, it was clear from the start-server output that the database primed completely and our interpretation of the status output was sound. To see the state of the database cache with more detail, perform an ldapsearch on the backend monitor.

In addition to the user configured backends, there may be backends for replication and changelog. The heap is shared among all backends. The amount allocated to each backed is calculated according to the procedure in the next section.