Overview#

Dynamic Cache Mode is when FLAIM polls the Operating System, based off of a specified time interval to find available memory and requests the available memory from the Operating System. There are also configurable parameters with Dynamic Cache Mode which allows the administrator to control how much of the free memory can be used by eDirectory.

Although dynamic mode is very efficient and will work well for most eDirectory implementations, there are some limitations. By default, dynamic mode will consume up to 80% of available cache. This can cause several issues:

• The maximum Virtual Memory space can be reached. If there is a large amount of memory on the system, it is possible for the maximum amount of Virtual Memory space per process that is defined by the Operating System can be reached. As stated previously, the adverse effect of this varies depending on what eDirectory operations are occurring when this state is hit.
• eDirectory can starve other processes running on the server of memory. The file system, communication protocols and other applications require memory as well. If only 20% of memory is left for these applications, which also includes the eDirectory application itself, depending on the amount of memory on the server, the other applications may show performance degradation.
• eDirectory Application can be starved of memory. As just mentioned, if only 20% of available memory is left on the server, it is possible that all of the processes that require memory from the eDirectory application could experience slowness. If there is not enough available memory to perform a said operation, the information will have to be swapped in and out of memory to disk. Disk I/O is slow and will cause slower performance in many eDirectory operations.
• Increased overhead with database functions. It stands to reason that the more database cache allocated, the more overhead will be required to maintain the cache. With this in mind, more memory assigned to database cache is not always better. There is a point in which the overhead required to maintain the database cache creates more of a performance hit to the eDirectory operations than going to disk to access the information in the first place.
• The database is too large to load a reasonable amount of cache into memory. eDirectory is a highly scalable identity management system. It is not atypical to see an eDirectory database that exceeds several GB. In these circumstances, it does not make sense to load a lot of information (that represents only a small set of data) into memory. Wasted resources are used to scan through memory, just to find that in most cases, eDirectory needs to go to File System anyway to access the desired data. By limiting the amount of database cache in these cases will decrease the amount of overhead required to scan through the cache and determine that it is necessary to go to disk to get the information.

More Information#

• Cacheadjustinterval
• FLAIM Cache
• Hard cache limit
• _ndsdb.ini