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
Dynamic Cache Mode
Dynamic Cache Mode

Version management

Difference between version and

At line 1 added 23 lines
!!! Overview
[{$pagename}] is where the [FLAIM Cache] is managed by the [FLAIM] memory manager.
[{$pagename}] is when [FLAIM] polls the [Operating System], based off of a [specified time interval|cacheadjustinterval] to find available memory and requests the available memory from the [Operating System]. There are also configurable parameters with [{$pagename}] which allows the administrator to control how much of the free memory can be used by [eDirectory].
%%warning
Although [{$pagename}] works well in typical scenarios it is __[NOT RECOMMENDED]__ for optimal performance of [eDirectory] on [Linux] platforms because of large differences in [memory] usage patterns and [memory] allocators on [Linux] platforms.
%%
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 [File System] anyway to access the desired [data]. 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.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop