0

I'm trying to understand how memory allocation for dbcache is being handled by OpenDJ in tandem with java vm. There is a couple of things I couldn't get completely, though. As mentioned here, it's possible to allocate some predefined amount of RAM for the sole purpose of caching the database. It also mentioned here and there, that OpenDJ may attempt to store as much db files in memory as possible. 2 questions so far:

  1. Is dbcache actually a part of the heap? If answer is "yes", then where exactly is memory for it being allocated? I.e., is it the Old Generation space, Permanent Generation space, or even Young Generation space? Or may be it is neither of them, and it cannot be seen in usual heap memory zone's (meaning it isn't placed in the heap, but in its own memory space which size is simply derived from the size of the heap using the settings this article mentions)?
  2. Can I somehow ensure (i.e. is there specific settings for that in the OpenDJ) that my complete db is cached during service's start up, and make sure that otherwise (i.e. if allocated RAM's size isn't set correctly, or there is not enough RAM) the service simply won't start?

Any help is appreciated.

Taipen
  • 13
  • 4

1 Answers1

0

Funny you're referring to my blog... 1/ Yes, dbcache is part of the JVM heap. OpenDJ let the JVM decides where to allocate the dbcache. Normally it is allocated in the New Generation space, but if the amount to be allocated exceeds the size of the New Gen, it's allocated in the Old Generation space.

2/ OpenDJ has an option to specify whether the server should pre-load the cache and the maximum amount of time it should spend trying to pre-load it. Please check the OpenDJ administration guide, and it's Tuning For Performance section for details.

There is no way to prevent the server from starting if the whole DB is not cached. I cannot think of a valid use case for this specific behaviour.

Ludovic Poitou
  • 4,788
  • 2
  • 21
  • 30
  • Hi, Ludovic, thank you for clarification. The use case could be some highly loaded system which possess a lot of unused memory (so it can afford spending 1-2GB for full DB cache), and, at the same time, must comply to strict SLA governing a repsonse times. That would allow its admin to always be sure, that if the service were able to start that means that cache was created successfully, otherwise he provided incorrect values for some memory-related settings (which can be easily tuned right away). Without that he can't be sure that system is always performs at the top of its capabilities. – Taipen Oct 14 '15 at 14:41
  • May I also ask this: is there a way to diagnose how much of a database's contents is actually cached at the moment? – Taipen Oct 14 '15 at 14:41
  • One more question: how actually db cache is represented in code? Is it a single large object, or a multitude of smaller objects? If it's the latter, then is it possible that some of these objects which are being referenced relatively infrequently will be "dropped" (removed/deallocated) by working OpenDJ's instance at some point, even despite they were initially pre-loaded because of preload option was set? – Taipen Oct 14 '15 at 17:16
  • There is monitoring information about the database and its cache utilisation available through LDAP or JMX. The details of implementation of the cache is specific to the embedded key-value store. But yet, pre-loading the cache doesn't mean that cached objects will remain in the cache forever. A cache is a cache and when it becomes full, objects start to be evicted from it. – Ludovic Poitou Oct 21 '15 at 07:19