28 Oracle Unified Directory Performance Tuning

This chapter provides guidelines for tuning and sizing Oracle Unified Directory. It contains these topics

28.1 About Oracle Unified Directory

Oracle Unified Directory is a comprehensive next generation directory service that is designed to address large deployments, to provide high performance, to be highly extensive and to be easy to deploy, manage, and monitor.

For more information on Oracle Unified Directory, see the Oracle Unified Directory Administrator's Guide.

28.2 Performance Considerations

Oracle Unified Directory aims to be high-performing and highly-scalable. Although the server can achieve impressive results with the "out-of-the-box" server configuration and default JVM settings, performance can often be improved significantly through some basic tuning.

The default settings of Oracle Unified Directory are targeted at evaluators and developers who are running equipment with limited resources. When you deploy Oracle Unified Directory in a production environment, it useful to do some initial tuning of the Java Virtual Machine (JVM) and of the server configuration to improve scalability and performance (particularly for write operations).

In addition, performance tuning strategies differ depending on whether you are running a directory server or a proxy server. This section describes some of the areas that you should consider tuning based on your server usage. Note that the specific tuning parameters and descriptions are discussed in Section 28.4, "Basic Tuning Considerations".

  • When OUD is used as an LDAP Directory Server. When used as a Directory Server, you can maximize performance by:

    • Tuning the database cache size, preload, and file cache size appropriately.

    • Placing the database on a fast file system.

    • Using the correct database caching mode for your deployment.

    • Tuning the Oracle Berkeley DB Java Edition log cleaners.

  • When OUD is used as an LDAP Proxy Server. When used as a Proxy Server, you can maximize performance by:

    • Making sure you have a sufficient number of worker threads. Proxying requires a large number of worker threads to optimize performance.

    • Setting the heap size to an appropriate value and using the correct JVM. It is unlikely that a proxy will need more than 4GB of heap, therefore a 32-bit JVM should be used in most cases.

In addition, the following items can improve performance in specific deployment scenarios.

  • Java Version. Use the most recent Java Runtime Environment (JRE) release available. Oracle Unified Directory is designed to work with Java SE 6 and 7.

  • Environment Variables. The server uses the OPENDS_JAVA_HOME environment variable to point to your installed JRE. If you have multiple versions of Java installed on a system, set the JAVA_HOME environment variable to point to the root of the desired installation. In this way, the version of the JRE specified by the JAVA_HOME variable can be used by other applications but not by Oracle Unified Directory.

    To specify a JRE installation for the server, do one of the following:

    • Use the dsjavaproperties command to set the appropriate environment variables.

      For more information, see "dsjavaproperties" in the Oracle Unified Directory Administrator's Guide.

    • Set the OPENDS_JAVA_BIN environment variable (with the JAVA binary path).

    • Set the OPENDS_JAVA_HOME environment variable (with the JAVA installation path).

28.3 Monitoring Unified Directory Performance

This chapter provides an overview of the key monitoring tools you can use to gather performance information for Unified Directory.

Comprehensive monitoring information is available in the "Monitoring Oracle Unified Directory" chapter of the Oracle Unified Directory Administrator's Guide.


Oracle Unified Directory provides an extensible monitoring framework. Oracle Unified Directory performance can also be monitored by using the Enterprise Manager Grid Control plugin. For more information, see the System Monitoring Plug-in for Oracle Unified Directory User's Guide.

28.3.1 Examining Log Files

Oracle Unified Directory provides several types of logs: access logs, audit logs, error logs, debug logs, oud-setup logs, server.out logs, and a replication repair log. The replication repair log is read-only and its use is restricted to enabling replication conflict resolution.

To quickly determine whether performance issues are related to problems with the server or with the client, review the access log at INSTANCE_DIR/OUD/logs/access. Access logs record information about the types of operations processed by the directory server. Access logs are provided by default.

This log contains entries of the form:

[09/Sep/2009:15:36:18 +0200] SEARCH RES conn=1 op=16 msgID=17 
  result=0 nentries=1 etime=1

The value of the etime field is the time (in milliseconds) that the server spent processing the request. Large etimes generally indicate an issue on the server side (which can usually be resolved by appropriate performance tuning or indexing. If you are experiencing performance problems but the etimes are small, the issue is more likely to be with your client application.

Information about configuring and viewing the other log files can be found in the following sections of the Oracle Unified Directory Administrator's Guide:

  • See "Configuring Logs" for information on how to configure access, audit, error, and debug logs by using the dsconfig command-line interface, or Oracle Directory Services Manager.

  • See "Accessing Logs" for information on how to view the access, error, or debugging information for the server instance.

28.3.2 Monitoring the Server With LDAP

The following sections of the Oracle Unified Directory Administrator's Guide provide detailed instructions on how to monitor the server using Lightweight Directory Application Protocol (LDAP):

28.3.3 Monitoring the Server With SNMP

Oracle Unified Directory provides a jar file extension that contains a Simple Network Management Protocol (SNMP) connection handler for Management Information Base (MIB) 2605 support. The extension contains the SNMP connection handler, the required classes to support MIB 2605 objects and SNMP requests, and the SNMP adapter that allows an SNMP manager to access the server monitoring information.

See "Monitoring the Server With SNMP" in the Oracle Unified Directory Administrator's Guide for more information on using the SNMP manager to monitor server performance.

28.4 Basic Tuning Considerations

The following sections describe basic tuning configurations that you should also consider while tuning Oracle Unified Directory:

28.4.1 Tuning Java Virtual Machine Settings

As discussed in Chapter 2, "Tuning Java Virtual Machines (JVMs)", you can use the JAVA_ARGS environment variable to provide global configuration arguments that can be passed to the JVM, or you can use the java.properties file. Any argument that can be used with the java command can be used with both methods.

For more information, see "dsjavaproperties" in the Oracle Unified Directory Administrator's Guide.

The following table describes the main JVM tunable options for Oracle Unified Directory. Note that some of these settings apply to Sun JVM only, but that similar settings could be applied to JRockit.

Parameter Description When using OUD as a Directory Server... When using OUD as a Proxy Server...


Always use the server JVM instead of the client JVM. The client VM is better optimized for processes that run for a short period of time and need to start as quickly as possible. The server VM can take longer to warm up but is faster than the client VM.

Set this parameter as described.

Set this parameter as described.

-d32 or -d64

Select the 32-bit or 64-bit version of the JVM as follows:

  • -d32 provides better performance for JVM heaps smaller than 3.5Gbytes.

  • -XX:+UseCompressedOops should be used for JVM heaps between 3.5Gbytes and 31Gbytes.

  • -d64: should be used for JVM heaps over 32Gbytes.

The JVM version used will depend on heap size.

Not applicable, except for the case when global index is used, otherwise it's unlikely that a Proxy Server will need more than 4GB of heap.

In most cases the 32-bit version of the JVM should be used.


Use this option if you use the 64-bit JVM and if the heap size is less than 32 Gbytes.

Set this parameter as described.

Not applicable a 64-bit JVM is required.

-Xms (Initial heap size)

-Xmx (Maximum heap size)

This parameter sets the initial and maximum heap size available to the JVM.

Increasing the heap size can improve performance, but setting it too high can have a detrimental effect in the form of longer pauses for full garbage collection runs. The initial and maximum sizes should generally be set to the same values.

For maximum performance, size the heap so that the entire DB can be cached in memory. In general, you should allocate enough heap for the server runtime and the rest to the DB cache.

If you use CMS as the garbage collector of the oldgen, you must take into account the -XX:CMSInitiatingOccupancyFraction property when you calculate the heap size so that it is coherent with the size (or percent of the heap) occupied by the dbcache.

If you set the CMSInitiatingOccupancyFraction to 55, the dbcache percent should be set to 50. Then if you have a database on disk that is 10GB, you need at least a heap of 22GB if you want the entire database to fit into the dbcache.

Set this parameter as described.




Set this parameter as described.




The total heap space is divided into the old generation and the young generation. This parameter sets the size of the young generation. The remaining memory (old generation) must be sufficient to hold the DB cache plus some overhead.

Set this parameter as described.



Set this parameter as described.




Use the Concurrent Mark Sweep (CMS) garbage collector. This option allows the JVM to minimize the response time of LDAP operations, but it can have a small impact on the overall performance (throughput) of the server. Use this option of long pause times are not tolerated.

Set this parameter as described.

Set this parameter as described.


Specify the level at which the CMS garbage collection is started. The default value is approximately 68%. Use this value if you want to set the percentage to something other than the default value.

If you use CMS as the garbage collector of the oldgen, then it is important to take into account the CMS property -XX:CMSInitiatingOccupancyFraction in the computation of the heap size such it is coherent with the size (or percent of the heap) occupied by the dbcache.

If you setup the CMSInitiatingOccupancyFraction to 55, then the dbcache percent should be setup to 50. Then if you have a db on disk that is 10GB, this means you need at least a heap of 22GB if you want all the db to fit into the dbcache.

Set this parameter as described.

Set this parameter as described.


Add -XX:UseCMSInitiatingOccupancyOnly if you specified -XX:CMSInitiatingOccupancyFraction=60, and the CMS collections are still starting before they reach that threshold. Remove the -XX:CMSInitiatingOccupancy=60 (using the default value of 69%), and consider adding the line: -XX:UseCMSInitiatingOccupancyOnly.

Set this parameter as described.

Set this parameter as described.


Improve locking performance in the server in cases where there is not expected to be a high degree of contention.

Set this parameter as described.

Set this parameter as described.


Use large pages for the information it stores in memory.

NOTE: This argument applies primarily to systems using the UltraSPARC T1 processor.

Set this parameter as described.

Set this parameter as described.


Causes a minor collection to occur just before the remark which reduces the remark pause time.

Set this parameter as described.

Set this parameter as described.


NOTE: This option should only be used on UltraSPARC Tx processors.

Set this parameter as described.

Set this parameter as described.

28.4.2 Tuning the Server Configuration

Various components of the server can be tuned to provide performance improvements in specific scenarios. Most performance tuning recommendations depend on several variables, including the anticipated workload, the types of data that are stored, and the hardware and resources available. The following general tuning recommendations can improve server performance in specific deployments. Oracle Berkeley DB Java Edition Tuning Parameters

Oracle Berkeley DB Java Edition is an open source, embeddable, transactional storage engine. The architecture of Oracle Berkeley DB Java Edition supports very high performance and concurrency for both read-intensive and write-intensive workloads.

The following Berkeley DB Java Edition (JE) tuning parameters can be used to tune performance:

Parameter Description

db-cache-percent and


Use these properties to configure the amount of memory that the database cache uses. db-cache-size is dependant on the size of the directory and the amount of available memory.

There are two caching options:

  • Fully cached in JVM heap.

    When the directory is small and there is enough memory available, the db-cache_size should be tuned to contain the entire node.This caching mode provides deterministic response times and low disk I/O, but requires large JVM heap and can impact garbage collection.

  • Partially cached in JVM heap, remainder cached in File System cache.

    When the directory is too large to store all of the nodes in memory, the db-cache-size should be tuned to contain only the Upper Inner Nodes (UpperIN) and the Bottom Inner Nodes (BIN). This caching mode also provides low disk I/O and can eliminate some of the issues related to large heap, but it can be slower and has slightly less deterministic response times (performance degradation is proportional to the amount of DB cached in the JVM).

    The size of the Inner Node can be computed using the DbCacheSize utility. For more information, see "Estimating the JE Cache Size".

Before you can accurately set the db-cache-size, you must first determine the approximate size of the database after an import. For example, after doing an import into the userRoot back end, run the following command (on UNIX systems) to determine the size of the database:

$ du -sk userRoot/
910616 userRoot/

On Windows systems, use an equivalent procedure to determine the database size. Remember that the database size is not static and can increase after an initial import when modifications are made.

Setting the JVM heap to 2 Gbytes (-Xms2g -Xmx2g), and the db-cache-percent to 50, will cause the DB cache to use 1 Gbyte of memory.


If true, the checkpointer uses more resources in order to complete the checkpoint in a shorter time interval. Btree latches are held and other threads are blocked for a longer period. Log cleaner record migration is performed by cleaner threads instead of lazily during eviction and checkpoints (see CLEANER_LAZY_MIGRATION). When set to true, application response time may be longer during a checkpoint, and more cleaner threads may be required to maintain the configured log utilization.

Setting that property to false is a way to achieve better throughput and lower response times.


You can configure the server to preload some of the database contents into memory on startup. For large databases, preloading the database cache avoids a long warm-up period after server startup.


Ensure that the database is held on a fast file system with adequate storage. The file system should be different to the location of the access logs. By default, the database will grow to twice its original size. For example, if the database is 1 Gbyte after an import, the file system should have at least 2 Gbytes available.


Use this property to control how the database cache retains information. Setting this value to false ensures that the internal nodes are maintained in cache, which provides better performance when the JE cache holds only a small percentage of the database contents.


Use this property to configure durability for write operations. Reducing durability can increase write performance, but it can also increase the chance of data loss in the event of a JVM crash or a system crash. This property takes the following values:

  • write-to-disk. All data are written synchronously to disk.

  • write-to-fs. Data are written to the file system immediately but might stay in the file system before being flushed to disk.

  • write-to-cache. Data are written to an internal buffer and flushed to the file system, then to disk when necessary.


Use this property to control the size of JE log files. Increasing the file size can improve write performance, but it can also make it harder to maintain the desired utilization percentage.


and db-cleaner-min-utilization

These properties control how the cleaner works, which keeps the database size down and keeps up with high write throughput. As older records become obsolete they are cleaned. The cleaning process can impact performance if not tuned.


On systems with a large number of CPUs, this property can improve concurrency within the database lock manager. Core Server Tuning Parameters

The following core server tuning parameters can be used to tune performance:

Parameter Description


This property can be configured so that the LDAP connection handler (and the LDAPS connection handler, if it is enabled) use multiple threads for decoding client requests. Increasing the number of threads on systems with a larger number of CPUs can improve performance. As a rule of thumb, you should set this property to a quarter the number of CPUs, with a maximum of twelve.

In some cases disabling the keep-stats property can help reduce lock contention in the connection handlers.


The default value of this property is two times the number of CPUs. This value is sufficient in most deployments.


Ensure that the access log publisher is on a fast file system, or turn it off altogether by setting the enabled property to false.

28.5 Advanced Tuning Recommendations

The following additional recommendations can improve performance in specific scenarios.

  • Enable an Entry Cache. In some cases, particularly those involving relatively small directories (for example, up to a few hundred thousand entries), it can be useful to enable an entry cache. In general the FIFO entry cache provides better results than the soft reference entry cache.

    For large databases, it is recommended that you store only a specific set of the data in the cache, by using the include-filter property. Storing static groups in the entry cache can greatly improve the overall performance of the server. This reduces the time required to perform group membership lookup, which is necessary in evaluating ACIs, for example.

  • Disable Unused Virtual Attributes. If the functionality needed by one or more of the virtual attributes is not required, they can be disabled for a slight performance improvement when decoding entries.

  • Disable Unused Access Logging. If access logging is not necessary, disabling the server access logger can help improve performance.

  • Disable Unused Access Control Handlers. If you do not need access control processing in the server, then you can disable it by setting the enabled configuration property to false for the Access Control Handler. You can set the property by using dsconfig.

  • Reduce Lock Contention. On systems with large numbers of CPUs (for example, chip multi-threading (CMT) systems with several hardware threads per core), you can reduce lock contention by setting the org.opends.server.LockManagerConcurrencyLevel system property to be equal to the number of worker threads you intend to use.

    NOTE: This property must be set as a JVM system property, because it can be required very early in the server startup process, even before accessing the server configuration.