Chapter 1 Top Tuning Tips

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

Table 1-1 Tuning Process
Phase	Description
Define goals	Define specific, measurable objectives for tuning, based on deployment requirements. Consider questions such as: Which applications use Directory Server? Is the system dedicated to Directory Server? Does it run other applications? If so, which other applications? How many entries does the deployment call for? How large are such entries? How many searches per second must the Directory Server support? What types of searches are expected? How many updates per second must the Directory Server support? What types of updates are expected? What sort of peak update and search rates are expected? What sort of average rates are expected? Does the deployment call for repeated bulk import initialization on this system? If so, how often are imports performed? How many entries are imported at a time? What types of entries? Must initialization be performed online with the server running? This list is not exhaustive. Ensure yours is.
Select methods	Determine how you plan to implement tuning optimizations and how you plan to measure and analyze them. Can you change the hardware configuration of the system? Are you limited to using existing hardware, tuning only the underlying operating system and Directory Server itself? How can you simulate other applications? How should you generate representative data samples for testing? How should you measure results? How should you analyze results?
Perform tests	Carry out the tests planned. For large and complex deployments, this phase may take considerable time.
Verify results	Check whether the potential optimizations tested reach the goals defined at the outset of the process. If they reach the goals, document the results. If they do not reach the goals, profile and monitor the Directory Server you are tuning.
Profile and monitor	Profile and monitor the behavior of Directory Server after applying the potential modifications. Collect measurements of all relative behavior.
Plot and analyze	Plot and analyze the behavior observed while profiling and monitoring. Attempt to find evidence and patterns that suggest further tests. You may need to go back to the profiling and monitoring phase to collect more data.
Tweak and tune	Apply further potential optimizations suggested by your analysis of measurements. Return to the phase of performing tests.
Document results	Once the optimizations applied reach the goals defined at the outset of the process, document them well so they can be easily reproduced.

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.



Note	With transaction batching enabled, you lose up to (nsslapd-db-transaction-batch-val - 1) updates during a crash, because Directory Server waits for the batch to fill (or 1 second, whichever is sooner) before flushing content to the transaction log. Do not use this optimization if you cannot afford to lose updates.

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.

Previous Contents Index Next
Sun Java(TM) System Directory Server 5 2004Q2 Performance Tuning Guide