Existen varios tutoriales en la Web donde se describe, como optimizar de la mejor manera posible, la Base de Datos de LDAP; dependiendo del uso que se le dará. El que describiré aquí, de manera práctica y breve, tiene como objetivo:

  • Optimizar la Base de datos de LDAP para mantener al mínimo las lecturas en el disco duro (I/O).
  • El tiempo de búsqueda debe de estar al mínimo.
  • Se puede usar toda la RAM que dispone el equipo.

Optimización en Sistema de Archivos Link to heading

Para poder reducir las lecturas de disco duro al mínimo, y que la escritura al disco duro sea rápido; a parte de tener un buen Hardware para esto; se puede optar por un Sistema de Archivos donde la reescritura de bloques de archivos sea veloz. Se pueden optar como Sistema de Archivos que albergue la Base de Datos los siguientes:

ReiserFS

Es un Sistema de Archivos que empieza a ser obsoleto, y pronto el kernel de Linux dejará de soportarlo. Usa una estructura BTree para los datos. Útil para millones de archivos pequeños en un directorio.

XFS

El Sistema de Archivos es muy veloz, y los Meta-datos los mantiene en memoria, lo que hace que la búsqueda de datos a reescribir sea casi instantánea. El problema es que es lento con archivos pequeños.

BtrFS

Es el nuevo Sistema de Archivos que todo mundo habla. Tiene buen desempeño ante archivos de diferentes tamaños.

Por gusto personal, usaría BtrFS para almacenar la Base de Datos. Por ejemplo, crear una partición que se monte en /var/cache/slapd. Y definir en el archivo DB_CONFIG un directorio para los datos, y en otro directorio, con el Sistema de Archivos que gusten, almacenar las bitácoras.

set_data_dir /var/cache/slapd
set_lg_dir /var/log/ldap-logs

Optimización en Berkeley DB Link to heading

La optimización de Cache en Berkeley DB tiene su truco; pero enfocándonos a los objetivos mencionados anteriormente, tiende a ser un poco más fácil la explicación. Se puede definir como Cache, el tamaño total de los archivos .bdb en el directorio; hacer esto optimiza el tiempo de prendido y apagado del servicio de LDAP; pero la búsqueda de datos será de un desempeño medio y se generará mucha basura en la Cache. Aquí es donde interviene la formula que voy a explicar.

En este momento, deberíamos de tener todos los archivos .bdb que tienen la Base de Datos completa en su directorio; y sacaremos de éstos los siguientes datos:

  1. Tamaño de las páginas (Underlying database page size)
  2. Número de páginas internas (Number of tree internal pages)
  3. Número de hojas (Number of tree leaf pages)

Éstos datos se obtienen con el comando db_stat -d archivo.bdb. Una vez obtenidos los datos de todos los archivos .bdb; calculamos lo que sigue:

( N_pag_internas[1] + 10% de N_hojas[1] ) * Tamano_pags[1] +
( N_pag_internas[2] + 10% de N_hojas[2] ) * Tamano_pags[2] +
( N_pag_internas[N] + 10% de N_hojas[N] ) * Tamano_pags[N] +
...

Obtendremos un resultado, en bytes, de la Cache que se usará en Berkeley DB.

Ahora bien, necesitamos saber cuantas entradas en total hay en la Base de Datos; definiendo que se usará 1GB de Cache por cada 100 000 entradas, y que los bloqueos serán la mitad del total de entradas en la Base de Datos. Por ejemplo, si nuestra Base de Datos tiene 132978 entradas, la configuración en DB_CONFIG quedaría como sigue:

set_cachesize 2 5378048 0
set_lk_max_objects 66489
set_lk_max_locks 66489

Optimización en Configuración de LDAP Link to heading

La configuración se guarda en el archivo slapd.conf. Para optimizar las búsquedas, es conveniente tener indexados los atributos principales de referencia dentro de la Base de Datos.

La siguiente parte de la optimización; serán los parámetros cachesize, idlcachesize, dncachesize y threads. La formula para definirlos es más simple, ya que es el total de entradas más el 10%, y que habrán 4 threads por CPU. Entonces, si tenemos una Base de Datos con 132978 entradas y 4 CPUs; quedaría como sigue:

cachesize 146275
idlcachesize 146275
dncachesize 146275
threads 16

Conclusión Link to heading

Una vez que su servicio de LDAP tiene la Base de Datos cargada y funcionando, se puede apreciar la cobertura de Cache con el comando db_stat -m; y si consiguen resultados como éste:

3691610     Requested pages found in the cache (99%)

Significa que nuestro servicio está cumpliendo el objetivo que esperamos, también se puede consultar con iostat si hay lectura en el disco y con time ldapsearch... para ver el tiempo de consulta de datos.

Éstas explicaciones son en base a experiencia personal; si quieren seguir probando otros trucos de optimización, pueden consultar en: