Sun Java(TM) System Directory Server 5.2 2005Q1 Performance Tuning Guide |
Chapter 1
Top Tuning TipsTuning performance implies modifying the default configuration to reflect specific deployment requirements.
This guide describes how to tune a single Directory Server instance. It is assumed here that your overall directory service design including the replication topology is complete, and that you use the information here to tune the Directory Server instances to meet the design requirements. If you have not yet completed the overall directory service design, refer to the Directory Server Deployment Planning Guide for suggestions on how to do so.
Tuning performance takes time, effort, and thought as reflected in Table 1-1.
This chapter lists basic recommendations that apply almost every time you tune a Directory Server instance. Although the recommendations presented here are in general valid, avoid the temptation to apply them without understanding how they impact the specific deployment at hand. This chapter is intended as a checklist, not a cheat sheet.
- Adjust cache sizes.
Ideally, the server has enough available physical memory to hold all caches used by Directory Server, and an appropriate amount of extra available physical memory to account for future growth. In the case where plenty of physical memory is available, set the entry cache size large enough to hold all entries in the directory, and set the database cache size large enough to hold all indexes including the content of all *_id2entry.db3 files.
Refer to Chapter 3, "Tuning Cache Sizes," for more information.
- Optimize indexing.
- Remove unnecessary indexes and add additional indexes to support expected requests.
From time to time, it may become necessary to add additional indexes that support requests from new applications. It is possible to add, remove, and modify indexes while Directory Server is running. Directory Server gradually indexes data after you make changes to the indexes. You can also force Directory Server to rebuild indexes.
Refer to Benefits: How Searches Use Indexes and Costs: How Updates Affect Indexes for more information.
- Allow only indexed searches.
Unindexed searches can have a strong negative impact on server performance and may consume significant server resources. Consider adding indexes to support specific searches applications may perform, and forcing the server to reject unindexed searches.
Refer to Allowing Only Indexed Searches for more information.
- Adjust the maximum length of index lists.
Refer to Limiting Index List Length for more information.
- Tune the underlying operating system.
Refer to Chapter 2, "Tuning the Operating System," for more information.
- 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.
Refer to Chapter 6, "Managing Use of Other Resources," for more information.
- Distribute disk activity.
Especially for deployments supporting large numbers of updates, Directory Server can be extremely disk I/O intensive. If possible, consider spreading the load across multiple disks using separate controllers.
- Disable unnecessary logging.
Disk access being slower than memory access, heavy logging can 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, and leave error logging at a minimal level when not using the error log to troubleshoot problems. You may also reduce the impact of logging by putting log files on a lesser used disk, such as the disk used for the replication changelog.
Refer to Chapter 5, "Tuning Logging," for more information.
- When replicating large numbers of updates, consider adjusting network configuration parameters related to replication as described in the Directory Server Administration Guide.
- (Solaris systems) Move the database home directory to a tmpfs file system.
The database home directory, specified by nsslapd-db-home-directory, indicates where Directory Server locates database cache backing files. (Data files continue to reside by default under ServerRoot/slapd-serverID/db.) By placing the database cache backing files on a tmpfs file system, you keep the system from flushing the database cache backing files to disk from time to time, therefore avoiding a performance bottleneck for updates, and in some cases even for searches. As 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 or reboot. This cost is probably not one you can avoid, however, if you expect a restart or reboot to happen only after a crash. After a crash, the database cache has to be rebuilt anyway.
- Enable transaction batching if you can afford to lose updates during a crash.
Each update to the transaction log is followed by a sync operation to ensure update data is not lost. By enabling transaction batching, updates are grouped together before being written to the transaction log, and sync operations only take place when the whole batch is written to the transaction log. Enabling transaction batching can therefore significantly increase update performance, with the trade off that during a crash, you lose update data not yet written to the transaction log.
- 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. Refer to Configuring Server Plug-Ins for details.