Utilisation CPU intense de ITDI - IDILoader.jar

Nous avons récemment rencontre un problème curieux sur notre installation ITIM / ITDI : le processus ITDI IDIloader.jar est en permanence à 100% de CPU sur le serveur, alors même qu'il ne traite aucune donnée.
Les logs ne donnent pas d'informations.

Symptômes

La commande top donne le résultat suivant :

top - 10:57:29 up 115 days,  2:00,  4 users,  load average: 1.03, 1.08, 0.83
Tasks: 200 total,   1 running, 198 sleeping,   0 stopped,   1 zombie
Cpu(s): 76.4%us, 23.6%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3925320k total,  3774292k used,   151028k free,     6860k buffers
Swap:  4194296k total,  2721804k used,  1472492k free,   530284k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
21871 itdi      20   0 1213m 145m 7104 S 99.9  3.8  10:51.67 java                                                                   
    1 root      20   0 19216  688  508 S  0.0  0.0   0:13.72 init     

On identifie le processus fautif :

ps -ef | grep 21871

itdi     21871 21862 88 10:46 ?        00:13:40 /product/itdi/TDI-71/jvm/jre/bin/java -cp /product/itdi/TDI-71/IDILoader.jar -Dlog4j.configuration=file:etc/log4j.properties com.ibm.di.loader.ServerLauncher -s /product/itdi/TDI-71/timsol -c ITIM_RMI.xml -d

Aucun fichier de log ne donne de piste probante. L'utilisation de la commande lsof ne montre qu'un seul fichier en écriture, le fichier ibmdi.log, qui ne donne pas plus d'informations.

Identification du problème

Un collègue / expert unix envoie alors un kill -QUIT sur le processus, ce qui provoque un thread dump sur le process Java, et permet d'analyser les causes du problème.

Il identifie que l'un des threads java est en attente de ressource sur un fichier dans le répertoire /tmp, et qu'il ne possède pas les bons droits :

ls -al /tmp/
total 88
drwxrwxrwt.  8 root     root      4096  7 févr. 10:46 .
dr-xr-xr-x. 25 root     root      4096  3 févr. 20:38 ..
drwxr-xr-x   2 explitdi explitdi  4096  7 févr. 10:45 .com_ibm_tools_attach

En effet, le propriétaire du processus ITDI ne peut pas écrire dans ce répertoire.

Résolution

Les droits sont alors modifiés sur le répertoire en question :

# chmod 775 /tmp/.com_ibm_tools_attach
# chgrp itdi /tmp/.com_ibm_tools_attach
# ls -al /tmp
total 88
drwxrwxrwt.  8 root     root    4096 Feb  7 10:46 .
dr-xr-xr-x. 25 root     root    4096 Feb  3 20:38 ..
drwxrwxr-x   2 explitdi itdi    4096 Feb  7 11:00 .com_ibm_tools_attach

Le résultat est aussitôt visible : le processus ITDI IDILoader.jar disparaît du top des process :

top 

top - 11:00:37 up 115 days,  2:03,  2 users,  load average: 0.74, 0.98, 0.83
Tasks: 193 total,   1 running, 191 sleeping,   0 stopped,   1 zombie
Cpu(s):  4.4%us,  0.9%sy,  0.0%ni, 91.2%id,  3.4%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   3925320k total,  3769352k used,   155968k free,     7484k buffers
Swap:  4194296k total,  2722080k used,  1472216k free,   531384k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
    1 root      20   0 19216  688  508 S  0.0  0.0   0:13.72 init                                                                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd 

Explication de notre problème

Le souci vient de l'utilisation de 2 comptes systèmes pour ITDI : le compte itdi est utilisé pour lancer le processus itdi (via la commande /etc/init.d/ITIMAd start, alors que l'utilisateur explitdi lance des lignes d'assemblage de type IDI Data Feed vers ITIM. Nous avons du tomber dans une configuration où le premier lancement a été fait avec l'utilisateur explitdi, qui s'est octroyé les droits sur le répertoire /tmp/.com_ibm_tools_attach. Lorsque le serveur ITDI a été lancé par la suite, il n'a pas pu accéder à ce répertoire, et le processus est parti en vrille...


Au fait, que contient ce répertoire ? Le fichier de PID du processus, et des fichiers utilisés comme sémaphores. Tout ceci est amené par des considérations de sécurité des Java Attach API

Référence : http://www-01.ibm.com/support/docview.wss?uid=swg21407964

Catégorie: 

Tag: