NetIQ® eDirectory™

Tuning Guide
October 2019
Legal Notice
For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government
rights, patent policy, and FIPS compliance, see https://www.netiq.com/company/legal/.

Copyright © 2019 NetIQ Corporation, a Micro Focus company. All Rights Reserved.
Contents

About this Book and the Library 5

About NetIQ Corporation 7

1 Overview 9
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 eDirectory Subsystems 11
FLAIM Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Roll-Forward Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
FLAIM Attribute Containerization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Thread Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Analyzing System Bottlenecks 15

Disk I/O Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
CPU Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Memory Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Tuning eDirectory Subsystems 19

FLAIM Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Choosing Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tuning for Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Thread Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Improving eDirectory Searches and Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Disabling ACL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Solid State Disk (SSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
NMAS Login Update Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SSL Overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Import Convert and Export (ICE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ldif2dib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Enhanced NCP Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 eDirectory Configuration 27
Configuring the FLAIM Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Hard Cache Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Dynamically Adjusting the Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Modifying FLAIM Cache Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Modifying FLAIM Cache Settings through iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Modifying FLAIM Cache Settings through _ndsdb.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Contents 3
4
About this Book and the Library

Describe cómo analizar y sintonizar el producto NetIQ eDirectory ( eDirectory ) para obtener un
rendimiento superior rendimiento en todas las implementaciones.

Para la versión más reciente de la Guía de sintonización de directorios electrónicos de NetIQ,

consulte el NetIQ eDirectory online documentation Web site.

Intended Audience
La guía está destinada a administradores de red.

Other Information in the Library

Otra información en la biblioteca

XDASv2 Administration Guide

Describe cómo configurar y usar XDASv2 para auditar eDirectory y NetIQ Identity Manager.

Installation Guide
Describe cómo instalar eDirectory. Está destinado a administradores de red.

Administration Guide
Describes how to manage and configure eDirectory.

Troubleshooting Guide
Describes how to resolve eDirectory issues.

What’s New Guide

Describes the new features of eDirectory.

These guides are available at NetIQ eDirectory documentation Web site.

For information about the eDirectory management utility, see the NetIQ iManager Administration
Guide.

About this Book and the Library 5

6 About this Book and the Library
About NetIQ Corporation

Somos una compañía global de software empresarial, con un enfoque en los tres desafíos persistentes
en su entorno: cambio, complejidad y riesgo — y cómo podemos ayudarlo a controlarlos.

Our Viewpoint
Adaptarse al cambio y gestionar la complejidad y el riesgo no son nada nuevo
De hecho, de todos los desafíos que enfrenta, estas son quizás las variables más prominentes
que le niegan el control que necesita para medir, monitorear y administrar de manera segura
su físico, virtual, y entornos de computación en la nube.

Habilitación de servicios comerciales críticos, mejor y más rápido

Creemos que proporcionar la mayor cantidad de control posible a las organizaciones de TI
es la única forma de permitir la prestación de servicios de manera más oportuna y
rentable. Las presiones persistentes como el cambio y la complejidad solo continuarán
aumentando a medida que las organizaciones continúen cambiando y las tecnologías
necesarias para administrarlas se vuelvan inherentemente más complejas.

Our Philosophy
Venta de soluciones inteligentes, no solo software
Para proporcionar un control confiable, primero nos aseguramos de comprender los escenarios mundiales
reales - en los que operan organizaciones de TI como la suya — día tras día. Esa es la única forma en que
podemos desarrollar soluciones de TI prácticas e inteligentes que produzcan con éxito resultados probados y
medibles. Y eso es mucho más gratificante que simplemente vender software.

Conducir tu éxito es nuestra pasión

Colocamos su éxito en el corazón de cómo hacemos negocios. Desde el inicio del producto
hasta la implementación, entendemos que necesita soluciones de TI que funcionen bien e
integren sin problemas con sus inversiones existentes; necesita soporte continuo y
implementación de la publicación de capacitación -; y necesita a alguien que sea realmente
fácil de trabajar con — para variar. Finalmente, cuando tienes éxito, todos tenemos éxito.

Our Solutions
 Identity & Access Governance
 Access Management
 Security Management
 Systems & Application Management
 Workload Management
 Service Management

About NetIQ Corporation 7

 Contacting Sales Support
For questions about products, pricing, and capabilities, contact your local partner. If you cannot
contact your partner, contact our Sales Support team.

Worldwide: www.netiq.com/about_netiq/officelocations.asp

United States and Canada: 1-888-323-6768

Email: [email protected]

Web Site: www.netiq.com

Contacting Technical Support

For specific product issues, contact our Technical Support team.

Worldwide: www.netiq.com/support/contactinfo.asp

North and South America: 1-713-418-5555

Europe, Middle East, and Africa: +353 (0) 91-782 677

Email: [email protected]

Web Site: www.netiq.com/support

Contacting Documentation Support

Our goal is to provide documentation that meets your needs. If you have suggestions for
improvements, click Add Comment at the bottom of any page in the HTML versions of the
documentation posted at www.netiq.com/documentation. You can also email Documentation-
[email protected]. We value your input and look forward to hearing from you.

Contacting the Online User Community

Qmunity, the NetIQ online community, is a collaborative network connecting you to your peers and
NetIQ experts. By providing more immediate information, useful links to helpful resources, and
access to NetIQ experts, Qmunity helps ensure you are mastering the knowledge you need to realize
the full potential of IT investments upon which you rely. For more information, visit http://
community.netiq.com.

8 About NetIQ Corporation

1 Overview
NetIQ eDirectory 9.2 es una solución de servicios de directorio de rendimiento - compatible con
estándares, multi -, altamente escalable, falla - tolerante y alta -. Esta guía proporciona información
sobre cómo ajustar su entorno de eDirectory para mejorar el rendimiento.

La sintonización para el rendimiento es una actividad compleja. Requiere la comprensión de los

subsistemas del sistema operativo y del directorio electrónico. Implica monitorear el sistema para
identificar cuellos de botella y arreglarlos uno a la vez. Muchas veces los recursos son limitados y la
sintonización se limita a eDirectory y al sistema operativo.

En esta guía, lea la sección Requisitos previos antes de intentar cualquier tipo de ajuste, luego
continúe con las otras secciones. El capítulo Subsistemas de directorio electrónico describe
subsistemas primarios que influyen en el rendimiento del directorio electrónico. El capítulo Análisis
de cuellos de botella del sistema describe varios recursos del sistema y su influencia en el
rendimiento del directorio electrónico. El capítulo Tuning eDirectory Subsystems describe cómo
analizar y ajustar eDirectory en diversas condiciones y entornos. Finalmente, el capítulo
Configuración de eDirectory describe cómo configurar varios parámetros sintonizables.

Prerequisites
Asegúrese de que se cumplan los siguientes requisitos previos generales antes de intentar
ajustar el sistema para el rendimiento:

Un buen diseño de árbol de eDirectory puede mejorar el rendimiento de

eDirectory. Se pueden aplicar las siguientes consideraciones:
Las aplicaciones leen toda la informacion localmente en el servidor sin necesidad de encadenar
las solicitudes.
eDirectory maneja eficientemente las referencias de objetos automáticamente. Si es posible, los
objetos en un servidor no deben referirse a objetos que no son locales en ese servidor, porque
mantener referencias de objetos locales no - puede llevar más tiempo. Si existen tales referencias,
se deben mantener los vínculos de retroceso. Esto se vuelve engorroso en grandes despliegues.

Si necesita un grupo con 10,000 miembros o más, se recomiendan grupos dinámicos. Esto le
permite evitar los gastos generales asociados con el mantenimiento de referencias para tantas
personas. Elija cuidadosamente la configuración dinámica de su grupo, ya que el uso de múltiples
grupos dinámicos con criterios de búsqueda inadecuados podría sobrecargar el servidor y reducir el
rendimiento general del servidor. Si una operación de búsqueda tarda mucho en completarse, el índice
elegido podría ser ineficiente. Minimice el uso de grupos regulares ( estáticos ) ya que esto puede
aumentar la marcha de los árboles al iniciar sesión.
Use ACL de manera eficiente. Por ejemplo, use el administrador [ This ] y asígnelo a nivel de
contenedor en lugar de usar una plantilla ACL que se asigne derechos a sí mismo. Cuantos menos
ACL, mejor será el rendimiento. Para obtener más información sobre ACL, consulte

“eDirectory Rights” in the NetIQ eDirectory Administration Guide.

Distribuya la carga en múltiples servidores de réplica.

Overview 9
 Aunque un buen diseño de árbol minimiza la necesidad de caminar sobre los
árboles, a veces todavía es necesario. Puedes considerar
“Advanced Referral Costing” in the NetIQ eDirectory Administration Guide.
Si los inicios de sesión son lentos, puede deshabilitar las actualizaciones de inicio de sesión. Hay
formas separadas de deshabilitar las actualizaciones de inicio de sesión para los inicios de sesión
NDS y NetIQ Modular Authentication Service ( NMAS ). Sin embargo, es importante entender el
security implications (http://www.novell.com/documentation/nmas33/admin/data/
bg8dphs.html).
Ejecute controles de salud a través de iMonitor. Para más información, ver “Viewing
eDirectory Server
Health” in the NetIQ eDirectory Administration Guide. Asegúrese de lo siguiente:
El tiempo está sincronizado en todos los servidores de réplica.
La sincronización de réplica y los procesos en segundo plano están en un estado saludable.

10 Overview
2 eDirectory Subsystems 2

Esta sección discute los subsistemas de directorio electrónico.

“FLAIM Database” on page 11
“Thread Pool” on page 14

FLAIM Database
eDirectory utiliza FLAIM como su base de datos. FLAIM ( El Administrador de información adaptable
flexible ) se utiliza para información tradicional, volátil y compleja. Es un motor de base de datos muy
escalable que admite múltiples lectores y un solo modelo de concurrencia de escritor -. Los lectores no
bloquean a los escritores y los escritores no bloquean a los lectores.
Físicamente, FLAIM organiza datos en bloques. Algunos de los bloques generalmente se guardan en la
memoria. Representan el caché de bloques. El caché de entrada ( a veces llamado caché de registro )
almacena en caché las entradas lógicas de la base de datos. Las entradas están construidas a partir de los
elementos en el caché de bloques. FLAIM mantiene tablas hash para ambos cachés. El tamaño del
cucharón hash se ajusta periódicamente en función de la cantidad de artículos.
Por defecto, eDirectory utiliza un tamaño de bloque de 4 KB. El tamaño de caché de bloque para almacenar
en caché el DIB completo es igual al tamaño DIB, y el tamaño requerido para el caché de entrada es
aproximadamente dos o cuatro veces el tamaño DIB.
Mientras recupera una entrada, FLAIM primero verifica la entrada en el caché de entrada. Si la entrada
existe, no es necesario leer desde el caché de bloques. Mientras recupera un bloque del disco, FLAIM
primero verifica el bloque en la memoria caché. Si el bloque existe, no es necesaria una operación de lectura
de disco.
Cuando se agrega o modifica una entrada, los bloques correspondientes para esa entrada no se
comprometen directamente con el disco, por lo que el disco y la memoria podrían no estar sincronizados. Sin
embargo, las actualizaciones realizadas en la entrada se registran en el registro de avance - ( RFL ). Se
utiliza un RFL para recuperar transacciones después de una falla del sistema.
El último ( LRU ) utilizado recientemente es el algoritmo de reemplazo utilizado para reemplazar elementos
en la memoria caché.
 “Checkpoint” on page 11
 “Indexes” on page 12
 “Roll-Forward Log” on page 13
 “FLAIM Attribute Containerization” on page 13

Checkpoint
Un punto de control lleva la versión en disco - de la base de datos al mismo estado coherente que la
base de datos en memoria - ( en caché ). FLAIM puede realizar un punto de control durante la
actividad mínima de actualización en la base de datos. Se ejecuta cada segundo y escribe los
bloques sucios ( caché sucio ) en el disco. Los bloques que se modifican en el caché pero aún no
se escriben en el disco se denominan "bloques sucios. FLAIM adquiere un bloqueo en la base de
datos y realiza la cantidad máxima de trabajo posible hasta que se complete el punto de control u
otro subproceso esté esperando para actualizar la base de datos. Para evitar que la base de datos
on - se vuelva demasiado fuera de sincronización, existen condiciones bajo las cuales se obliga un
punto de control incluso si los subprocesos esperan actualizar la base de datos:

eDirectory Subsystems 11
 Si el hilo del punto de control no puede completar un punto de control dentro de un intervalo de
tiempo específico ( el valor predeterminado es 3 minutos ), se fuerza y se limpia el caché sucio.
Si el tamaño del caché sucio es mayor que el caché maxdirty ( si está configurado ), un punto
de control se ve obligado a reducir el tamaño de caché sucio a mindirtycache ( si está
configurado ) o a cero.

Indexes
Las aplicaciones leen toda la información localmente en el servidor sin necesidad de encadenar las
solicitudes. Un índice es un conjunto de claves dispuestas de una manera que acelera
significativamente la tarea de encontrar cualquier cosa en particular clave dentro del índice. Las
claves de índice se construyen extrayendo el contenido de uno o más campos ( atributos ) de las
entradas. Los índices se mantienen en la memoria caché de bloques. Cualquier cambio en los
atributos indexados requiere cambios en los bloques de índice.

eDirectory define un conjunto predeterminado de índices para los atributos del sistema ( campos ).
Los atributos del sistema, como parentID y ancestorID, se utilizan para búsquedas de nivel y
subárboles -. Estos índices no pueden suspenderse ni eliminarse. El directorio los usa
internamente. Los índices predeterminados se definen para atributos como CN, Apellido, Nombre
de pila, etc. Los índices pueden ser de presencia de tipo, valor e índices de subcadena. Estos
índices pueden ser suspendidos. Al eliminar, se recrean automáticamente -.

Puede usar iManager o la utilidad ndsindex Lightweight Directory Access Protocol ( LDAP ) para
crear índices.

Indexes (http://www.novell.com/documentation/edir88/edir88/data/a5tuuu5.html) are server-specific.

Al habilitar la etiqueta Storage Manager ( StrMan ) en DSTrace ( ndstrace ), puede ver el índice
elegido para las consultas de búsqueda.

El siguiente ejemplo es para un registro DSTrace para una búsqueda subárbol usando "cn=admin",
CN.

3019918240 StrMan: Iter #b239c18 query ((Flags&1)==1) &&

((CN$217A$.Flags&8=="admin") && (AncestorID==32821))

3019918240 StrMan: Iter #b239c18 index = CN$IX$220

El siguiente ejemplo es para un registro DSTrace para una búsqueda subárbol usando
"Description= This is for testing", AncestorID.

2902035360 StrMan: Iter #83075b0 query ((Flags&1)==1) &&

((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))

2902035360 StrMan: Iter #83075b0 index = AncestorID_IX

Para mejorar el rendimiento de búsqueda con la ordenación del lado del servidor, use la opción - a
para prefijar el atributo AncestorID en la lista de atributos pasados mientras crea un nuevo índice.
La siguiente tabla explica la tendencia de aumentar el tamaño de DIB al tiempo que crea índices
simples / compuestos para un cierto número de objetos. Le recomendamos que consulte estos datos
de prueba mientras crea índices simples / compuestos:

12 eDirectory Subsystems
Number of Objects Increase in DIB size with Increase in DIB size with Increase in DIB size with
simple index containing simple index containing compound index
attribute size of 20 attribute size of 200 containing attribute size
characters characters of 200 characters

23K 24KB 3MB 7MB

47K 50KB 6MB 15MB

0.5 Million 4MB 55MB 100MB

1 Million 9MB 111MB 210MB

Roll-Forward Log
FLAIM registra las operaciones para cada transacción de actualización en un archivo de registro
directo - ( RFL ). Se utiliza un RFL para recuperar transacciones de una falla del sistema o al
restaurar desde una copia de seguridad. El archivo RFL se trunca después de completar cada
punto de control a menos que esté activado ( rflkeepfiles ) utilizando un hot continuous backup
(http://www.novell.com/documentation/edir88/edir88/data/a2n4mb7.html).

FLAIM Attribute Containerization

Para garantizar la utilización óptima de la memoria caché de entrada y el rendimiento mejorado de
las operaciones de búsqueda de atributos, FLAIM almacena atributos con valores más grandes o
un mayor número de valores en una ubicación separada, a saber, Atribute Container. Por defecto,
los atributos se moverán al contenedor automáticamente cuando el atributo:
tiene más de 25 valores
tiene un valor superior a 2048 bytes
Para deshabilitar la contenedorización automática de atributos, agregue disablemovetoattrcontainer
=1 in the _ndsdb.ini file and restart eDirectory.

eDirectory le brinda la flexibilidad de programar el movimiento de atributos. Primero ve los atributos que
están listos para ser movidos y luego programa su movimiento según su conveniencia.

Para ver el número de atributos listos para el movimiento para atribuir contenedores, ejecute el ndscheck
comando. Para ver los detalles de los atributos, use iMonitor dsContainerReadyAttrs atributo en los
objetos del servidor Pseudo en el Agent Configuration. El usuario también puede encontrar los atributos
que están marcados para indexar en Agent Health.

Puede iniciar la contenedorización de atributos utilizando la opción de reparación de un solo objeto de

ndsrepair para el objeto Pseudo servidor. Para contenedorizar un atributo, emita el ndsrepair comando
con el nuevo interruptor de avance - am seguido del nombre del atributo como se muestra a continuación:

ndsrepair –J <Pseudo server object ID> –Ad –AM/–am <attribute name>

Después de mover un atributo al Contenedor de atributos, eDirectory crea un índice del sistema con el
nombre del atributo. Cuando un atributo está en contenedores, no puede moverlo de regreso al
contenedor original.
NOTE: Si un atributo tiene un valor superior a 2048 bytes, la contenedorización aún ocurre
pero eDirectory no crea ningún índice del sistema.

eDirectory Subsystems 13
 Thread Pool
eDirectory está roscado multi - por razones de rendimiento. En subprocesos multi -, cuando el
sistema está ocupado, se crean más subprocesos para manejar la carga y algunos subprocesos
se terminan para evitar gastos generales adicionales. Es ineficiente y costoso crear y destruir
hilos con frecuencia. En lugar de engendrar nuevos hilos y destruirlos para cada tarea, se inician
y colocan varios hilos en una piscina. El sistema asigna los hilos del grupo de hilos a varias
tareas según sea necesario. Las tareas se llevan a cabo en dos tipos de colas:

Las tareas que necesitan programación inmediata se llevan a cabo en la cola Ready.
Las tareas que necesitan programación en un momento posterior se llevan a cabo en la cola de espera.

No todos los módulos usan el grupo de hilos. El número real de subprocesos para el proceso es mayor que el
número que existe en el grupo de subprocesos. Por ejemplo, FLAIM gestiona sus subprocesos de fondo por
separado.

Corriendo el ndstrace -c threads el comando devuelve las siguientes estadísticas de grupo de hilos:

El número total de hilos engendrados, terminados e inactivos.

El número total de hilos de trabajo actualmente y el número máximo de hilos de trabajo.
El número de tareas y el número máximo de tareas en la cola Ready.
El número mínimo, máximo y promedio de microsegundos gastados en la cola Ready.
El número actual y máximo de tareas en la cola de espera.
Un ejemplo de un grupo de hilos de muestra:

Hay ciertos parámetros de agrupación de subprocesos:

n4u.server.max-threads: Número máximo de hilos que pueden estar disponibles en la piscina.

n4u.server.idle-threads: Número máximo de hilos inactivos que pueden estar disponibles en la piscina.
n4u.server.start-threads: Número de hilos iniciados.
Corre el ndsconfig get and ndsconfig set comandos para obtener y establecer el tamaño del grupo de
hilos.

14 eDirectory Subsystems
3 Analyzing System Bottlenecks
Hay varios recursos del sistema que influyen en el rendimiento del directorio electrónico. Además,
la actualización a la última versión del sistema operativo mejora el rendimiento.

 “Disk I/O Subsystem” on page 15

 “CPU Subsystem” on page 16
 “Memory Subsystem” on page 16
 “Network Subsystem” on page 17

Disk I/O Subsystem

El subsistema de disco es el cuello de botella más común. La E / S lleva un tiempo relativamente
largo con colas más largas, lo que resulta en una alta utilización del disco y ciclos de CPU
inactivos. Use la herramienta iostat durante las cargas máximas esperadas para determinar los
indicadores de tiempo de respuesta promedio.
Las operaciones de lectura, escritura y actualización de discos pueden ser secuenciales o
aleatorias. Lecturas y actualizaciones aleatorias es el patrón de acceso más común en las
implementaciones de eDirectory.
Algunas soluciones para cargas de trabajo aleatorias:

• Aumentar la RAM. Esto permite almacenar en caché datos de uso frecuente o leer - datos
por adelantado en el capa del sistema de archivos. También permite almacenar en caché el
DIB dentro del subsistema FLAIM.
• Utilice volúmenes dedicados para el DIB. El rendimiento del sistema de archivos mejora
para los volúmenes creados más cerca del huso. Use volúmenes dedicados para RFL y
otros registros. de modo que los discos se desarrollan aumentando la latencia durante un
período de tiempo debido a la fragmentación, deberían estar desfragmentado.
• unidades de disco separadas para FLAIM RFL. Este tipo de registro se puede realizar a alta
velocidad - discos.
• Utilice un entorno RAID 10 ( 1 + 0 ) con más unidades de disco
Los archivos creados por eDirectory pueden crecer a 4 GB. Los sistemas de archivos
optimizados para manejar archivos grandes funcionan eficientemente con eDirectory.
Para Solaris ™, el sistema de archivos Veritas * VxFS es un sistema de archivos basado en extensión - donde los
metadatos del sistema de archivos están optimizados para archivos grandes. El sistema de archivos UFS está
indirectamente basado en bloques -, donde los metadatos del sistema de archivos se almacenan en un mayor número
de bloques. Incluso se puede dispersar para archivos grandes, lo que hace que UFS sea más lento para archivos más
grandes.
Para Linux ™, el sistema de archivos Reiser es un sistema de archivos de registro rápido y
funciona mejor que el sistema de archivos ext3 en grandes conjuntos DIB. Sin embargo, se
sabe que el modo de registro de escritura de ext3 coincide con el rendimiento del sistema de
archivos Reiser, aunque el modo ordenado predeterminado proporciona una mejor
consistencia de datos. XFS es un sistema de archivos de registro de alto rendimiento -, capaz
de manejar archivos grandes y ofrecer transferencias de datos sin problemas. eDirectory 9.1
es compatible con las plataformas SLES 11 32 y 64 - bit que tienen un sistema de archivos
XFS.
FLAIM admite un tamaño de bloque de 4 KB y 8 KB. Por defecto, es 4 KB. Esto es lo mismo que el
tamaño de bloque predeterminado en Linux (tune2fs -l device). Sin embargo, en Solaris, el
sistema de archivos UFS se crea con un tamaño de bloque predeterminado de 8 KB (df -g
mountpoint).

Analyzing System Bottlenecks 15

 Si el tamaño del bloque FLAIM es menor que el tamaño del bloque del sistema de archivos, pueden
ocurrir escrituras parciales del bloque. Si el tamaño del bloque de la base de datos es mayor que el
tamaño del bloque del sistema de archivos, las lecturas y escrituras de bloques individuales se
dividen en una serie de operaciones físicas de E / S distintas. Por lo tanto, siempre debe mantener
el tamaño de bloque FLAIM igual que el tamaño de bloque del sistema de archivos.

Los tamaños de bloque solo se pueden controlar durante la creación del DIB. Agregue una línea
"blocksize = 8192" a _ndsdb.ini para crear el DIB con un tamaño de bloque de 8K.

Elegir el tamaño de bloque correcto depende del tamaño promedio del registro FLAIM en sus
implementaciones. Se requieren pruebas empíricas en el conjunto correcto de datos de prueba
para determinar qué tamaño de bloque es mejor para su implementación.

CPU Subsystem
eDirectory is built on a highly scalable architecture. The performance increases with the increase in
the number of processors. Increased throughput is observed until at least the 12th processor under
heavy load. However, this increase is subject to the performance of other resources during the
increasing load on the system. Servers are often under-configured with disks and memory. You
should add more processors only under the following circumstances:

 If the average load on currently used processors is beyond 75% percent utilization. If the current
CPU utilization is below 75%, adding more CPUs might not improve performance.
 If there is a satisfying increase in performance.

If eDirectory is configured with too many threads, considerable amount of CPU time is spent in
context switching. In this case, a decrease in threads can result in better throughput.

Memory Subsystem
Server applications can perform significantly better when RAM is increased. Caching the eDirectory
database in the filesystem or in the FLAIM cache can lead to improved performances of search and
modify operations. However, you cannot cache the complete DIB in large deployments. Avoid page
swapping even if it means reducing the FLAIM entry and 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 IDM have some
modules that run inside eDirectory.

The memory used by eDirectory might appear to be growing. Although memory is freed by an
eDirectory process, it might not be released to the 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 process 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.

16 Analyzing System Bottlenecks

Network Subsystem
Typical deployments have sufficient bandwidth to handle peak network load. Adequate bandwidth
reduces errors, collisions, and dropped packets. Use the netstat tool to determine the network
statistics.

Several operating systems provide TCP/IP tunable parameters for tuning network intensive servers.
For information, refer to the documentation for the operating systems.

If the network is the bottleneck, you should increase the bandwidth. Configuring a dedicated private
network between the application servers and the eDirectory server might also help in reducing the
network congestion.

Analyzing System Bottlenecks 17

18 Analyzing System Bottlenecks
4 Tuning eDirectory Subsystems
4

This section includes the following information:

 “FLAIM Database” on page 19

 “Thread Pool” on page 20
 “ACLs” on page 21
 “Replication” on page 23
 “Solid State Disk (SSD)” on page 24
 “NMAS Login Update Interval” on page 25
 “SSL Overhead” on page 25
 “Import Convert and Export (ICE)” on page 25
 “ldif2dib” on page 25
 “Enhanced NCP Packet Size” on page 25

FLAIM Database
Cache sizing is arguably the most important factor affecting the overall performance of eDirectory.
The greater the number of items (blocks and entries) that can be cached, the better the overall
performance is. The percentage of times that the blocks or entries are found in the cache is called the
hit ratio. A higher ratio results in better performance. iMonitor can be used to view the hit ratio.

The block cache is most useful for update operations. The entry cache is most useful for operations
that performs a base-scoped search for an entry. However, both one-level and sub-tree scoped
searches use the entry cache as well as the block cache. The block cache is used to retrieve indexes.
Create the right type of indexes as necessary, for more information see “Choosing Indexes” on
page 20.

A fault in the block cache can result in a disk read operation. Disk reads are always expensive, but
they can be avoided if a block is retrieved from the filesystem cache.

The amount of memory required to cache the complete database in the block cache is nearly the size
of the database on the disk, and the amount of memory required to cache the complete database in
the entry cache is nearly two to four times the database size on the disk. When you have less
memory on a system, try a smaller entry cache and a much larger block or filesystem cache.

If reads are localized to a set of entries in the directory, you should increase the 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 block cache or a filesystem cache than the entry cache.

Any method you use to tune eDirectory for an improved performance needs empirical testing. A good
ratio of entry to 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 eDirectory cache is never
fragmented by the native operating system memory manager.

Tuning eDirectory Subsystems 19

 Choosing Indexes
Indexes are meant to improve the one-level or sub-tree scoped search performance. Dynamic groups
also use one-level or sub-tree scoped searches. Indexes are not used for base-scoped searches.

Because a Presence index does not differentiate between present and not present (deleted) values, it
is mainly used for internal purpose. If applications run a Presence type search query, this index is
never used, so applications should not have Presence indexes created for them.

Applications can create a Value index for an attribute, which is sufficient for most of the searches.
FLAIM can use a Value index for performing both Presence as well as Substring searches on the
attributes.

A Substring index can significantly decelerate the updates performed on an attribute. The number of
index blocks required to support a Substring index is quite large compared to the Value index. This
means more block cache is required to cache them. Create a Substring index only when necessary. A
Value index should suffice for most searches. However, if Substring searches do not yield acceptable
performance with a Value index, you can create a Substring index on those attributes.

If a search operation takes a long time to complete despite the chosen index, you might introduce a
newer value index on one of the attributes of the search filter. Pick the attribute that yields best results
when indexed.

Tuning for Updates

The block cache is most useful for update operations. Indexes also reside in the block cache.
Although indexes help in faster searches, having too many indexes keeps the server busy
maintaining them. Indexes are modified if attribute values are modified, added, or deleted. During
large upload operations, indexes can be disabled for faster upload.

Having the RFL directory on a different disk than the DIB directory improves performance.

An acceptable limit for response time for an update operation can be controlled by using the
maxdirtycache. For example, if an acceptable limit for the server response is 5 seconds and random
disk write speed is 20 MB per second, then the maxdirtycache should be set as 20x5 = 100 MB.
Ensure that the block cache can hold these dirty blocks in memory. See “Modifying FLAIM Cache
Settings through _ndsdb.ini” on page 29 for more information.

Thread Pool
By default, the maximum number of threads that can be available in the thread pool is 256. This
number should suffice for most deployments. It can be increased to 512 threads in larger
deployments. You should increase the number of threads in the pool in the following cases:

 If the number of idle threads is often zero.

 If the average amount of time spent by a task in the Ready queue is high and increasing.
 If the number of tasks in the Ready queue is high and increasing.

Keep increasing the max threads if the performance of the server increases. It should also result in
increased CPU utilization.

For information about viewing the thread pool statistics, see “Viewing the Thread Pools Statistics” in
the NetIQ eDirectory Administration Guide.

20 Tuning eDirectory Subsystems

ACLs
 “Improving eDirectory Searches and Reads” on page 21
 “Disabling ACL Templates” on page 21

Improving eDirectory Searches and Reads

An LDAP search in eDirectory returns results depending on the number of attributes returned for a
user (inetOrgPerson).

When an object is created in eDirectory, default ACLs might be added on the object. This depends on
ACL templates in the schema definition for the objectClass to which this object belongs. For example,
in the default configuration for inetOrgPerson, there can be up to six ACLs added on the user object.
When an LDAP search request is made to return this user object with all attributes, it takes slightly
longer to return this object to the client than returning this user object without ACL attributes.

Though default ACLs can be turned off, administrators may not want to turn them off because they
are required for better access control. However, you can improve the search performance by not
requesting them or by marking them as read filtered attributes. These changes do not break any
applications because most applications use effective privileges and do not rely on specific ACLs.

Not requesting ACLs: An ACL attribute is not needed by several applications, so the applications
can be modified to request specific attributes in which the application is interested. This results in
better performance of the LDAP search.

Marking an ACL as read filtered: If an application cannot be modified, the arf_acl.ldif can be
used by an administrator to mark the ACL attribute as a read filtered attribute. When the ACL is
marked as a read filtered attribute, the server does not return the attribute on the entry if all attributes
are requested. However, the if the LDAP search is done to return operational attributes or if the
request specifically asks for ACL attributes, the marked attribute is returned. rrf_acl.ldif can be
used to turn off the read filtered flag on an ACL attribute. These LDIFs affect the ACL attribute on the
schema, so only a user with Supervisor rights on tree root can extend them.

By default, an ACL is not marked as read filtered, so the performance benefit for requests to return all
attributes is not seen.

The following table depicts the location of arf_acl.ldif and rrf_acl.ldif files in different
platforms.

Platform Location

Linux  /opt/novell/eDirectory/lib64/nds-schema/
Windows  <unzipped_location>\eDirectory\windows\x64\NDSonNT\ndsnt\
nds

Disabling ACL Templates

You can disable the Access Control List (ACL) templates to increase the bulkload performance. The
implication of this is that some of the ACLs will be missing. However, you can resolve this by adding
the required ACLs to the LDIF file or applying them later.

1 Run the following command:

ldapsearch -D cn_of_admin -w password -b cn=schema -s base objectclasses=inetorgperson

Tuning eDirectory Subsystems 21

 The output of this command would be as follows:

dn: cn=schema

objectClasses: (2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP

organizationalPerson STRUCTURAL MAY (groupMembership $ ndsHomeDirectory
$ loginAllowedTimeMap $ loginDisabled $ loginExpirationTime $
loginGraceLimit $ loginGraceRemaining $ loginIntruderAddress $
loginIntruderAttempts $ loginIntruderResetTime $
loginMaximumSimultaneous $ loginScript $ loginTime $
networkAddressRestriction $ networkAddress $ passwordsUsed $
passwordAllowChange $ passwordExpirationInterval $
passwordExpirationTime $ passwordMinimumLength $ passwordRequired $
passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $
publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
minimumAccountBalance $ messageServer $ Language $ UID $
lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
higherPrivileges $ printerControl $ securityFlags $ profileMembership $
Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
sASSecretStoreData $ sASPKIStoreKeys $ userCertificate
$ nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
rADIUSAttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory
$ rADIUSDefaultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
$ rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
carLicense $ departmentNumber $ employeeNumber $ employeeType $
givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledUri $ mail $ manager $ mobile $ pager $ ldapPhoto $
preferredLanguage $ roomNumber $ secretary $ uid $ userSMIMECertificate
$ x500UniqueIdentifier $ displayName $ userPKCS12) X-NDS_NAME 'User' X
-NDS_NOT_CONTAINER '1' X-NDS_NONREMOVABLE '1' X-NDS_ACL_TEMPLATES
('2#subtree#[Self]#[All Attributes Rights]' '6#entry#[Self]#loginScript'
'1#subtree#[Root Template]#[Entry Rights]' '2#entry#[Public]#messageServer'
'2#entry#[Root Template]#groupMembership' '6#entry#[Self]#printJobConfiguration'
'2#entry#[Root Template]#networkAddress'))

2 In the output noted in the previous step, delete the information marked in bold.
3 Save the revised output as an LDIF file.
4 Add the following information to the newly saved LDIF file:

dn: cn=schema

changetype: modify

delete: objectclasses

objectclasses: (2.16.840.1.113730.3.2.2)

add:objectclasses

Therefore, your LDIF should now be similar to the following:

dn: cn=schema

changetype: modify

delete: objectclasses

objectclasses: (2.16.840.1.113730.3.2.2)

22 Tuning eDirectory Subsystems

 add:objectclasses

objectClasses: (2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP

organizationalPerson STRUCTURAL MAY (groupMembership $ ndsHomeDirectory
$ loginAllowedTimeMap $ loginDisabled $ loginExpirationTime $
loginGraceLimit $ loginGraceRemaining $ loginIntruderAddress $
loginIntruderAttempts $ loginIntruderResetTime $
loginMaximumSimultaneous $ loginScript $ loginTime $
networkAddressRestriction $ networkAddress $ passwordsUsed $
passwordAllowChange $ passwordExpirationInterval $
passwordExpirationTime $ passwordMinimumLength $ passwordRequired
$ passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $
publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
minimumAccountBalance $ messageServer $ Language $ UID $
lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
higherPrivileges $ printerControl $ securityFlags $ profileMembership $
Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
sASSecretStoreData $ sASPKIStoreKeys $ userCertificate $
nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
rADIUSAttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory $
rADIUSDefaultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
$ rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledUri $ mail
$ manager $ mobile $ pager $ ldapPhoto $ preferredLanguage $ roomNumber
$ secretary $ uid $ userSMIMECertificate $ x500UniqueIdentifier $
displayName $ userPKCS12) X-NDS_NAME 'User' X-ND S_NOT_CONTAINER '1' X
-NDS_NONREMOVABLE '1')

5 Enter the following command:

ldapmodify -D cn_of_admin -w password -f LDIF_file_name

Replication
In this release, some background processes have been redesigned to cater to large, dynamic
environments. For more information, see “Managing Background Process” in the NetIQ eDirectory
Administration Guide.

We recommend that you set the Hard Limit to 5ms and enable Asynchronous Outbound
Synchronization. However, if the CPU utilization goes high, increase the sleep duration. Figure 4-1
shows the values set for Background Process Delay Settings.

Tuning eDirectory Subsystems 23

 Figure 4-1 Background Process Settings

In-house lab tests were performed on a setup of 10 servers with the following settings: Hard Limit-
0ms, Asynchronous Outbound Synchronization - enabled, and Async Dispatcher Thread Delay -
0ms. The tests have shown that replication is 7 times faster than with the default settings. During this
test, no other client operations were performed.

NOTE: To reap the best benefits of the performance of your systems with these scalability
enhancements, you must be on eDirectory 9.1 or above on all servers. Even if there are some older
versions in the replica ring, there is improvement in performance.

Solid State Disk (SSD)

This release supports Enterprise SSD for improved IO operations. Table 4-1 on page 24 shows the
improvement in repair performance on SSD in our test setup:

Table 4-1 Repair Performance

DIB Size (GB) HDD (Time in Minutes) SSD (Time in Minutes) % Improvement

11 80 53 33.75

24 277 169 38.98

24 Tuning eDirectory Subsystems

 DIB Size (GB) HDD (Time in Minutes) SSD (Time in Minutes) % Improvement

34 542 296 45.38

75 1383 618 55.31

98 3171 1023 67.73

NMAS Login Update Interval

For more information, see “Using the sasUpdateLoginInfo and sasUpdateLoginTimeInterval Attribute
” in the NetIQ eDirectory Administration Guide.

SSL Overhead
LDAP over SSL adds an additional load on the CPU because of its encryption requirements. A lab
performance study shows greater than a 10% performance hit because of encryption overhead.

Import Convert and Export (ICE)

The NetIQ Import Convert and Export (ICE) utility uses an optimized bulk update protocol called
LBURP to upload data into eDirectory. This protocol is significantly faster than uploading data by
using a simple ldapmodify command. For more information, see Offline Bulkload Utility in the NetIQ
eDirectory Administration Guide.

ldif2dib
For tuning eDirectory performance during offline bulk upload by using the ldif2dib utility, for more
information, see Tuning ldif2dib in the NetIQ eDirectory Administration Guide.

Enhanced NCP Packet Size

To communicate among various servers, eDirectory uses Netware Core Protocol (NCP) as the
communication protocol. In previous releases, the maximum packet size that NCP allowed was 64
KB, which limited the maximum throughput when data was transferred over NCP. This release
improves the ability of NCP to handle packet size up to 1 MB, which enables eDirectory to
synchronize up to 1 MB data in a single packet. eDirectory starts synchronizing with 64 KB packet
size and increases the packet size based on the remaining data to be synchronized. This significantly
improves the replication performance. If your both servers are 9.2, you do not need to perform any
additional configuration to leverage this enhancement.

Tuning eDirectory Subsystems 25

26 Tuning eDirectory Subsystems
5 eDirectory Configuration
5

This section includes the following information:

 “Configuring the FLAIM Subsystem” on page 27

 “Modifying FLAIM Cache Settings” on page 27

Configuring the FLAIM Subsystem

In order to address a wide range of deployments and configurations, two mechanisms for controlling
the cache memory consumption are provided in the eDirectory. These mechanisms are mutually
exclusive.

 “Hard Cache Limit” on page 27

 “Dynamically Adjusting the Limit” on page 27

Hard Cache Limit

You can specify a hard memory limit in one of the following ways:

 As a fixed number of bytes.

 As a percentage of physical memory.
 As a percentage of available physical memory.

When a hard limit is specified by using the second or third method, it is always translated to a fixed
number of bytes. This means that for the second method, the number of bytes is the percentage of
physical memory detected when eDirectory is started. For the third method, the number of bytes is
the percentage of available physical memory detected when eDirectory is started.

Dynamically Adjusting the Limit

A dynamic adjustment causes eDirectory to periodically adjust its memory consumption in response
to the variable memory consumption by other processes. Although adjusting memory dynamically
works well in typical scenarios, this mechanism 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.

Modifying FLAIM Cache Settings

 “Modifying FLAIM Cache Settings through iMonitor” on page 28
 “Modifying FLAIM Cache Settings through _ndsdb.ini” on page 29

eDirectory Configuration 27
 Modifying FLAIM Cache Settings through iMonitor
You can use iMonitor to do the following:

 View or change the cache settings.

 Monitor the cache statistics.

28 eDirectory Configuration
Refer to the Database cache under Agent Configuration of iMonitor for the above information.

Database Cache Description

Information

Maximum Size The maximum size (in KB) that the specified cache is allowed to grow
to.

Current Size The current size (in KB) of the specified cache.

Items Cached The number of items in the specified cache.

Old Versions Cached The number of old versions in the specified cache. Old versions of
cache items are kept to maintain the consistency of read transactions
in the database. In other words, if one thread is in a read transaction
and another is in a write transaction, old versions of blocks modified
by the writer are maintained on behalf of the reader. This is done so
that the reader’s results are guaranteed to produce a consistent view
during the life of its transaction even though modifications are taking
place during that time.

Old Versions Size The size (in KB) of the old version items cached.

Hits The number of times an item was successfully accessed from the
specified cache.

Hit Looks The number of items looked at in the cache before an item was
successfully accessed from the specified cache. The hit-look-to-hit
ratio is a measure of cache lookup efficiency. Normally, the ratio
should be close to 1:1.

Faults The number of times an item was not found in the specified cache
and had to be obtained in a lower level cache or from the disk.

Fault Looks The number of items looked at in the cache before it was determined
that the desired item was not in the specified cache. The fault-look-to-
fault ratio is a measure of cache lookup efficiency. Normally, the ratio
should be close to 1:1.

Modifying FLAIM Cache Settings through _ndsdb.ini

The FLAIM cache settings and other FLAIM configurations can be performed by modifying the
_ndsdb.ini file that resides in the DIB directory. Restart eDirectory when _ndsdb.ini file is
changed.

You can set the dynamically adjusting limit or the hard cache limit. The cache options are listed below.
Multiple options can be specified, in any order, separated by commas. All are optional.

 DYN or HARD - Dynamically adjusting a limit or hard limit.

 % : percentage - Percentage of available or physical memory to use.
 AVAIL or TOTAL - The percentage specifies available memory or total physical memory. It is
applicable only for the hard limit and ignored for the dynamically adjusting limit, because
dynamically adjusting limits are always calculated based on the available physical memory. By
default, it is AVAIL.
 MIN: bytes - Minimum number of bytes.
 MAX: bytes - Maximum number of bytes.
 LEAVE: bytes - Minimum number of bytes to leave.

eDirectory Configuration 29
 For example:

cache=HARD,%:75, MIN:200000000

cache=500000000

 preallocatecache: true/false - This setting causes eDirectory to preallocate the amount of

memory specified by the hard cache limit.
 rfldirectory - A different path can be specified for RFL files.
 cpinterval - Number of seconds after which FLAIM forces a checkpoint. The default is 3
minutes.
 maxdirtycache - Maximum dirty cache bytes.
 lowdirtycache - Minimum dirty cache bytes.
 blockcachepercent - Percentage of the FLAIM cache used for block cache.
 cacheadjustinterval - Interval in seconds for dynamically adjusting the cache.
 cachecleanupinterval - Interval in seconds for cleaning up older versions of entries and blocks
from the cache.

30 eDirectory Configuration