Forum Linux.général Identification responsable d'une forte charge sur un serveur

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
17
août
2017

Bonjour,

J'ai un serveur qui de temps en temps est sous le coup d'une forte charge (loadavg > 10) et je n'arrive pas à identifier le responsable.
Cela arrive aléatoirement et je ne peux pas être devant le serveur en permanence pour surveiller ce qui se passe.

Est-ce qu'il existe un script quelque part qui identifierait automatiquement la cause d'une forte charge ou qui du moins enregistrerait tous les logs d'un coup pour permettre d'identifier le coupable ?

Merci

  • # Supervision

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

    Alors non il n'y a pas de script auto-magique capable de cela, par contre il existe des outils de monitoring et de supervision pour historiser les compteurs (collectd, monit (très bof), cacti, zabbix, …) .

    L'enregistrement des logs est une question surprenante, par définition les logs sont enregistrés et archivés donc analyser les logs en fonction de la date est assez simple.

    Pour finir je rappelle juste que le load average en soit n'est pas un indicateur suffisament pertinent de l'état de ton serveur, il faut l'utiliser en correlation avec des métriques plus adaptées (temps de réponse du service) ou comme dernière chance. Et un load average de 10 sur une machine à 16 core n'est pas une valeur si problèmatique que ça par exemple.

    http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

    • [^] # Re: Supervision

      Posté par  . Évalué à 2.

      Pour les logs, je voulais dire s'il existait un script qui enregistrait des infos qui ne sont pas déjà présentes dans les logs existant (top, iostat, vmstat, iotop, etc.).

      Mon serveur est un Atom N2800 et je viens de voir le load average monter à 20, donc je pense qu'il y a réellement un problème.

      • [^] # Re: Supervision

        Posté par  . Évalué à 3.

        je viens de voir le load average monter à 20

        Combien de cœurs a ta machine ?

        Sur une machine mono-cœur une valeur « maximum » du load c’est 2 (1 process qui s’exécute et 1 qui attend). Il faut multiplier par le nombre de cœurs.

        J’ai fait un petit utilitaire en bash pour enregistrer la sortie de certaines commandes dans des fichiers RRD, sysrrdd, c’est juste un wrapper pour rrdtool (qui a je trouve une syntaxe à chier…), ça lance un daemon qui met les fichiers à jour et génère des graphes à intervalle régulier. Ça marche plutôt bien. J’ai trois « modules » (vmstat, uptime, loadavg) qui mettent à jour toutes les secondes, c’est peu consommateur. C’est vraiment minimal, ajouter un module consiste à copier un module existant et adapter au besoin.

        Voilà pour l’auto-promo :) Manipuler des RRD ça demande de comprendre le principe et d’apprendre la syntaxe mais ce n’est pas du temps de perdu, ça te donne vraiment le contrôle total sur la manière dont tu graphes et dont tu archives ta donnée. L’avantage de RRD sur ses concurrents plus modernes c’est que c’est archi-éprouvé, « ça juste marche » comme certains diraient.

        Il y a un autre outil dont je n’ai appris l’existence que très récemment et que je n’ai jamais eu le temps de tester c’est sysstat. Il semblerait que l’on trouve cet outil non seulement sur Linux mais aussi sur des Unix et ça pourrait répondre à ton besoin.

        Sinon, comme déjà suggéré, installe carrément une solution de supervision. Si tu peux avoir une machine de libre, avec une installation de CES, en mode simple (standalone: tout sur la même machine), tu as un outil très pratique clé en main qui te permettra de répondre à ton besoin et à une partie de ceux à venir.

        Pour le load average et autres contrôles de ce genre, avec Centreon (ou autre solution Nagios-like) il faut que l’hôte que tu veux superviser ait soit un agent NRPE soit un agent SNMP (snmpd). Je te recommande plutôt SNMP car c’est le moins intrusif (et SNMP est fait exactement pour ça), d’ailleurs le daemon snmpd est souvent actif par défaut (avec juste quelques infos disponibles de base), il suffit de le configurer.

        Bon courage.

        • [^] # Re: Supervision

          Posté par  . Évalué à 2.

          J'ai un Atom N2800, donc il a 4 coeurs. Mais c'est surtout que je n'ai presque rien qui tourne dessus donc je dois avoir un process pas normal quelque part.

          En fait ce n'est pas tant d'archiver tous les logs qui pose problème, mais le fait de devoir faire le détective et d'inspecter tous les logs à chaque fois pour trouver le coupable.
          J'imaginais qu'il y avait un bel utilitaire qui permettait à coup de règles heuristiques, de donner directement les hypothèses pour identifier le coupable mais je suppose que c'est trop demander (mais c'est une bonne idée de projet tiens !).
          Mais on arrive à faire jouer une IA à Dota 2, donc pourquoi pas une IA pour identifier le responsable d'un load average élevé ! ;-)

          Merci

  • # atop

    Posté par  . Évalué à 4.

    atop permet d'enregistrer un « top » régulier dans un log que tu peux lire après.

    atop -w rawfile [-a] [-S] [ interval [ samples ]]
atop -r [ rawfile ] [-b hh:mm ] [-e hh:mm ] [-g|-m|-d|-n|-u|-p|-s|-c|-v|-o] [-C|-M|-D|-N|-A] [-f1x] [-L linelen] [-Plabel[,label]...]

    • [^] # Re: atop

      Posté par  . Évalué à 2.

      Merci pour l'astuce, mais je crois que top (ou atop) ne suffira pas tout le temps. À lire un peu sur le sujet, il semblerait qu'il faille aussi regarder du côté de vmstat, iostat et iotop.

      • [^] # Re: atop

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Tant qu'on est dans les tops:

        • apachetop (si apache)
        • mytop (si mysql)
        • iftop
        • htop

        Mais encore
        - free
        - ps
        - netstat

        Bonne chasse

        La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: atop

      Posté par  . Évalué à 2.

      Merci ! Je connaissais pas, j'avais fait un script à la main pour faire ça.

  • # sysstat

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

    Je pense que le vénérable sysstat est un sérieux candidat pour ton besoin. Il faut un peu de temps pour se familiariser avec la commande sar et ses multiples options pour accéder aux données qui t'intéressent mais ça peut valoir la peine de découvrir cet outil.

    Sa description, dans Debian 8 :

    Description-en: system performance tools for Linux
 The sysstat package contains the following system performance tools:
  - sar: collects and reports system activity information;
  - iostat: reports CPU utilization and disk I/O statistics;
  - mpstat: reports global and per-processor statistics;
  - pidstat: reports statistics for Linux tasks (processes);
  - sadf: displays data collected by sar in various formats;
  - cifsiostat: reports I/O statistics for CIFS filesystems;
  - nfsiostat-sysstat: (obsolete) reports I/O statistics
    for network filesystems.
 .
 The statistics reported by sar deal with I/O transfer rates,
 paging activity, process-related activities, interrupts,
 network activity, memory and swap space utilization, CPU
 utilization, kernel activities and TTY statistics, among
 others. Both UP and SMP machines are fully supported.

    Debian Consultant @ DEBAMAX

    • [^] # Re: sysstat

      Posté par  . Évalué à 2.

      Ok je vais regarder cela.
      Tu penses vraiment que rien qu'avec sysstat je peux surveiller la charge et trouver la raison en cas de forte charge ?
      Tu as de l'expérience sur le sujet ou bien tu as un lien vers quelqu'un qui l'a fait ?

      Merci !

      • [^] # Re: sysstat

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

        Been there, done that.

        Tu as moyen de savoir quand le problème apparaît/disparaît, le lien avec les éventuelles I/O disque (top 1 des pistes considérées après avoir exclu le CPU), et parfois on tombe sur des surprises, genre des soucis réseau. Cela ne va pas te donner nécessairement le coupable (il n'y a pas forcément unicité), mais tu auras une bien meilleure vision de ce qui provoque le pic de charge, sans avoir besoin de mettre en place munin ou un autre outil de monitoring un peu plus avancé.

        Pourquoi je mentionne cela : J'ai monté un monitoring minimaliste basé là-dessus à la demande d'un client, et je donne des cours dont le programme inclut cet outil.

        Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

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