A la recheche des causes de Hangs répétitifs

On 27 mar, 13:00, JKB <knatsc...@koenigsberg.fr> wrote:

Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
bra...@gmail.com ?crivait dans fr.comp.os.linux.configuration :



> On 27 mar, 09:34, JKB <knatsc...@koenigsberg.fr> wrote:
>> Le 27-03-2009, ? propos de
>> A la recheche des causes de Hangs répétitifs,
>> bra...@gmail.com ?crivait dans fr.comp.os.linux.configuration :

>> > Bonjour,

>> Bonjour,

>> > J'ai un serveur avec 32 Go de RAM et 4 CPU tournant sous Debian, mai s
>> > qui n'arrête pas de se planter !

>> Quelle architecture ? Quelle version du noyau (certains bouts de
>> code sont _mal_ testés dès qu'on n'est plus sur du PC standard) ? Quel
>> type de serveur ?

>> > Une analyse du Hardware ne révèle rien d'anormal (mémoire ég alement
>> > testé avec memtest86, sans trouver aucune erreur).

>> Combien de temps ?

>> > Je me suis alors orienté vers la piste Software, notamment
>> > l'application que je fais tourner sur cette machine. Voici donc mes
>> > questions :

>> > 1- Est-ce qu'une application, aussi mal programmée et buguée soi t-
>> > elle, peut provoquer un hang d'un serveur ? Et comment cela est
>> > possible, je veux dire sous quelles conditions ?

>> Quelle application ?

>> > 2- Comment fait-on généralement : quel diagnostic et quels outil ou
>> > méthode, pour dire de façon certaine que c'est bien l'applicatif qui
>> > fait planter le serveur et non le hardware?

>> > Merci de votre aide, c'est très urgent...

>> Qu'est-ce que ça veut dire, planter ? Qu'y a-t-il sur la con sole ?
>> Alimentation vérifiée ? Oops ? Panic ?

>> Ma boule de cristal est en panne...

>> JKB

>> --
>> Le cerveau, c'est un véritable scandale écologique. Il représent e 2% de notre
>> masse corporelle, mais disperse à lui seul 25% de l'énergie que no us
>> consommons tous les jours.

> Voici mes réponses à vos questions :
> - C'est une architecture x86 64 bits (AMD opteron 885)
> - Noyau : 2.6.18
> - serveur : SunFire X4600

Ça, c'est plutôt bon.

> - les tests memtest86 : une semaine !
> - l'application est un logiciel propriétaire de traitement de donné es
> - "Planter" veut dire : pas de console, pas de clavier, pas de souris,
> et que la seule solution pour redemarrer c'est un "reset"
> - Il n'y a rien sur toutes les consoles, pas de Oops, pas de message
> de Panic (et rien d'alarmant dans les fichiers logs)
> - L'alimentation est conforme, un audit a été fait. Et le test
> Hardware des FANs ne montre rien d'anormal...

Bon, déjà, remplacer le noyau par un plus récent. Des tas d e choses
ont été corrigées depuis. Un 2.6.28.x fera l'affaire (le 2.6.29 est
foireux...). Que dit le processeur de service ? On peut aussi commencer
à virer l'overcommit, cela ne fera pas de mal (j'ai eu un problème
similaire avec 4Go de mémoire).

Quant à la virtualisation, je ne dis pas ce que j'en pense pour
régler le problème en question (au moins tant que l'on ne sait pas d' où
provient le problème...).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Je viens à l'instant de discuter avec mon boss par rapport à vos
suggestions, notamment en ce qui concerne l'upgrade du Kernel :
- Ca pose problème car nous sommes en Prod trop critique et surtout
que si on upgrade une machine, il faudra le faire pour tout le parc.
Ce qui veut dire qu'un changement de ce genre doit être planifié à
l'avance. Ce qui n'est pas possible en ce moment.
- Tout le parc est identique au niveau hardware avec la même version
du kernel. Nous n'avons jamais rencontré ce problème sur des Linux.
- Il avance aussi, probablement à raison ou à tard, que si l'upgrade
viendrait à faire disparaître le problème de hang, on ne saura jamais
qu'elle en était la cause et par conséquent éviter que cela ne se
reproduise.
- Si le noyau à lui seul était la cause, il devrait produire un Oops,
un panic, un vmcore, etc. Mais là rien, et c'est ça en réalité qui
nous embête...

Par ailleurs,
- le "processeur de service" de service dit que tous les composants
fonctionnent normalement.
- Comment fait-on pour virer l' "overcommit" ? (dans le BIOS ?) Je ne
connais pas.
- Enfin, je voudrais savoir s'il vous est déjà arrivé de voir des
plantage de ce genre dont la cause est purement software? Comment
faites-vous dans ce cas pour analyser/debuguer et avec quels outils ?
Tout tend ici à accuser l'application qui tourne sur ce serveur après
un tas de tests hardware sans résultats (le hardware était le premier
à être accusé)...

Merci

Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
bras39@gmail.com ?crivait dans fr.comp.os.linux.configuration :

Je viens à l'instant de discuter avec mon boss par rapport à vos
suggestions, notamment en ce qui concerne l'upgrade du Kernel :
- Ca pose problème car nous sommes en Prod trop critique et surtout
que si on upgrade une machine, il faudra le faire pour tout le parc.
Ce qui veut dire qu'un changement de ce genre doit être planifié à
l'avance. Ce qui n'est pas possible en ce moment.

Ouaips. Sauf que je commencerais par là pour justement ne pas perdre
du temps ailleurs. J'ai fait une palanquée et demi de bugs reports et de
patches sur les lkml's depuis le 2.6.12 en raison d'une version de la VM
légèrement foireuse.

- Tout le parc est identique au niveau hardware avec la même version
du kernel. Nous n'avons jamais rencontré ce problème sur des Linux.

Il y a un début à tout.

- Il avance aussi, probablement à raison ou à tard, que si l'upgrade
viendrait à faire disparaître le problème de hang, on ne saura jamais
qu'elle en était la cause et par conséquent éviter que cela ne se
reproduise.
- Si le noyau à lui seul était la cause, il devrait produire un Oops,
un panic, un vmcore, etc. Mais là rien, et c'est ça en réalité qui
nous embête...

Non. Le noyau peut planter dans un deadlock (et à mon avis, le
problème est là). Une autre solution est une surchauffe sur la machine
en question en fonction d'une utilisation spécifique (les suns sont
connues pour s'arrêter brutalement en cas de surchauffe).

Par ailleurs,
- le "processeur de service" de service dit que tous les composants
fonctionnent normalement.

Je parle de la console système qui se récupère par le processeur de
service. Voir la commande console. Je ne connais pas la 4600, mais pour
mes 4200 et Txxx, ça fonctionne comme ça.

- Comment fait-on pour virer l' "overcommit" ? (dans le BIOS ?) Je ne
connais pas.

Je parie que cat /proc/sys/vm/overcommit_memory renvoie 0.

echo 2 > /proc/sys/vm/overcommit_memory

- Enfin, je voudrais savoir s'il vous est déjà arrivé de voir des
plantage de ce genre dont la cause est purement software? Comment
faites-vous dans ce cas pour analyser/debuguer et avec quels outils ?
Tout tend ici à accuser l'application qui tourne sur ce serveur après
un tas de tests hardware sans résultats (le hardware était le premier
à être accusé)...

Je regarde ce qui se passe instantanément sur la machine et je
procède par bissection. En gros, j'isole les problèmes.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

bras39@gmail.com a écrit :
à

l'avance. Ce qui n'est pas possible en ce moment.
- Tout le parc est identique au niveau hardware avec la même version

donc tu prends ton programme proprio et tu le fous sur une autre
machine qui ne plante pas et tu attends

si cela suit l'appli tu auras une piste
ce qui n'expliquera pas comment fait ton programme pour planter le
noyau s'il est planté


et il ne te restera plus qu'à refaire tourner ton appli après mise à
jour du noyau sur une machine "bêta"

histoire de vérifier que le problème vient bien de là

juste comme ça en passant tu peux faire un script avec

beep et sleep dans une boucle
histoire de vérifier que ton programme plante bien tout
remy


--
http://remyaumeunier.chez-alice.fr/

remy a écrit :

bras39@gmail.com a écrit :
à

l'avance. Ce qui n'est pas possible en ce moment.
- Tout le parc est identique au niveau hardware avec la même version

donc tu prends ton programme proprio et tu le fous sur une autre
machine qui ne plante pas et tu attends

si cela suit l'appli tu auras une piste
ce qui n'expliquera pas comment fait ton programme pour planter le
noyau s'il est planté


et il ne te restera plus qu'à refaire tourner ton appli après mise à
jour du noyau sur une machine "bêta"

histoire de vérifier que le problème vient bien de là

juste comme ça en passant tu peux faire un script avec

beep et sleep dans une boucle
histoire de vérifier que ton programme plante bien tout
remy

en gros un fichier test avec

#!/bin/bash
var
while [ var > 10 ]
do
beep
sleep 1
beep
done



chmod +x test
./test


--
http://remyaumeunier.chez-alice.fr/

On 27 mar, 15:42, remy <r...@fctpas.fr;> wrote:

remy a écrit :

> bra...@gmail.com a écrit :
> à
>> l'avance. Ce qui n'est pas possible en ce moment.
>> - Tout le parc est identique au niveau hardware avec la même version

> donc tu prends ton programme proprio et tu le fous sur une autre
> machine qui ne plante pas et tu attends

> si cela suit l'appli tu auras une piste
> ce qui n'expliquera pas comment fait ton programme pour planter le
> noyau s'il est planté

> et il ne te restera plus qu'à refaire tourner ton appli après mise à
> jour du noyau sur une machine "bêta"

> histoire de vérifier que le problème vient bien de là

> juste comme ça en passant tu peux faire un script avec

> beep et sleep dans une boucle
> histoire de vérifier que ton programme plante bien tout
> remy

en gros un fichier test avec

#!/bin/bash
var=20
while [ var > 10 ]
do
beep
sleep 1
beep
done

chmod +x test
./test

--http://remyaumeunier.chez-alice.fr/

Merci à vous tous, j'ai appris plein de choses.

JKB,
- lorsque vous dites : "Le soft proprio tourne en userland et ne peut
foutre en l'air le noyau à moins d'une erreur du côté du noyau." Est-
ce que cela voudrait dire que la plantage de la machine peut avoir
lieu si le soft en question tourne en kerneland (donc lancé par
root) ?

- Que signifie exactement le fait de mettre overcommit_memory =2 ?
Sinon, je confirme sa valeur actuelle est bien 0 !

- pour le "deadlock", nous avons également pensé à cela, mais surtout
côté application. Car un deadlock, me semble-t-il, peut être provoqu é
par une appli. mal codée et qui renvoie dans la nature plusieurs
processus qui bouclent mutuellement indéfiniment, et du coup mettre le
serveur à genou. A ce propos, notre application est assez lourde, ça
vaut le cout de le signaler...

- "Je parle de la console système qui se récupère par le processeur d e
service. Voir la commande console. Je ne connais pas la 4600, mais
pour
mes 4200 et Txxx, ça fonctionne comme ça. "

- Le 4600 a (ou presque) les mêmes commandes SP que le 4100 et 4200.
Moi je récupère la console system à partir du SP avec un "start /SP/
console". Mais cela ne m'affiche rien d'anormal lors des hangs !! Je
ne sais pas si c'est bien cela dont vous parlez.

- Pour ce qui est du "surchauffe sur la machine", si le problème
venait de là, normalement les commandes de stress et de diagnostic
lancées à partir du SP auraient montrer quelque chose, non?


Remy,

- Nous avons arrêté l'application pendant une semaine, et durant cette
semaine la machine n'a jamais hanguée. Mais dès qu'on a lancé
l'application la semaine d'après au bout de 4 heures, le serveur était
tombé (parfois ça arrive au bout de 20 min). Logiquement, on peut dire
qu'on a ainsi isolé le problème. Et bien non, car pour certains
(notamment les développeurs de l'appli. ;) ), cela voudrait tout
simplement dire que l'application sollicite des ressources I/O (driver
HBA ou réseau par exemple) ou RAM/CPU qui ne gèrent pas bien au niveau
hardware, ce qui provoque le hangue...

- Pour ce qui est de la "virtualisation", je ne vois pas trop en quoi
elle pourrait m'aider dans cette problématique. En tout cas, j'ai déj à
eu (et j'en ai encore) pas mal de problèmes similaires avec Vmware ESX
3.x : des hangs et des reboots inexpliqués. Et ce qui est mauvais chez
Vmware c'est qu'on ne sait même pas comment faire des choses qu'on
sait faire dans beaucoup de cas sous linux : hangwatch, SysRQ,
Netdump, etc.

- Merci pour le script. Il est à lancer au même moment que l'appli. ou
cela n'a pas d'importance ?

- Lorsque le plantage arrive : F1-8 ne donne rien, les SysRQ non plus.

On Fri, 27 Mar 2009 10:08:27 -0700 (PDT), "bras39@gmail.com"
<bras39@gmail.com>:

Est-
ce que cela voudrait dire que la plantage de la machine peut avoir
lieu si le soft en question tourne en kerneland

C'est quand même très rare, ce genre d'application. En fait, les seuls
exemples que je connais, c'est les drivers, et les applications de
virtualisation (VMware, Vserver, etc.)

Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
bras39@gmail.com ?crivait dans fr.comp.os.linux.configuration :

On 27 mar, 15:42, remy <r...@fctpas.fr;> wrote:

remy a écrit :

> bra...@gmail.com a écrit :
> à
>> l'avance. Ce qui n'est pas possible en ce moment.
>> - Tout le parc est identique au niveau hardware avec la même version

> donc tu prends ton programme proprio et tu le fous sur une autre
> machine qui ne plante pas et tu attends

> si cela suit l'appli tu auras une piste
> ce qui n'expliquera pas comment fait ton programme pour planter le
> noyau s'il est planté

> et il ne te restera plus qu'à refaire tourner ton appli après mise à
> jour du noyau sur une machine "bêta"

> histoire de vérifier que le problème vient bien de là

> juste comme ça en passant tu peux faire un script avec

> beep et sleep dans une boucle
> histoire de vérifier que ton programme plante bien tout
> remy

en gros un fichier test avec

#!/bin/bash
var
while [ var > 10 ]
do
beep
sleep 1
beep
done

chmod +x test
./test

--http://remyaumeunier.chez-alice.fr/

Merci à vous tous, j'ai appris plein de choses.

JKB,
- lorsque vous dites : "Le soft proprio tourne en userland et ne peut
foutre en l'air le noyau à moins d'une erreur du côté du noyau." Est-
ce que cela voudrait dire que la plantage de la machine peut avoir
lieu si le soft en question tourne en kerneland (donc lancé par
root) ?

Il faudrait que le soft en question utilise un module propre qu'il
lie au noyau (kqemu fait ça, les pilotes nvidia...). C'est assez rare.

- Que signifie exactement le fait de mettre overcommit_memory =2 ?
Sinon, je confirme sa valeur actuelle est bien 0 !

Ça fait des prédictions généralement fausses sur le retour des
fonctions d'allocation mémoire (voir doc/vm dans les sources du noyau).
Le mettre à 2 signifique qu'un malloc() renvoie NULL s'il ne reste plus
de mémoire disponible. Avec 0, l'appel renvoie un pointeur non nul en
espérant que lors de son utilisation la mémoire sera effectivement
disponible. C'est légèrement foireux et parfaitement casse-gueule.

- pour le "deadlock", nous avons également pensé à cela, mais surtout
côté application. Car un deadlock, me semble-t-il, peut être provoqué
par une appli. mal codée et qui renvoie dans la nature plusieurs
processus qui bouclent mutuellement indéfiniment, et du coup mettre le
serveur à genou. A ce propos, notre application est assez lourde, ça
vaut le cout de le signaler...

Je n'ai jamais vu une application planter un système (même en
occupant tout le processeur, la mémoire et la table des processus). À un
moment, le bon oom-killer prend le dessus. Au pire, les disques
gratouillent, mais on sait que le noyau n'est pas planté.

- "Je parle de la console système qui se récupère par le processeur de
service. Voir la commande console. Je ne connais pas la 4600, mais
pour
mes 4200 et Txxx, ça fonctionne comme ça. "

- Le 4600 a (ou presque) les mêmes commandes SP que le 4100 et 4200.
Moi je récupère la console system à partir du SP avec un "start /SP/
console". Mais cela ne m'affiche rien d'anormal lors des hangs !! Je
ne sais pas si c'est bien cela dont vous parlez.

Je parle de la console série qui fait partie du processeur de
service. Si le linux est bien configuré, elle permet récupérer les
dernières infos affichées sur la console même en cas de plantage (sauf
deadlock du noyau).

- Pour ce qui est du "surchauffe sur la machine", si le problème
venait de là, normalement les commandes de stress et de diagnostic
lancées à partir du SP auraient montrer quelque chose, non?

Non, pas forcément.

- Nous avons arrêté l'application pendant une semaine, et durant cette
semaine la machine n'a jamais hanguée. Mais dès qu'on a lancé
l'application la semaine d'après au bout de 4 heures, le serveur était
tombé (parfois ça arrive au bout de 20 min). Logiquement, on peut dire
qu'on a ainsi isolé le problème. Et bien non, car pour certains
(notamment les développeurs de l'appli. ;) ), cela voudrait tout
simplement dire que l'application sollicite des ressources I/O (driver
HBA ou réseau par exemple) ou RAM/CPU qui ne gèrent pas bien au niveau
hardware, ce qui provoque le hangue...

C'est un peu facile. Les Sun sont des machines remarquablement
fiables. Je ne suis pas certain de mon coup pour les serveurs AMD, mais
il me semble que la mémoire est ECC, donc les problèmes de mémoire sont
visibles dans les logs.

- Pour ce qui est de la "virtualisation", je ne vois pas trop en quoi
elle pourrait m'aider dans cette problématique. En tout cas, j'ai déjà
eu (et j'en ai encore) pas mal de problèmes similaires avec Vmware ESX
3.x : des hangs et des reboots inexpliqués. Et ce qui est mauvais chez
Vmware c'est qu'on ne sait même pas comment faire des choses qu'on
sait faire dans beaucoup de cas sous linux : hangwatch, SysRQ,
Netdump, etc.

Je ne dirais pas ici tout le mal que je pense de la virtualisation
dans 95% des cas...

- Merci pour le script. Il est à lancer au même moment que l'appli. ou
cela n'a pas d'importance ?

Ce script ne servira à rien s'il passe en swap...

- Lorsque le plantage arrive : F1-8 ne donne rien, les SysRQ non plus.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

>
- Merci pour le script. Il est à lancer au même moment que l'appli. o u
cela n'a pas d'importance ?

aucune importance juste dans 2 terminals differents
1 pour le script et un autre pour le programme proprio

ce script fait juste beep toutes les seconds sleep 1
si qt cela plante il continue à faire beep beep cela voudra dire que
l'ordi n a pas planter

pour la virtualisation oublie cela ne sera pas tres utile
par contre je te crois mais ne suis pas vraiment sur que l'ordi soit
plante

ce petit test nous le dira

a lundi
remy

Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
remy ?crivait dans fr.comp.os.linux.configuration :

- Merci pour le script. Il est à lancer au même moment que l'appli. ou
cela n'a pas d'importance ?

aucune importance juste dans 2 terminals differents
1 pour le script et un autre pour le programme proprio

ce script fait juste beep toutes les seconds sleep 1
si qt cela plante il continue à faire beep beep cela voudra dire que
l'ordi n a pas planter

Ça ne veut strictement rien dire. Si le noyau fait un oops dans un
truc qui ressemble aux IO, ton script ne fera rien et pourtant, tu ne
seras pas dans un deadlock. Tu n'auras donc rien montré.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

bras39@gmail.com wrote:

Je viens à l'instant de discuter avec mon boss par rapport à vos
suggestions, notamment en ce qui concerne l'upgrade du Kernel :
- Ca pose problème car nous sommes en Prod trop critique

Votre boss a une conception curieuse de la production, puisqu'il semble
considérer qu'il vaut mieux qu'une machine plante de manière certaine,
plutôt qu'elle fonctionne éventuellement sans planter.....

et surtout
que si on upgrade une machine, il faudra le faire pour tout le parc.

C'est là une contrainte qui me semble un peu stricte.

Avez-vous informé votre Boss qu'il est parfaitement possible d'installer
plusieurs versions de noyau sur une même machine sans modifier la
distribution à proprement parler : le multiboot ne sert pas qu'à lancer
Windows ou Linux.

- Tout le parc est identique au niveau hardware avec la même version
du kernel. Nous n'avons jamais rencontré ce problème sur des Linux.

Comme cela vous a été proposé, avez-vous essayé la même application sur une
autre machine ?

Essayez aussi de la lancer avec la plus faible priorité possible : vous
pourrez ainsi éventuellement reprendre la main plus facilement si c'est
elle qui plante.

- Il avance aussi, probablement à raison ou à tard, que si l'upgrade
viendrait à faire disparaître le problème de hang, on ne saura jamais
qu'elle en était la cause et par conséquent éviter que cela ne se
reproduise.

Votre description du problème semble effectivement suggérer un plantage du
noyau. Si celui-ci provient d'un défaut de programmation du genre
débordement de capacité d'un tableau, je ne vois pas très bien l'intérêt
qu'il y aurait à le savoir, étant donné qu'il faudra corriger cette erreur
et que cela suppose donc de passer à une version plus récente du noyau.

- Enfin, je voudrais savoir s'il vous est déjà arrivé de voir des
plantage de ce genre dont la cause est purement software? Comment
faites-vous dans ce cas pour analyser/debuguer et avec quels outils ?
Tout tend ici à accuser l'application qui tourne sur ce serveur après
un tas de tests hardware sans résultats (le hardware était le premier
à être accusé)...

Merci

Au niveau applicatif je ne vois qu'un debugger, ce qui suppose que vous ayez
accès à un binaire compilé de manière ad hoc et aux sources.

Au niveau système, il faut dériver les infos de dmesg vers un terminal
périphérique externe qui puisse être consulté indépendamment du système en
cause : une liaison série semble le plus efficace.

strace pourrait peut-être aussi vous permettre d'identifier la dernier appel
système employé par votre application (si le sync se fait bien).

--
Dominique MICOLLET
Adresse email : enlever deux francs