Plantage ITDS sur certaines transactions ITIM

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.

Catégorie: 

Tag: