Service manual

Optimizing for Updates
Chapter 6 Tuning Cache Sizes 121
Alternatively, if search patterns are less random,you may choose to set entry and
database caches higher onthe assumption that most of the searches in the
particular deployment access the same small subset of all entries in the directory,
and that the gains from having entries and indexes cached for such searches offset
the cost of handling occasionalunusual search requests. Verify and correct
assumptions through empirical testing.
Low Memory, Low File System Cache
Imagine asystem with insufficient available memory both for holding data inentry
and database caches, but also for allowing the system to cache data in the file
system cache. The key in thiscase is to make the most of theavailablememory you
have.
Consider settingentry and databasecachesizesas lowas possible, leaving asmuch
memory as possible to the file system cache. Leaving memory to the file system
cache at least prevents entries from being expanded into database or entry by a
factor of 3 to 4.5, theoretically limiting the disk I/O activity. Verify this assumption
through empirical testing for the particular deployment.
Optimizing for Updates
Fortopupdateperformance,firstremoveany transactionlogbottlenecksobserved.
Refer to “Transaction Logging,” on page 147 for details.
Next, attemptto provideenough memoryforthe database cache tohandleupdates
in memory and minimize disk activity. You can monitor the effectiveness of the
database cache by reading the hit ratio in Directory Server Console. Directory
ServerConsole displays hit ratios for suffixes under the Status tab as shown in
Figure 6-5 on page 119.
Attempt as well to leave significant memory available for the file system cache.
After Directory Server has run for some time, the file system cache 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 can itself be a bottleneck, so storing the database on a
separate RAID system such as a Sun StorEdge™ disk array can help improve
update performance. You may use utilities such as
iostat(1M) on Solaris systems
to isolate potential I/O bottlenecks. Refer to Windows help for details on handling
I/O bottlenecks onWindows systems.