FLAIM Cache is the eDirectory Data Store cache as used in FLAIM

The primary reason for reading this is for eDirectory Performance Tuning and Capacity Management

Two Types of FLAIM Cache#

Page Cache#

Many Operating Systems use Page Cache to improve performance.

Page Cache caches disk operations in RAM and minimizes the need for applicaitons to perform caching. (ie FLAIM Block Cache)

Virtual Memory#

Many Operating Systems use Virtual Memory to enhance and expand RAM utilization.

General Rule: Avoid using swap Space even if it means reducing the FLAIM Cache sizes.

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.

Static Mode#

As of eDirectory, and later version, FLAIM Cache is statically set and preallocated.

Other Info#

On 32 bit Operating Systems maximum limit for all NDSD processes and necessary resources is 3 GB, including eDirectory FLAIM Cache and Loadable Module.

The amount of memory required to FLAIM Block Cache the complete database in the FLAIM Block Cache is the size of the database on the disk.

The amount of memory required to cache the complete database in the FLAIM Entry Cache is nearly two to four times the DIB size on the disk.

When you have less memory on a system, try a smaller FLAIM Entry Cache and a much larger FLAIM Block Cache or Operating System Page Cache.

If reads are localized to a set of entries in the eDirectory, you should increase the FLAIM Entry Cache as long as it results in an improved entry cache hit ratio.

If the read pattern is completely random and the DIB is much larger than the available RAM, you should have a larger FLAIM Block Cache or Operating System Page Cache.

Any method you use to tune eDirectory for an improved performance needs empirical testing. A good ratio of FLAIM Entry Cache to FLAIM Block Cache for search‐intensive environments is 2:1 ratio.

Ensure that sufficient memory is left for other processes.

Avoid page swapping even if it means reducing the FLAIM Cache sizes.

Because FLAIM provides preallocated caching, memory allocated to the FLAIM Cache is never fragmented by the native Operating System memory manager.

Two FLAIM Cache Configuration Modes#

  • Dynamic Mode
  • Static Mode

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.

The basic difference between the two modes is that with dynamic 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 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 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.

IMPORTANT:When dealing with available memory, most operating systems will utilize a Swap Space file. If information has to be "Swapped" in and out of memory to disk, performances will suffer.

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 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 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 Mode#

Dynamic Mode allocation wants to use memory based on how much your system has available which is fine on smaller systems.

Static Mode#

As of eDirectory 8.8 SP5, and later version, FLAIM Cache is statically set and preallocated. On Linux Operating Systems caching using Swap Space

Although dynamic 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 mode is used while determining the optimal settings.

When memory is released by a process, it is the responsibility of the Operating System to add the released memory back to the free memory pool. Each Operating System handles this differently.

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.

TIP: With both static and dynamic memory, memory is not automatically allocated to NDSD. NDSD will request memory as needed until the limits are hit.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-26) was last changed on 05-Jan-2017 12:00 by jim