Forum Linux.debian/ubuntu enquête post-mortem sur un serveur

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
3
23
mar.
2010
Bonjour,

J'ai un problème récurrent sur un de mes serveurs. De temps en temps, il monte terriblement en charge (très très rapidement) et semble surtout saturer au niveau des I/O du disque dur.

Cela fait planter le kernel, ce qui n'est pas gloups.

Le problème, c'est que je ne trouve rien de parlant dans les logs et que je n'ai aucune idée de ce qui provoque ce problème.


Comment faites-vous pour savoir, après un crash, ce qui a été la cause du problème lorsqu'il s'agit d'un écroulement sous la charge ? (parce que, finalement, à part le syslog…)

Comment monitorer cela au mieux et empécher ce genre d'accidents ?


J'utilise déjà monit sur mes process importants mais j'ai de gros doutes quand à son efficacité (la plupart du temps, je constate que monit ne surveille plus rien et je dois en permanence relancer monit pour qu'il retrouve que, ô miracle, les process qu'il est sensé surveiller sont bel et bien présents).


Merci d'avance,

  • # ulimit

    Posté par  . Évalué à 2.

    Par exemple bien paramétrer "ulimit" permettra d'éviter le crash du serveur !,
    mais c'est l'application qui partira à la poubelle ...

  • # Alim...

    Posté par  . Évalué à 2.

    Il monte en charge ou il freeze en attente disque? Si tu a un problème au niveau des disques système, ça devient vite problématique si le serveur tente de lire dessus, et fatalement ca finira par planter/freezer, et il sera difficile de consulter les logs étant donné que sans disque dur... pas de log.
    La cause des faiblesses "aléatoires" d'un disque dur est souvent une alimentation qui n'a plus toute sa forme. C'est pernicieux et ça frappe sans prévenir, les alims. Tiens d'ailleurs j'en ai vu une faire des étincelles et fumer, aujourd'hui.

    • [^] # Re: Alim...

      Posté par  . Évalué à 1.

      sinon les logs on peut les exporter vers une autre machine (syslog) et ça permet de les avoir même avec des io disque problèmatiques.

      Sinon je conseillerai de vérifier le disque dur, si c'est un serveur tu dois avoir des logs sur le disque lui même (SMART), voire dans le bios ...

  • # Paquets sysstat & acct

    Posté par  (site web personnel) . Évalué à 3.

    sysstat (commande sar) enregistre les stats systèmes toutes le 10min (charge, i/o waits, utilisation mémoire) ce qui te permet de voir ce qui sature et l'heure assez précise du début du pb (peut aider à identifier une tâche cron qui fout la merde, etc ...)

    acct (commandes ac et sa) enregistre aussi ce type de stats mais pas utilisateurs/process ce qui peut permettre d'identifier le process à l'origine du pb ...

    Par contre c'est assez pénible à éplucher ce genre de stats, mais parfois ça permet de trouver le coupable après coup (à condition qu'ils arrivent encore à logguer quelque chose pendant l'incident) ...


    Tu peux aussi tenter de récupérer un dump mémoire avec Sysrq pendant le plantage (http://enoch_deb.hd.free.fr/mediawiki/index.php/Magic_Sysreq(...) si le kernel est encore à peut près en vie quand tu interviens c'est jouable ...

    Après arriver à exploiter le dump pour savoir ce qui s'est passé, c'est une autre histoire ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.