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 performance in specific deployments.

• Back End Tuning Parameters. The following Berkeley DB JE tuning parameters can be used to tune performance:

  • preload-time-limit. 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 warmup period after server startup. For more information, see the Local DB Backend Configuration.

  • Use the db-cache-percent and db-cache-size properties to configure the amount of memory that the database cache uses. For best performance, consider configuring the server so that the whole database fits into the database cache.

    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:

    $ cd install-dir/db
    $ 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. To monitor the DB cache size, observe the following properties under the "dn:cn=userRoot Database Environment,cn=monitor" entry through Jtrace and JMX:

    • Check that EnvironmentCacheDataBytes has a value that is consistent with the expected size of the DB cache.

    • Check that EnvironmentNCacheMiss does not have unexpected growth when loading the server.

  • db-directory. 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.

  • db-evictor-lru-only. Use this property can be used 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.

  • db-txn-no-sync and db-txn-write-no-sync. Use these properties 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.

  • db-log-file-max. 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.

  • db-num-cleaner-threads 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.

  • On systems with a large number of CPUs, the db-num-lock-tables configuration property improves concurrency within the database lock manager.

• Core Server Tuning Parameters. The following core server tuning parameters can be used to tune performance:

  • num-request-handlers. 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 half the number of CPUs.

    In some cases disabling the keep-stats property can help reduce lock contention in the connection handlers. For more information, see the LDAP Connection Handler Configuration.

  • num-worker-threads. The default value of this property is two times the number of CPUs. This value is sufficient in most deployments.

  • log-file. Ensure that the access log publisher is on a fast file system, or turn it off altogether by setting the enabled property to false. For more information see the File Based Access Log Publisher Configuration.

• 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 more information, see the Entry Cache Configuration.

• 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. For more information, see the Virtual Attribute Configuration.

• Disable Unused Access Logging. If access logging is not necessary, disabling the server access logger can help improve performance. For more information, see the Log Publisher Configuration.

• 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.

  ---