Overview#FLAIM Cache is the eDirectory Data Store cache as used in FLAIM ( i.e eDirectory)
Two Types of FLAIM Cache#Operating Systems use Page Cache to improve performance. Operating Systems use Virtual Memory to enhance and expand RAM utilization.
Two FLAIM Cache Configuration Modes#
Dynamic Mode#Dynamic Mode allocation wants to use memory based on how much your system has available which is fine on smaller systems. eDirectory, and later version, FLAIM Cache is statically set and preallocated.
FLAIM Cache Options#eDirectory's FLAIM Cache is an important factor when speaking about performance. It is well known that accessing and updating information in memory is much faster than having to go to disk, find the information, load it into memory, make the changes or read the information and then write it back to disk. It stands to reason that if eDirectory loads as much information into memory as possible, without starving other processes (within eDirectory's virtual address space or without its space) of memory, eDirectory can achieve optimal performance. The trick for an eDirectory administrator is to determine the maximum amount of memory to allocate towards eDirectory's database cache to achieve optimal performance. There are two modes in which eDirectory can determine the maximum amount of memory to use for database cache, namely, dynamic mode and static mode. Dynamic Cache Mode, FLAIM Cache 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.
Dynamic Cache Mode is very efficient and will work well for most eDirectory implementations, there are some limitations. By default, Dynamic Cache 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 disk anyway to access the desired information. 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.
With the above factors in mind, the maximum amount of cache allowed for database cache becomes a crucial factor to performance. As a general rule, the recommendation for most systems would be to implement eDirectory with the default cache mode, which is Dynamic Cache Mode. Make configuration changes only if eDirectory, as well as other applications on the same server, performance is not acceptable and the performance can be directed at memory consumption.
In the case where performance is not acceptable, eDirectory, through NDS iMonitor has provide some tools that will assist in determining the correct settings. It is recommended that Static Cache Mode is used in conjunction with the statistics in NDS iMonitor as well as other performance tests.
IMPORTANT:NDS Imonitor provides statistics about how cache is being used. However, it is a mistake to rely only on the statistics provided through NDS iMonitor because the statistics can not identify adverse effects that could occur if too much memory is allocated to eDirectory's FLAIM Cache.
Dynamic Cache Mode configuration options through NDS Imonitor can be used to control the maximum amount of memory that is assigned to FLAIM Cache, it is recommended that Static Cache Mode is used while determining the optimal settings.
False assumptions can be made if this is not understood and watched. If, for instance, the file system is being starved of memory which is causing I/O performance issues, a logical step would be to decrease the amount of FLAIM Cache is using, thus freeing the memory for file system to use. An administrator could decrease the amount of cFLAIM Cache (either with static or dynamic settings). If NetWare does not add the released memory to the free pool, NSS will not be able to immediately use the newly freed memory. Before NSS consumes the memory, a new performance test is ran and the results are that there is no change when in actuality, the change made may increase performance after NSS consumes the memory.
Because dynamic cache scans the available memory pool, there are a lot of variables to consider. This can be simplified by setting a static limit when determining optimal settings because the setting is not completely based off of available memory.
Ensure that sufficient memory is left for other processes.
Avoid page swapping even if it means reducing the FLAIM Cache sizes.
- NetIQ® eDirectory™ 8.8 SP8 Tuning Guide September 2013
- Setting a Hard Limit for the eDirectory Cache on Linux
- eDirectory Best Practices Guide, memory configuration for eDirectory
More Information#There might be more information for this subject on one of the following:
- Dynamic Cache Mode
- EDirectory Monitor Entry
- FLAIM Block Cache
- FLAIM Cache
- FLAIM Entry Cache
- FLAIM checkpoint
- Hard cache limit
- Static Cache Mode