Gros problème ces temps-ci, alors qu'on voulait démarrer en production : lors de certaines opérations dans ITIM, l'annuaire ITDS crash sans message dans ses logs. J'avais déjà remarqué des soucis relativement similaires sur notre plate-forme de développement, que j'avais mis sur le compte de mises à jour nombreuses et pas forcément très carrées...
Lorsque l'annuaire s'arrête, on n'a aucun message dans son fichier ibmslapd.log. Par contre, on constate dans le fichier /var/log/messages :
Mar 27 13:59:59 lnxfr99720434 kernel: ibmslapd[1999]: segfault at 0000000000000040 rip 00002b568d7e08ec rsp 00000000434342c0 error 4
Ceci n'arrive que pour certains recherches. Par exemple la recherche d'utilisateurs sur leur code XX* donne bien la liste des utilisateurs donc le matricule commence par XX. La même recherche sur * fait crasher l'annuaire.
L'audit a été mis en place sur ITDS, mais aucune erreur n'est remontée. On voit passer la requête incriminée, sans autre détail.
Diagnostic du problème
Après quelques recherche sur le web, je suis tombé sur un article qui m'a mis sur la piste. Référence : http://www-01.ibm.com/support/docview.wss?uid=swg21499819
Il donne notamment des pistes pour diagnostiquer le problème.
Lancement de ITDS en mode console
On lance ITDS en mode console, ce qui permettra peut-être d'avoir plus d'informations lors du crash :
/opt/ibm/ldap/V6.2/sbin/ibmslapd -I idsldap -c ... GLPSRV048I Started 15 worker threads to handle client requests. /opt/ibm/ldap/V6.2/sbin/ibmslapd[1101]: eval: line 1: 22892: Memory fault
Effectivement, lorsque ITDS s'arrête brutalement on a une indication supplémentaire : il s'agit d'un problème mémoire.
Vérification de la mémoire et de l'environnement
cat /proc/meminfo MemTotal: 24659144 kB MemFree: 8321348 kB
Il reste 8 Go de RAM libre. Donc pas de souci côté O.S.
$ idsilist -a Directory server instances: -------------------------------------- Instance 1: Name: idsldap Version: 6.2 Location: /product/ldap Description: IBM Tivoli Directory Server Instance V6.2 IP Addresses: All available Port: 389 Secure Port: 636 Admin Server Port: 3538 Admin Server Secure Port: 3539 Type: Directory Server
Une seule instance LDAP, en version 6.2.
Génération d'un core Dump
Nous allons tenter de générer un core dump, pour analyser le problème. Les variables d'environnement sont positionnées pour générer le fichier de dump, et on effectue la transaction ITIM qui pose problème :
ulimit -c unlimited ulimit -Sc unlimited /opt/ibm/ldap/V6.2/sbin/ibmslapd -I idsldap -c .../... GLPCOM003I Non-SSL port initialized to 389. GLPRPL137I Restricted Access to the replication topology is set to false. GLPSRV098I Directory server audit logging started. GLPSRV009I 6.2.0.3 server started. GLPRPL136I Replication conflict resolution mode is set to true. GLPSRV048I Started 15 worker threads to handle client requests. /opt/ibm/ldap/V6.2/sbin/ibmslapd[1101]: eval: line 1: 25475: Memory fault(coredump) Core dump generated : /product/ldap/idsslapd-idsldap/workdir/core.1856
Le problème a bien généré un fichier, que l'on va pouvoir analyser.
Analyse du core dump
L'analyse nécessite l'installation de gdb. Sur notre plate-forme CentOS / RedHat, ceci se fait par un
# yum install gdb
L'analyse du fichier dump se fait via la commande :
# cd /product/ldap/idsslapd-idsldap/workdir # gdb /opt/ibm/ldap/V6.2/sbin/64/ibmslapd core.1856 Core was generated by `/opt/ibm/ldap/V6.2/sbin/64/ibmslapd -I idsldap -c'. Program terminated with signal 11, Segmentation fault. #0 0x00002b568d7e08ec in attr_cache_complete_complex_filter_resolution(vec_base**, vec_base**, int, filter*) () from /opt/ibm/ldap/V6.2/lib64/libback-rdbm.so
Le problème est donc lié à la librairie du back-end DB2, dans une fonction qui semble liée à un cache d'attributs...
Détermination de la cause
Les problèmes sont survenus suite à une séance d'optimisation des performances. En suivant les indications du document de tuning IBM, certains paramètres ITDS ont été modifiés.
Dans le fichier de configuration de l'instance LDAP ibmslapd.conf, le cache d'attribut était positionné en Auto Adjust, suite aux optimisations réalisées sur la plate-forme, via les scripts ITIM :
ibm-slapdCachedAttributeAutoAdjust: TRUE ibm-slapdCachedAttributeSize: 262144
En modifiant l'auto-ajustement à FALSE, on résout le problème :
ibm-slapdCachedAttributeAutoAdjust: FALSE ibm-slapdCachedAttributeSize: 262144
Ce paramétrage était issu du document : IBM - Performance Tuning and Capacity Planning Guide - Tivoli Directory Server - Version 6.3, page 17. Je cite :
For automatic attribute caching for the directory database:
dn: cn=Directory, cn=RDBM Backends, cn=IBM Directory, cn=Schemas, cn=Configuration changetype: modify replace: ibm-SlapdCachedAttributeSize ibm-SlapdCachedAttributeSize: 262144 - replace: ibm-slapdCachedAttributeAutoAdjust ibm-slapdCachedAttributeAutoAdjust: TRUE
Conclusion
L'optimisation des performances est à manier avec précaution... Et même en suivant les recommandations de l'éditeur, il convient de tester par la suite et de noter les changements réalisés.
Ceci est d'autant plus bizarre que les requêtes, passées via un ldapbrowser, se passaient correctement, et que d'autres opérations dans la console ITIM ne renvoyaient pas d'erreur.