[Résolu] Munin : décryptage des graphes présentés

Mornagest · Le 18/02/2010, à 13:55

Hello tout le monde

Voilà, nous avons un serveur qui héberge un forum, et il arrive de temps à autre qu'il plante (moins régulièrement ces jours-ci mais par période cela reste anormalement élevé). Notre hébergeur nous a installé Munin pour surveiller les performances et autres du serveur, mais étant donné que je n'ai qu'une connaissance très limitée de la chose, j'ignore ce que je dois chercher !

Est-ce qu'il y a des exemples quelque part afin d'indiquer d'éventuelles anomalies, par exemple ?

Merci d'avance

Dernière modification par Mornagest (Le 19/04/2010, à 13:03)

francoisp31 · Le 18/02/2010, à 19:05

munin ne fait que ce que tu lui demande donc .... si tu demandes rien tu as juste un pov"graph cpu memoire swap et disque je crois par defaut donc la pertinance.... bof

tu n'as rien trouvé dans /var/log/* qui indiquerai un pb ?

Elemmire · Le 18/02/2010, à 19:35

Il faut regarder :
- utilisation de la mémoire
- utilisation du CPU
- LoadAvg
- les accès apache
- le nombre de process

Mornagest · Le 18/02/2010, à 21:29

Oui, j'ai essayé de regarder un peu mais je n'ai pas trouvé de pic à un moment particulier, et pas spécialement quand le serveur plantait (on a eu une panne ce midi par exemple, et les techs ont dû le rebooter eux-mêmes).

Dans /var/log/... rien trouvé de particulier non plus. Les techs aussi ont fouillé, et c'est pour ça qu'ils nous ont installé munin.

Je vais tenter de regarder plus en détails ce soir, j'ai un peu de temps

Merci pour votre coup de main en tout cas !

Elemmire · Le 19/02/2010, à 13:34

et sur la console il n'y a pas de message d'erreur ???
une solution est de mettre un serveur de logs déporté
cela permet d'envoyer les logs via le réseau et ainsi s'affranchir d'un problème d'écriture disque.
Il peut etre intéressant de récupérer la température de la machine via les sondes de la carte mere ou du CPU... on a déjà vu planter des serveurs parce qu'ils avaient trop chaud.

un test mémoire peut également etre envisagé ... c'est courant d'avoir une barette mémoire deffectueuse!

Si le serveur est encore sous garantie, il faut appeler le service client du constructeur qui vous donnera des pistes ou des outils de diagnostique.

Mornagest · Le 19/02/2010, à 14:09

En fait on l'a pas acheté, il est loué... et il est pas accessible pour un memtest, c'est un serveur partagé donc on n'a pas possibilité de tout faire dessus

Elemmire · Le 19/02/2010, à 17:07

dans ce cas ca va etre plus compliqué pour trouver le pb ...
l'une des actions que font faire les support constructeur c'est la mise à jour des firmware et BIOS en tout genre. Cela implique bien évidement l'arrêt du serveur le temps de les mettre à jour.
Ensuite cela peut venir d'un problème de module ou carrément du noyau donc il faut etre sur que la machine est à jour

Mornagest · Le 19/02/2010, à 19:29

Ben, la Debian qui est dessus n'est pas à jour, à vrai dire. C'est une Lenny, mais le problème du partagé c'est qu'on ne peut pas la mettre à jour nous-mêmes, il faut que ce soit l'hébergeur qui nous le fasse...

On est en train de tenter une migration sur un autre serveur (même hébergeur) afin d'atterrir sur une Debian à jour. Peut-être que cela améliorera la situation...

Edit : ah, et je n'ai pas trouvé de pic particulier lorsque le serveur a planté, hier... bizarre. Peut-être un problème matériel, mais s'il ne s'inscrit pas dans les logs, ça va être dur

Edit bis : ah, si, j'ai une pointe sur le graphe MySQL throughput, hier (quand ça a planté) et aux alentours du dernier plantage vers la mi-janvier. Ques acco ? À quoi cette valeur correspond-elle ? Il y a deux valeurs en fait : vert foncé (taux de transfert) et vert clair (pas expliqué)... c'est cette dernière qui est excessive (on saute de 2 M à 4 M).

Dernière modification par Mornagest (Le 19/02/2010, à 19:48)

Yann · Le 21/02/2010, à 17:31

Salut Mornagest, les causes du plantage sont *tres* souvent une memoire pleine. Tu cherches donc le graph memory. Sur ce graph, tu veux verifier qu'il n'y a pas de swap ou tres peu, et s il y en a, qu'elle n'arrive pas a la petite barre au dessus. Tu recherches egalement qu'est ce qu il y a comme gros pic juste avant le plantage, et qui pourrait expliquer cela.

Si tu veux bien mettre ca public (rien a craindre a priori) je veux bien jeter un oeil.

Mornagest · Le 21/02/2010, à 18:11

Salut Yann,

Voilà par exemple les données sur la semaine écoulée. Le plantage a eu lieu jeudi midi, pour info. Comme il y a de nombreux codes, j'ignore lequel importe pour un serveur... d'autant que je ne connais pas ses caractéristiques (swap, RAM,...)

http://www.baldursgateworld.fr/images/m … emaine.png

Merci en tout cas !

Yann · Le 21/02/2010, à 18:33

1GB de ram et 256MB de swap mais.. t as pas les autres graphs? tu peux pas faire "enregistrer page sous" et tout uploader? La t'as un peu de swap mais rien d alarmant. Ce qui serait interessant ca serait le syslog aussi - t as deja regardé?

Mornagest · Le 21/02/2010, à 19:07

http://www.baldursgateworld.fr/images/Munin.html

J'espère que les liens sur la page sont pas risqués...

J'ai pas regardé les syslogs au moment du plantage... c'est pas malin mais j'étais au boulot donc pas trop le temps...

Yann · Le 21/02/2010, à 19:28

Non, mes munin a moi sont publics aussi
C'est bizarre ta machine, apparement t as 8 coeurs et seulement 1GB de ram. Apparement ca fait que du mysql, que a en juger par l utilisation memoire tu ne t'es jamais fatigué a configurer aux petits oignons Il fait un peu de traffic quand même. C'est une VM? Je suis un peu surpris qu'il y ait pas du tout d'i/o.

En tout cas y'a rien dans les logs qui marque pour moi de gros probleme pouvant justifier un crash. Ya bien le truc bleu dans les IRQ qui est suspect, mais j ai encore jamais vu ca.

Je pencherais pour un souci dans leur systeme de virtualisation (si c'en est) - je veux bien savoir quelle est la techno utilisée.

Ya plusieurs solutions:
* C est une VM - il y a soit un bug qui a cause un crash de la vm, ou un truc qui a planté les drivers reseaux, ce qui revient au meme. La prochaine fois qu elle plante il faudrait essayer de se connecter en local via serie ou VNC, en fonction de la technologie.
* C est pas une VM, dans ce cas il devrait y avoir quelquechose dans le syslog ou kern.log . Garde en memoire que ca peut aussi etre un probleme reseau qui a rien a voir, indépendant de ton serveur.

Si c'est pas une VM, et qu'il y a rien dans les logs, et que le reseau etait 100% ok tout le temps (personne d autre d'affecté dans ton rack), alors je sais pas. Mais je parie pour une des options ci dessus

Dernière modification par Yann (Le 21/02/2010, à 19:29)

Mornagest · Le 21/02/2010, à 19:37

Nope, dans la mesure où je suis admin depuis pas très longtemps, où je connais très peu MySQL, et que le forum existe depuis longtemps (même si on a changé d'hébergeur entretemps), donc j'ai pas pris le temps de la mitonner... et aussi j'ai pas les compétences

À ma connaissance ce n'est pas une machine virtuelle... ou alors on me cache des choses !

Je vais attendre le prochain plantage pour examiner le syslog...

En tout cas merci de ton aide ! Je pense qu'on n'a malheureusement pas grand-chose à espérer.

Ils nous ont proposé de mettre à jour la Lenny, en migrant sur une installation propre (ça fera toujours ça de pris ). On attend leur réponse, d'ailleurs.

Je vous tiens au jus

kAzz · Le 21/02/2010, à 20:03

Hello,

A mon avis la config mysql n'est pas étrangère au pb, je verrais bien la valeur de connexion_max dépassée (voir /etc/mysql/my.cnf)... tu peux t'aider d'outils très simple pour le configurer aux petits oignons : tunning-primer.sh et mysqltuner.pl, qui te font un état de la pertinence du paramétrage des différents paramètres de my.cnf. Ca pourra peut-être faire avancer le schmilblick...

Mornagest · Le 21/02/2010, à 20:35

Salut kAzz,

Des précautions particulières à prendre avant d'essayer ces outils, à part sauvegarder le my.cnf ? Est-ce qu'ils modifient d'autres fichiers ?

Merci pour le tuyau !

Edit : pour info :

#max_connections = 100

donc pas de plafond...

Dernière modification par Mornagest (Le 21/02/2010, à 20:40)

kAzz · Le 21/02/2010, à 21:18

Pas de plafond !! o_O fort surprenant, je ne pense pas que ce soit une bonne chose... ça serait d'ailleurs intéressant de connaitre le nombre max de connexions détecté par tuning-primer.sh.

Sinon les outils ne modifient rien du tout, ils affichent seulement un rapport, c'est à toi ensuite de modifier my.cnf en conséquence.

Dernière modification par kAzz (Le 21/02/2010, à 21:27)

Yann · Le 21/02/2010, à 21:26

Rien ne dit qu'il n y a pas de plafond par defaut
En tout cas d apres les graphs rien ne montre qu il y a eu un manque de ram comme je le pensais.

Mornagest: les graphs du serveur apache pourraient aider aussi, mais je suis pas sur que ca explique la cause du downtime.

Mornagest · Le 21/02/2010, à 21:43

Yann a écrit :

Mornagest: les graphs du serveur apache pourraient aider aussi, mais je suis pas sur que ca explique la cause du downtime.

Je peux les trouver où ? (et pas de réponse facile )

Mornagest · Le 21/02/2010, à 22:02

Arf... j'arrive pas à avoir le rapport correctement... je lance le script

sh tuning-primer.sh | tee test

mais il manque une bonne partie des informations... comment je peux faire ?

Désolé pour la question con, j'ai pas l'habitude des scripts... ni des commandes de ce type (tee)

kAzz · Le 21/02/2010, à 22:06

Tee ne sert qu'à écrire le résultat du script dans le fichier test en plus qu'à l'écran. Ca te sort quoi exactement ?

Mornagest · Le 21/02/2010, à 22:33

Trop long sinon, mon terminal ne remonte pas assez haut, en fait...

kAzz · Le 21/02/2010, à 22:36

Tu peux taper sh tuning-primer.sh mem pour restreindre aux valeurs concernant la ram.

Mornagest · Le 21/02/2010, à 22:51

Quand je rajoute l'option mem il m'indique que la commande bc n'est pas installée comprends pas trop...

Yann · Le 21/02/2010, à 22:56

ton terminal remonte pas assez haut? | more ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/02/2010, à 13:55

[Résolu] Munin : décryptage des graphes présentés

#2 Le 18/02/2010, à 19:05

Re : [Résolu] Munin : décryptage des graphes présentés

#3 Le 18/02/2010, à 19:35

Re : [Résolu] Munin : décryptage des graphes présentés

#4 Le 18/02/2010, à 21:29

Re : [Résolu] Munin : décryptage des graphes présentés

#5 Le 19/02/2010, à 13:34

Re : [Résolu] Munin : décryptage des graphes présentés

#6 Le 19/02/2010, à 14:09

Re : [Résolu] Munin : décryptage des graphes présentés

#7 Le 19/02/2010, à 17:07

Re : [Résolu] Munin : décryptage des graphes présentés

#8 Le 19/02/2010, à 19:29

Re : [Résolu] Munin : décryptage des graphes présentés

#9 Le 21/02/2010, à 17:31

Re : [Résolu] Munin : décryptage des graphes présentés

#10 Le 21/02/2010, à 18:11

Re : [Résolu] Munin : décryptage des graphes présentés

#11 Le 21/02/2010, à 18:33

Re : [Résolu] Munin : décryptage des graphes présentés

#12 Le 21/02/2010, à 19:07

Re : [Résolu] Munin : décryptage des graphes présentés

#13 Le 21/02/2010, à 19:28

Re : [Résolu] Munin : décryptage des graphes présentés

#14 Le 21/02/2010, à 19:37

Re : [Résolu] Munin : décryptage des graphes présentés

#15 Le 21/02/2010, à 20:03

Re : [Résolu] Munin : décryptage des graphes présentés

#16 Le 21/02/2010, à 20:35

Re : [Résolu] Munin : décryptage des graphes présentés

#17 Le 21/02/2010, à 21:18

Re : [Résolu] Munin : décryptage des graphes présentés

#18 Le 21/02/2010, à 21:26

Re : [Résolu] Munin : décryptage des graphes présentés

#19 Le 21/02/2010, à 21:43

Re : [Résolu] Munin : décryptage des graphes présentés

#20 Le 21/02/2010, à 22:02

Re : [Résolu] Munin : décryptage des graphes présentés

#21 Le 21/02/2010, à 22:06

Re : [Résolu] Munin : décryptage des graphes présentés

#22 Le 21/02/2010, à 22:33

Re : [Résolu] Munin : décryptage des graphes présentés

#23 Le 21/02/2010, à 22:36

Re : [Résolu] Munin : décryptage des graphes présentés

#24 Le 21/02/2010, à 22:51

Re : [Résolu] Munin : décryptage des graphes présentés

#25 Le 21/02/2010, à 22:56

Re : [Résolu] Munin : décryptage des graphes présentés

Pied de page des forums