...
- LMDB monte la base en RAM pour pouvoir l'exploiter ;
- grouper fait des requêtes assez conséquentes (1 pour trouver un groupe puis 1 par membre d'un groupe) qui, si vous avez des groupes comprenant finalement l'ensemble des individus, correspondent finalement à requêter très régulièrement toute la base ;
- les requêtes, notamment sur les membres, sont mises en cache par grouper (via ehcache) en RAM ...
- on peut ajuster cette configuration d'ehcache
- cependant, le script export-modified-groups-to-LDAP fonctionne en lançant une nouvelle instance de gsh (== grouper) à chaque modification de groupe : le cache ehcache de grouper est alors impuissant
- si votre serveur LDAP dispose d'un espace RAM plus petit que la taille de votre base, alors :
- LMDB se verra contraint de flusher une partie de la base pour monter la partie qui qu'il doit lire et qu'il n'avait pas pu monter en RAM faut faute d'espace ; si vous consultez l'ensemble de la base trtès très régulièrement, vous provoquez ce mécanisme de manière cyclique !
- en conséquence, vous pouvez alors constater un usage du disque en lecture (IO READ) très important.
→ en LMDB, et notamment avec grouper qui peut solliciter beaucoup le ldap, il est vivement recommandé de fournir assez de RAM au serveur pour que l'ensemble de la base (ou au moins la base "utile") puisse être monté en RAM :
en disposant d'un volume de RAM supérieur à la taille (effective) du .mdb (dans /var/lib/ldap/ généralement), on s'assure déviter d'éviter de l'IO (lecture) trop important. Privilégier Privilégiez également des disques SSD pour les VMs du LDAP (imports LDIFs et réindexations).
Pour avoir la taille effective: ll -sh *mdb
1,9G -rw------- 1 openldap openldap 6,6G nov. 8 12:06 data.mdb
4,0K -rw------- 1 openldap openldap 8,0K nov. 8 12:08 lock.mdb
...