El subsistema de disco es el cuello de botella más habitual. Las operaciones de E/S tardan un tiempo relativamente largo con las colas más largas, lo cual resulta en un uso elevado del disco y ciclos de CPU inactivos. Utilice la herramienta iostat durante las cargas máximas esperadas para determinar los indicadores de tiempo medio de respuesta.
Las operaciones de lectura, escritura y actualización de disco pueden ser secuenciales o aleatorias. Las actualizaciones y lecturas aleatorias constituyen el patrón de acceso más común en las implantaciones de eDirectory.
Algunas soluciones para cargas de trabajo aleatorias:
Aumentar la memoria RAM. Esto permite el almacenamiento en caché de datos usados con frecuencia o de datos de lectura anticipada en la capa del sistema de archivos. También permite el almacenamiento en caché del archivo DIB dentro del subsistema FLAIM.
Usar volúmenes dedicados para el archivo DIB. Mejora el rendimiento del sistema de archivos en volúmenes creados más cerca del eje. Utilizar volúmenes dedicados para registros RFL y de otro tipo.
A medida que los discos desarrollan una latencia cada vez mayor durante un período de tiempo debido a la fragmentación, deberían desfragmentarse.
Añadir unidades de disco independientes para el RFL de FLAIM. Este tipo de registro puede realizarse en discos de alta velocidad.
Utilizar un entorno RAID 10(1+0) con más unidades de disco.
Los archivos creados por eDirectory pueden aumentar hasta los 4 GB. Los sistemas de archivos optimizados para la gestión de archivos de gran tamaño funcionan de forma eficaz con eDirectory.
En Solaris™, el sistema de archivos Veritas* VxFS es un sistema basado en extensión donde los metadatos del sistema de archivos están optimizados para archivos de gran tamaño. El sistema de archivos UFS se basa en bloques de forma indirecta, y los metadatos del sistema de archivos se almacenan en un número mayor de bloques. Incluso pueden estar dispersos para archivos grandes, lo que hace que UFS sea más lento para los archivos de mayor tamaño.
En Linux™, el sistema de archivos Reiser es un sistema rápido con respaldo de transacciones y que funciona mejor que el sistema de archivos ext3 en conjuntos de archivos DIB grandes. Sin embargo, se sabe que el modo con respaldo de transacciones de ext3 ofrece el mismo rendimiento que el sistema de archivos Reiser, aunque el modo por defecto proporciona una mayor coherencia de datos. XFS es un sistema de archivos con respaldo de transacciones de alto rendimiento capaz de manipular archivos de gran tamaño y ofrecer transferencias de datos sin problemas. eDirectory 8.8 SP8 es compatible con plataformas SLES 11 de 32 y 64 bits que utilicen el sistema de archivos XFS.
FLAIM admite un tamaño de bloque de 4 KB y 8 KB. El valor por defecto es 4 KB. Este tamaño coincide con el del bloque por defecto en Linux (tune2fs -l device). Sin embargo, en Solaris, el sistema de archivos UFS se crea con un tamaño de bloque por defecto de 8 KB (df -g mountpoint). Si el tamaño del bloque FLAIM es menor que el tamaño de bloque del sistema de archivos, pueden darse escrituras de bloque parciales. Si el tamaño del bloque de la base de datos es mayor que el del bloque del sistema de archivos, las lecturas y escrituras de bloques individuales se dividen en una serie de operaciones de E/S físicas distintas. Por lo tanto, siempre debe usar el mismo tamaño para el bloque FLAIM que para el bloque del sistema de archivos.
Los tamaños de bloque solo se pueden controlar durante la creación del archivo DIB. Añada una línea "blocksize=8192" a _ndsdb.ini para crear el archivo DIB con un tamaño de bloque de 8 K.
La elección del tamaño de bloque adecuado depende Del tamaño medio del registro FLAIM en sus implantaciones. Es necesario realizar pruebas empíricas en el conjunto adecuado de datos de prueba para determinar cuál es el mejor tamaño de bloque para su implantación.