eDirectory Cache Settings for Million Object Trees
Novell Cool Solutions: Tip
By Subbu K.K.
Digg This -
Posted: 1 Oct 2001
Our online tuning guides recommend very large caches (four times the DIB size!). On machines with GBs of RAM, this is likely to lead to instability, if not capped to 2GB. eDirectory is designed to run as a 32-bit process with a 4GB limit in its virtual address space. If you set cache to 2GB or more, then during peaks of high activity the address space may exceed the OS limits for a 32-bit process and lead to its abrupt termination (crash, core dump, abend, crap out or whatever they call it these days). On Linux 2.4 kernels (e.g. RH 7.1), the process may run out of virtual address map entries and freeze.
For all those who are working on high-end tree deployments, use the following tips:
- Set the cache to an absolute figure of 1GB (or less). Do not use dynamic or hard settings on high-end deployments.
- Leave the max-threads, active interval and other esoteric parameters out of the nds.conf file. Let the replica server handle peaks and lows automatically. If the replica server maxes out, at least we will get a warning in the log.
- Leave the flushio, directio, and cache*interval settings out of the _ndsdb.ini file. blocksize has a built-in limit of 8192 and has no effect once the DIB is created. So you may leave this out too.
- Except during initial bulkload, don't set the blockcachepercent in the _ndsdb.ini file. If you need more block cache, increase the cache setting.
- Partition large trees generously. I normally limit a partition to about a million objects. It is faster to replicate and repair at this limit. Repair times increase very rapidly with the partition size and I don't have that many years left in my lifetime.
- Keep the root partition small - it contains the schema and security OUs which don't change much. I would rather have a root canal than deal with a large corrupted Root partition!
- Complete partitioning and replica servers before populating large trees. This may take slightly longer, but at least the tree is stable as it grows.
- On high end Solaris servers with more than 4 processors, it is better to create processor sets of not more than 4 processors and bind an instance of ndsd to the set. ndsd can then exploit warm on-chip caches to speed up its operations.
- Lastly, keep an eye on the disk space consumption on the DIB volumes. Apart from the DIB, this space also contains the repair logs, trace logs and the transaction logs. If the replica server runs out of space, it can fail in mysterious ways.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com