Slapd est le nom de l'implémentation d'un serveur LDAP au sein du projet libre de référence OpenLDAP.

Sur un slapd en version 2.4.44 installé sur un Debian Stretch (9), la fonctionnalité d'indexation, qui, comme sur un système de gestion de bases de données permet d'accélérer les recherches dans la base, a un comportement surprenant. Je vais énoncer ce que je trouve bizarre, je n'ai pas de réponse.

J'ai effectué mes essais sur deux serveurs fraîchement installés et dotés de la même configuration slapd (cela se vérifie avec un ldapsearch -Y external -H ldapi:/// -b cn=config + diff) et dans lesquels j'importe la même base de données (obtenue avec un slapcat) avec un slapadd.

La doc' OpenLDAP énonce que si l'on ajoute / supprime des index dans la configuration, l'indexation se fait en tâche de fond : « If this setting is changed while slapd is running, an internal task will be run to generate the changed index data. All server operations can continue as normal while the indexer does its work. If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool. ». Je nuance :

• L'indexation ne débute pas forcément de manière automatique après la définition d'un nouvel index. On s'en rend compte car slapd occupe 0 % du CPU en permanence et la taille de la base de données (/var/lib/ldap/data.mdb) reste inchangée ;
  
  
• L'indexation peut conduire le serveur à ne plus répondre aux requêtes LDAP, trop occupé qu'il est à indexer les données. Dans mon cas, slapd a lancé 16 threads sur une machine dotée de 4 cœurs CPU, ce qui entraîne une charge de 17 et une absence de réponse à des ldapsearch, même en attendant plus de 20 secondes (la plupart des applications auront abandonnées avant…).

De même, je constate une grande variation dans la consommation de RAM par la fonctionnalité d'exploitation… Entre 29 % de la RAM de la machine consommée par slapd et 65 %, il y a quand même un écart non négligeable.

Si la taille de la base de données dépasse la taille maximale prédéfinie (1 Go), alors l'indexation s'arrête nette (car plus rien ne peut être écrit dans la base de données). Si l'on change la taille de la base de données en direct avec un ldapmodify, l'indexation ne reprend pas son cours (conso CPU nulle, taille de la base de données inchangée). Si l'on la force avec la commande sudo -u openldap slapindex, la taille de la base de données reste inchangée.

La taille de la base de données peut varier du tout au tout entre deux suppressions de la base de données puis re-création avec un slapadd :

• 338 Mo puis 301 Mo sur un producer avec peu d'index définis dans la conf' ;
  
  
• Plus de 8 Go sur un consumer, 1004 Mo sur un autre, les deux ayant un nombre d'index plus conséquent que le producer qui les alimentent ;
  
  
• On peut aussi passer de 1,9 Go à 314 Mo sur un consumer ;
  
  
• L'écart peut aussi se creuser : 4,6 Go contre 1004 Mo sur deux consumers avant l'ajout d'index supplémentaires, 8 Go contre 1004 Mo (taille inchangée, donc) après l'ajout d'index supplémentaires et un slapindex…
  
  
• À chaque fois, j'utilise un serveur vierge, la même configuration slapd et la même méthodologie pour installer slapd et importer les données… Lors de ma dernière tentative, l'écart entre mes deux consumers était d'environ 50 Mo, j'ai trouvé ça acceptable, je n'ai pas cherché plus loin, mais ma configuration actuelle est identique à celle avec laquelle slapd me générait 8 Go d'index sur un consumer et 1004 Mo sur un autre…