!!! Overview
[{$pagename}] is the [eDirectory] [Data Store|DataStore] [cache] as used in [FLAIM] ( i.e [eDirectory])


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

!! Two Types of [{$pagename}]
* [FLAIM Block Cache]
* [FLAIM Entry 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 [{$pagename}] Configuration Modes
* [Dynamic Cache Mode]
* [Static Cache Mode]

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

! [Static Cache Mode]
As of [eDirectory], and later version, [{$pagename}] is statically set and [preallocated|preallocatecache].



!! [{$pagename}] Options
[eDirectory]'s [{$pagename}] 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]
[{$pagename}] with [Dynamic Cache Mode], [{$pagename}] 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.

IMPORTANT: When dealing with available memory, most [Operating System] 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 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 [{$pagename}]. 

[Dynamic Cache Mode] configuration options through NDS [Imonitor] can be used to control the maximum amount of memory that is assigned to [{$pagename}], it is recommended that [Static Cache 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 [{$pagename}] is using, thus freeing the memory for file system to use. An administrator could decrease the amount of c[{$pagename}] (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.

!! Other Info

On 32 bit [Operating Systems] maximum limit for all [NDSD] processes and necessary resources is 3 GB, including eDirectory [{$pagename}] 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|DIB] 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.

!! Links
* [NetIQ® eDirectory™ 8.8 SP8 Tuning Guide September 2013|https://www.netiq.com/documentation/edir88/pdfdoc/edir88tuning/edir88tuning.pdf|target='_blank']
* [Setting a Hard Limit for the eDirectory Cache on Linux|https://www.netiq.com/communities/cool-solutions/setting-hard-limit-edirectory-cache-linux/ |target='_blank']
* [eDirectory Best Practices Guide, memory configuration for eDirectory|https://www.novell.com/support/kb/doc.php?id=3178089|target='_blank']

!! Category
%%category [eDirectory]%%

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [NetIQ® eDirectory™ 8.8 SP8 Tuning Guide September 2013|https://www.netiq.com/documentation/edir88/pdfdoc/edir88tuning/edir88tuning.pdf|target='_blank']
* [Setting a Hard Limit for the eDirectory Cache on Linux|https://www.netiq.com/communities/cool-solutions/setting-hard-limit-edirectory-cache-linux/ |target='_blank']
* [eDirectory Best Practices Guide, memory configuration for eDirectory|https://www.novell.com/support/kb/doc.php?id=3178089|target='_blank']