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

Le
bras39
Bonjour,

J'ai un serveur avec 32 Go de RAM et 4 CPU tournant sous Debian, mais
qui n'arrête pas de se planter !
Une analyse du Hardware ne révèle rien d'anormal (mémoire également
testé avec memtest86, sans trouver aucune erreur).
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 soit-
elle, peut provoquer un hang d'un serveur ? Et comment cela est
possible, je veux dire sous quelles conditions ?

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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #18991921
Le 27-03-2009, ? propos de
A la recheche des causes de Hangs répétitifs,
?crivait dans fr.comp.os.linux.configuration :
Bonjour,



Bonjour,

J'ai un serveur avec 32 Go de RAM et 4 CPU tournant sous Debian, mais
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 également
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 soit-
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 console ?
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ésente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
remy
Le #18992881
a écrit :
Bonjour,



bonjour

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


en un seul mot virtualisation et quelque clik

http://www.virtualbox.org/

remy
--
http://remyaumeunier.chez-alice.fr/
bras39
Le #18993111
On 27 mar, 09:34, JKB
Le 27-03-2009, ? propos de
A la recheche des causes de Hangs répétitifs,
?crivait dans fr.comp.os.linux.configuration :

> Bonjour,

Bonjour,

> J'ai un serveur avec 32 Go de RAM et 4 CPU tournant sous Debian, mais
> 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) ? Que l
type de serveur ?

> Une analyse du Hardware ne révèle rien d'anormal (mémoire égale ment
> 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 soit-
> 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 qu i
> 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 consol e ?
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ésente 2 % de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
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
- 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...
JKB
Le #18993541
Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
?crivait dans fr.comp.os.linux.configuration :
On 27 mar, 09:34, JKB
Le 27-03-2009, ? propos de
A la recheche des causes de Hangs répétitifs,
?crivait dans fr.comp.os.linux.configuration :

> Bonjour,

Bonjour,

> J'ai un serveur avec 32 Go de RAM et 4 CPU tournant sous Debian, mais
> 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 également
> 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 soit-
> 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 console ?
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ésente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
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 de 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.
Dominique MICOLLET
Le #18993851
wrote:

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


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



Dans mon inittab j'ai les lignes
#6:23:respawn:/sbin/getty 38400 tty6
6:23:respawn:/usr/bin/top </dev/tty6 >/dev/tty6

top tourne en permanence dans la sixième console virtuelle : si un
processus devient envahissant, je peut savoir lequel, et éventuellement le
tuer.

--
Dominique MICOLLET
Adresse email : enlever deux francs
remy
Le #18994071
JKB a écrit :



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...).




il y a une grande chance que cela vienne du soft proprio
si cela ne venait pas du soft il aurait le même type de problème avec
un autre programme gourmand en ressource mémoire par exemple

la virtualisation lui aurait permis de faire avancer le problème sans
la touche reset


maintenant je ne vois pas trop comment un soft "normal"
peut foutre en l'air un noyau puisque je suppose qu'il n'a plus de
console
crtl +alt +fn
et que le petit mémo utile ne donne rien
mémo des touches magiques


Alt + SysReq + R (Raw) : (pas de translation).
Alt + SysReq + S (Sync) : vide les buffers (ou cache disque).
Alt + SysReq + U (Unmount) : démonte les partitions et les remonte en
lecture seule.
Alt + SysReq + E (tErm) : envoie le signal SIGTERM aux applications
pour un arrêt "propre".
Alt + SysReq + I (kIll) : envoie le signal SIGKILL aux applications
pour un arrêt forcé.
Alt + SysReq + B (reBoot) : redémarre le système.

ne pas confondre S et s

dit différemment
même si le voyant du clavier ne s'allume pas

ALT+PrintScr+SUIB

remy


--
http://remyaumeunier.chez-alice.fr/
JKB
Le #18994061
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 :
JKB a écrit :



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...).




il y a une grande chance que cela vienne du soft proprio
si cela ne venait pas du soft il aurait le même type de problème avec
un autre programme gourmand en ressource mémoire par exemple



Le soft proprio tourne en userland et ne peut foutre en l'air le
noyau à moins d'une erreur du côté du noyau.

la virtualisation lui aurait permis de faire avancer le problème sans
la touche reset



J'aimerais bien savoir comment _de façon simple_.

maintenant je ne vois pas trop comment un soft "normal"
peut foutre en l'air un noyau puisque je suppose qu'il n'a plus de
console
crtl +alt +fn
et que le petit mémo utile ne donne rien
mémo des touches magiques



Ma main à couper que le soft proprio n'y est pour rien. Voir du côté
de l'overcommit foireux. Après, on pourra discuter.

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.
remy
Le #18994331
JKB a écrit :
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 :
JKB a écrit :


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...).



il y a une grande chance que cela vienne du soft proprio
si cela ne venait pas du soft il aurait le même type de problème avec
un autre programme gourmand en ressource mémoire par exemple



Le soft proprio tourne en userland et ne peut foutre en l'air le
noyau à moins d'une erreur du côté du noyau.




là on est bien d'accord

la virtualisation lui aurait permis de faire avancer le problème sans
la touche reset



J'aimerais bien savoir comment _de façon simple_.

maintenant je ne vois pas trop comment un soft "normal"
peut foutre en l'air un noyau puisque je suppose qu'il n'a plus de
console
crtl +alt +fn
et que le petit mémo utile ne donne rien
mémo des touches magiques



Ma main à couper



espèce de mancho, sans ta main tu ne nageras pas plus vite


que le soft proprio n'y est pour rien. Voir du côté
de l'overcommit foireux. Après, on pourra discuter.





qu'il lance 3 open office dans 3 terminaux différents
et après on en reparle







--
http://remyaumeunier.chez-alice.fr/
JKB
Le #18994401
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 :
JKB a écrit :
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 :
JKB a écrit :


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...).



il y a une grande chance que cela vienne du soft proprio
si cela ne venait pas du soft il aurait le même type de problème avec
un autre programme gourmand en ressource mémoire par exemple



Le soft proprio tourne en userland et ne peut foutre en l'air le
noyau à moins d'une erreur du côté du noyau.




là on est bien d'accord

la virtualisation lui aurait permis de faire avancer le problème sans
la touche reset



J'aimerais bien savoir comment _de façon simple_.

maintenant je ne vois pas trop comment un soft "normal"
peut foutre en l'air un noyau puisque je suppose qu'il n'a plus de
console
crtl +alt +fn
et que le petit mémo utile ne donne rien
mémo des touches magiques



Ma main à couper



espèce de mancho, sans ta main tu ne nageras pas plus vite


que le soft proprio n'y est pour rien. Voir du côté
de l'overcommit foireux. Après, on pourra discuter.





qu'il lance 3 open office dans 3 terminaux différents
et après on en reparle



J'ai couru après un bug pareil et ce n'est pas comme ça que tu vas
le trouver. C'est en faisant des allocations/libérations en pagaille et
à grande vitesse.

--
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
Le #18994521
On 27 mar, 13:00, JKB
Le 27-03-2009, ? propos de
Re: A la recheche des causes de Hangs répétitifs,
?crivait dans fr.comp.os.linux.configuration :



> On 27 mar, 09:34, JKB >> Le 27-03-2009, ? propos de
>> A la recheche des causes de Hangs répétitifs,
>> ?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
Publicité
Poster une réponse
Anonyme