This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
FLAIM
FLAIM

Version management

Difference between version and

At line 1 added 71 lines
!!! Overview
[{$pagename}] is the underlying [Data Store|DataStore] for [eDirectory]
[{$pagename}] is a [FLexible Adaptable Information Management] [database] engine for traditional as well as volatile and complex information.
[{$pagename}] is a very scalable [database] engine that supports multiple readers and a single-writer concurrency model.
[{$pagename}] is an [Open Source] embeddable [database] engine developed by [Novell INC] and released under the [GPL] [license] in [2006|Year 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.
!! [{$pagename}] Operation
[{$pagename}] 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]. [{$pagename}] maintains [hash] tables for both [caches]. The [hash] bucket size is periodically adjusted based on the number of items.
* While retrieving an entry, [{$pagename}] 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].
!! [{$pagename}] 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 Module]s 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].
!! [{$pagename}] Settings
[_ndsdb.ini] file controls the settings for [{$pagename}]
!! [Roll-Forward Log]
[{$pagename}] 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).
!! [{$pagename}] [ndstrace]
[ndstrace] with Flag [RECM] can be used to monitor [{$pagename}] operations
!! [FLAIM Attribute Containerization]
[{$pagename}] 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]
!! [{$pagename}] History
[{$pagename}] 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 [{$pagename}] 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
%%category [eDirectory]%%
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
[#1] [http://en.wikipedia.org/wiki/Novell_eDirectory]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop