test

Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide

Optimizing Cache for Write Performance

In addition to planning a deployment for write scalability from the outset, provide enough memory for the database cache to handle updates in memory. Also, minimize disk activity. You can monitor the effectiveness of the database cache by reading the hit ratio in the Directory Service Control Center.

After Directory Server has run for some time, the caches should contain enough entries and indexes that disk reads are no longer necessary. Updates should affect the database cache in memory, with data from the large database cache in memory being flushed only infrequently.

Flushing data to disk during a checkpoint can be a bottleneck. The larger the database cache size, the larger the bottleneck. Storing the database on a separate RAID system, such as a Sun StorEdgeTM disk array, can help improve update performance. You can use utilities such as iostat on Solaris systems to isolate potential I/O bottlenecks. For more information, see the iostat(1M) man page.

The following table shows database and log placement recommendations for systems with 2, 3, and 4 disks.

Table 9–1 Isolating Databases and Logs on Different Disks

Disks Available 

Recommendations 

2 

  • Place the Directory Server database on one disk.

  • Place the transaction log, the access, audit, and error logs and the retro change log on the other disk.

3 

  • Place the Directory Server database on one disk.

  • Place the transaction log on the second disk.

  • Place the access, audit, and error logs and the retro change log on the third disk.

4 

  • Place the Directory Server database on one disk.

  • Place the transaction log on the second disk.

  • Place the access, audit, and error logs on the third disk.

  • Place the retro change log on the fourth disk.