As I get closer to my first real enterprise deployment of OpenDJ I’ve been scouring around for information on tuning important stuff like caches and resource limits. Two important resources follow.
OpenDJ Product Manager Ludo Poitou posted a couple of very timely articles last month that every enterprise directory admin should read:
Both of these articles are important because in them Ludo points out some interesting ways that OpenDJ behaves differently from earlier directory servers (i.e., Sun Directory Server).
In the first he points out that there are both global and individual entry resource limits in OpenDJ. That means, for example, that “cn=Directory Manager” has its own personal limits (set under “cn=Directory Manager,cn=Root DNs,cn=config”). As it turns out DM’s limits are… unlimited. That means that if you make changes to the global limits and want to test the result, using the DM account to do it is not going to give you an accurate picture. It also means that you can customize resource limits by binddn, something that be useful if you have one or more accounts that need/do not deserve preferred treatment.
The second article discusses the differences between caching in previous directory servers and OpenDJ. The most significant point Ludo makes here is that entry caching, which used to be classified as “A Good Thing [TM]” is no longer favored. Instead the OpenDJ team now recommends relying more heavily on database caching. The current default under OpenDJ 2.4.5 is 10% of JVM heap. In the next version, 2.5.x, this will increase to 50%. What that means is that if you’re deploying a new OpenDJ 2.4.5 today you may want to consider bumping the database cache to at least 50% of heap. In my case gathering good data for cache tuning is now going right to the top of testing list.