test

Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide

Top Tuning Tips

Basic recommendations follow. These recommendations apply in most situations. Although the recommendations presented here are in general valid, avoid the temptation to apply the recommendations without understanding the impact on the deployment at hand. This section is intended as a checklist, not a cheat sheet.

  1. Adjust cache sizes.

    Ideally, the server has enough available physical memory to hold all caches used by Directory Server. Furthermore, an appropriate amount of extra physical memory is available to account for future growth. When plenty of physical memory is available, set the entry cache size large enough to hold all entries in the directory. Use the entry-cache-size suffix property. Set the database cache size large enough to hold all indexes with the db-cache-size property. Use the dn-cache-size or dn-cache-count properties to control the size of the DN cache.

  2. Optimize indexing.

    1. Remove unnecessary indexes. Add additional indexes to support expected requests.

      From time to time, you can add additional indexes that support requests from new applications. You can add, remove, or modify indexes while Directory Server is running. Use for example the dsconf create-index and dsconf delete-index commands.

      Be careful not to remove system indexes. For a list of system indexes, see System Indexes and Default Indexes in Sun Java System Directory Server Enterprise Edition 6.2 Reference.

      Directory Server gradually indexes data after you make changes to the indexes. You can also force Directory Server to rebuild indexes with the dsconf reindex command.

    2. Allow only indexed searches.

      Unindexed searches can have a strong negative impact on server performance. Unindexed searches can also consume significant server resources.

      Consider forcing the server to reject unindexed searches by setting the require-index-enabled suffix property to on.

    3. Adjust the maximum number of values per index key with the all-ids-threshold property.

  3. Tune the underlying operating system according to recommendations made by the idsktune command. For more information, see idsktune(1M).

  4. Adjust operational limits.

    Adjustable operational limits prevent Directory Server from devoting inordinate resources to any single operation. Consider assigning unique bind DNs to client applications requiring increased capabilities, then setting resource limits specifically for these unique bind DNs.

  5. Distribute disk activity.

    Especially for deployments that support large numbers of updates, Directory Server can be extremely disk I/O intensive. If possible, consider spreading the load across multiple disks with separate controllers.

  6. Disable unnecessary logging.

    Disk access is slower than memory access. Heavy logging can therefore have a negative impact on performance. Reduce disk load by leaving audit logging off when not required, such as on a read-only server instance. Leave error logging at a minimal level when not using the error log to troubleshoot problems. You can also reduce the impact of logging by putting log files on a dedicated disk, or on a lesser used disk, such as the disk used for the replication changelog.

  7. When replicating large numbers of updates, consider adjusting the appropriate replication agreement properties.

    The properties are transport-compression, transport-group-size, and transport-window-size.

  8. On Solaris systems, move the database home directory to a tmpfs file system.

    The database home directory, specified by the db-env-path property, indicates where Directory Server locates database cache backing files. Data files continue to reside by default under instance-path/db.

    With the database cache backing files on a tmpfs file system, the system does not repeatedly flush the database cache backing files to disk. You therefore avoid a performance bottleneck for updates. In some cases, you also avoid the performance bottleneck for searches. The database cache memory is mapped to the Directory Server process space. The system essentially shares cache memory and memory used to hold the backing files in the tmpfs file system. You therefore gain performance at essentially no cost in terms of memory space needed.

    The primary cost associated with this optimization is that database cache must be rebuilt after a restart of the host machine. This cost is probably not a cost that you can avoid, however, if you expect a restart to happen only after a software or hardware failure. After such a failure, the database cache must be rebuilt anyway.

  9. Enable transaction batches if you can afford to lose updates during a software or hardware failure.

    You enable transaction batches by setting the server property db-batched-transaction-count.

    Each update to the transaction log is followed by a sync operation to ensure that update data is not lost. By enabling transaction batches, updates are grouped together before being written to the transaction log. Sync operations only take place when the whole batch is written to the transaction log. Transaction batches can therefore significantly increase update performance. The improvement comes with a trade off. The trade off is during a crash, you lose update data not yet written to the transaction log.

    Note –

    With transaction batches enabled, you lose up to db-batched-transaction-count - 1 updates during a software or hardware failure. The loss happens because Directory Server waits for the batch to fill, or for 1 second, whichever is sooner, before flushing content to the transaction log and thus to disk.

    Do not use this optimization if you cannot afford to lose updates.

  10. Configure the referential integrity plug-in to delay integrity checks.

    The referential integrity plug-in ensures that when entries are modified, or deleted from the directory, all references to those entries are updated. By default, the processing is performed synchronously, before the response for the delete operation is returned to the client. You can configure the plug-in to have the updates performed asynchronously. Use the ref-integrity-check-delay server property.