LDAPWiki: FLAIM

Overview#

FLAIM is the underlying Data Store for eDirectory

FLAIM is a FLexible Adaptable Information Management database engine for traditional as well as volatile and complex information.

FLAIM is a very scalable database engine that supports multiple readers and a single-writer concurrency model.

FLAIM is an Open Source embeddable database engine developed by Novell INC and released under the GPL license in 2006.

By default eDirectory uses a block size of 4 KB. The FLAIM Block Cache size for caching the complete DIB is equal to the DIB size, and the size required for the FLAIM Entry Cache is about two to four times the DIB size.

FLAIM Operation#

FLAIM organizes data in blocks. Some of the blocks are typically held in memory. They represent the FLAIM Block Cache. The FLAIM Entry Cache (sometimes called a record cache) caches logical entries from the database. FLAIM Entry Cache is constructed from the items in the FLAIM Block Cache. FLAIM maintains hash tables for both caches. The hash bucket size is periodically adjusted based on the number of items.

While retrieving an entry, FLAIM first checks for the entry in the FLAIM Entry Cache. If the entry exists, the entry is returned.
If an entry is NOT in FLAIM Entry Cache, then FLAIM Block Cache queried and if present, the entry is returned.
If an entry is NOT in FLAIM Block Cache (and therefore not in FLAIM Entry Cache) then a disk read operation is necessary.

When an Update is preformed an an eDirectory entry, the corresponding blocks for that entry are not directly committed to the File System, so the File System and memory might not be in sync. However, the updates made to the entry are logged to the FLAIM Cache and Roll-Forward Log (RFL). The FLAIM checkpoint process will periodically start a CheckPointThread will commit any Dirty cache items to File System and clean up the Roll-Forward Log if required.

Least Recently Used (LRU) is the replacement algorithm used for replacing items in the FLAIM Cache.

FLAIM Memory Subsystem#

Server applications can perform significantly better when RAM is increased. Caching the eDirectory database in the File System or in the FLAIM Cache can lead to improved performances of search and modify operations.

However, you may not be able to cache the complete DIB in large deployments. Avoid using Swap Space even if it means reducing the FLAIM Entry Cache and FLAIM Block Cache sizes.

Use the vmstat tool to find more information on the memory subsystem.

As eDirectory uses memory, each thread from the thread pool uses 1 MB of RAM for its stack. By default, the FLAIM Cache size is set to 200 MB.

Several Loadable Modules are started when eDirectory starts, but the Loadable Module architecture of eDirectory allows you to reduce the memory footprint of the process by not loading the unused modules (for example, SecretStore, LDAP, or eMBox).

In addition, products like DirXML have some Loadable Module that run inside eDirectory.

The memory used by eDirectory might appear to be growing. Although memory is freed by an eDirectory Processes, the memory it might not be released to the Operating System free pool because the memory manager used internally by eDirectory tries to optimize the memory allocations for future. This is one of the reasons for not recommending FLAIM dynamic configuration.

Use the Top tool to find the approximate Virtual Memory size of the NDSD Processes in your deployment.

The maximum memory that can be allocated to a process is limited in several ways. A certain amount of RAM is used by the Operating System and other processes on the system. The Operating System can impose limitations on physical RAM that a process uses.

Edirectory Indexes are maintained with the FLAIM Block Cache.

FLAIM Settings#

_ndsdb.ini file controls the settings for FLAIM

Roll-Forward Log #

FLAIM logs operations for each update transaction in a Roll-Forward Log (RFL) file. An RFL is used to recover transactions from a system failure or when restoring from a backup. The RFL file is truncated after every CheckPointThread is completed unless it is turned on (rflkeepfiles) by using a hot continuous backup (http://www.novell.com/documentation/edir88/edir88/data/a2n4mb7.html).

FLAIM ndstrace #

ndstrace with Flag RECM can be used to monitor FLAIM operations

FLAIM Attribute Containerization #

FLAIM to ensure optimal utilization of the entry cache and enhanced performance of attribute Search Responses operations, FLAIM stores attributes with larger values or higher number of values in a separate location namely, Attribute Container. This process is referred to as FLAIM Attribute Containerization

FLAIM History#

FLAIM was originally used in Groupwise product and eDirectory, well NetWare, used an embedded RECMAN DataStore. RECMAN was not capable of using SubstringIndex and other LDAP Indexes and the change to FLAIM was done. This change also allowed for Novell Directory Services (NDS) to properly support LDAP and to be ported to other platforms such as Windows Server, Linux, and UNIX.

Category#

eDirectory

More Information#

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

[#1] http://en.wikipedia.org/wiki/Novell_eDirectory