The easiest way to monitor, control, and configure Database cache values for eDirectory is via iMonitor. iMonitor runs on all platforms that eDirectory runs on. There are TIDs that define the port, but in general they come in pairs: http and then https.

Usually if the port is in use, eDirectory defaults to 2 higher for each. You can use "netstat -a" on the host OS to see what ports in the range are in use.

The image below shows a typical iMonitor screen.

Click to view.

When iMonitor is open in your browser, as in the image, look in the right-hand column, lower set of links, then click on Agent Configuration. Above it, the list of links will change and include Database Cache.

eDirectory Database Cache Settings

There are several options for eDirectory Database Cache settings.

eDirectory supports dynamic memory allocation or static allocation. In general, static is better as there is less overhead for the OS to maintain it, and it is more predictable. Novell Support seems to be leaning towards recommending static memory definition, but clearly there are cases where either might make more sense. Consider your environment and try to choose wisely.

At the top, you will see how big your DIB is, in KB. This is much easier than looking for the DIB file and checking its size. It would be nice to be able to cache the whole thing in RAM, and for a variety of reasons I have never had completely explained to my liking, actually 5 times in RAM. That is - entry once, block 4 times. This is not really a problem when your DIB is 20-100MB in size. If it is 200MB you start having a problem finding enough RAM for that. Regardless, the more RAM the merrier - within reason.

In this case, the DIB is about 28 Megs, and we have hard-coded it to use 128 Megs of RAM for cache. To get a feel for the size, this DIB has about 6000 users, 3500 groups, and lots of group memberships. 28MB is not that much space for that many users, when you come down to it.

You can see that about 82MB of the 128MB allocated is actually being used by cache, and that the split is not fifty-fifty. Should we hit the max allocated, then the fifty-fifty split would be enforced, as the Max Entry and Max Block lines show. If this becomes an issue for you, use the Block Cache percentage option at the bottom to change away from the fifty-fifty split.

One thing to watch out for is that usually 2GB is the maximum you can assign, since that is the largest memory space most OS's and eDirectory can support. It is worth mentioning that the Java instance that runs Identity Manager components runs within this 2 GB memory space. So if you have IDM, and you need 512MB of space for the Java components (which is reasonable for a multi-driver system), that only leaves you 1.5GB for eDirectory cache itself.

Be aware that if you have a server with slow DS performance, every so often an update or version of eDirectory hard-codes itself to 16MB of cache. (The default used to be 8 MB!) Linux eDirectory on a fresh install defaults to 16MB. That's easy enough to change, and it takes effect live.

You also get to see stats on hits and misses to the cache, which is nice to know. In this case, 99% of the hits were served from cache. This is pretty good and should be typical. Like all caches, it may take some time after a reboot to get the stats to be what you are looking for.