Forum Linux.général lecture du load average ? surtout niveau d'alarme ?

Posté par  .
Étiquettes : aucune
0
6
avr.
2011

Bonjour,

On voit souvent que le load average dépasse allègrement les 100%, pour se simplifier la vie on part tous, à tord ou à raison, du principe que jusqu'à 300% par cœur il faut pas s'inquiéter et que même des pics à 500% sont tolérables. De ma propre expérience c'est tout à fait vrai, des ralentissements (ressenti utilisateur) dès qu'on dépasse les 150%, et vu des pics à plus de 600% sans pour autant planter la machine.

Ceci étant du aux, système de file d'attente, de nice etc... ce qui est évident, mais ce principe est t il valable sur toutes les architectures ou seulement sur x86 ??
Est ce aussi le cas sur sparc, alpha, arm, rs6000, etc ??

Le comportement est il identique avec des machines multi-processeurs (physiques) pas simplement des cœurs dans un processeur unique ??

Donc doit t on intervenir systématiquement pour gérer des priorités dès qu'on attend des seuils de 200% ou plus tard ??

En fait le but de la question est la définition de seuils d'alarmes pour nagios dans un parc ou les configs sont variables (de 1 à 4 cœurs) et surtout hétérogènes (sun, dec, hp, ibm, bull)...

Ou est ce que je me prend la tête pour rien et que je dois mettre warning à 150% et erreur à 300% et basta ???

  • # En gros

    Posté par  . Évalué à 3.

    ça dépend complètement du type de machine, des tâches qu'elle doivent fournir...

    Mais on va dire que pour une machine en production, 100% tu émet un warning, 300% tu émet un critical.
    Pour les machines de pre-prod, tu peux être plus laxiste, et pour une machine de sauvegarde, celà va dépendre des performance, et seuls les tests te diront quels sont les seuils que tu pourra considérer comme anormaux.

    • [^] # Re: En gros

      Posté par  . Évalué à 1.

      Il va s'en dire qu'à critical, tu regarde le problème et tu interviens si tu vois qu'il y a un souci... à 200% celà dépends du type de services. Si tu as besoin d'une très haute réactivité pour certains services, tu peux effectivement émettre un critical à 200%, mais comme toujours, c'est l'expérience qui prévaut dans ces cas là.

    • [^] # Re: En gros

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

      Si on parle bien du load average tel qu'indiqué dans /proc/loadavg ou uptime(1), la mesure n'est pas en pourcents et un load de "3" peut très bien indiquer un système très largement sous utilisé.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # On ne plante pas

    Posté par  . Évalué à 2.

    De ma propre expérience c'est tout à fait vrai, des ralentissements (ressenti utilisateur) dès qu'on dépasse les 150%, et vu des pics à plus de 600% sans pour autant planter la machine.

    Une charge importante, même bien au dessus de 6, ne plante pas une machine. Ce qui provoque un plantage, c'est généralement d'atteindre des limites comme la mémoire virtuelle disponible ou le nombre de processus; cas souvent mal gérés; et encore, ces cas ne plantent pas souvent la machine qui se contente de faire du ménage.

    Il y a quand même deux points importants à noter:

    1. Une charge importante a de gros impacts sur le temps de réponse; pour un serveur qui est censé répondre dans un délais raisonnable aux requêtes reçues, ou pour un bureau de travail, ça peut tout à fait devenir inacceptable. La machine n'est pas plantée pour autant.

    2. Une charge importante peut être révélatrice d'une consommation de ressources en croissance qui va aboutir à un plantage de la machine. Par exemple sur une consommation excessive de mémoire, si la machine a beaucoup de swap, elle va passer par une phase de swap intensif qui va dégrader les performances, parfois pendant un moment.

    Ceci étant du aux, système de file d'attente, de nice etc... ce qui est évident, mais ce principe est t il valable sur toutes les architectures ou seulement sur x86 ?? Est ce aussi le cas sur sparc, alpha, arm, rs6000, etc ??

    Le comportement est il identique avec des machines multi-processeurs (physiques) pas simplement des cœurs dans un processeur unique ??

    Si tu es sur GNU/Linux, on considérer que le calcul du loadavg est le même, donc homogène. Tu as quand même le problème du nombre de cœur, un loadavg de 1.2 sur une machine bi-core n'indique pas de problème (1.2 processus a exécuter, 2 cœurs disponibles), sur un monoprocesseur c'est peut-être un problème. L'hyperthreading vient compliquer l'interprétation des valeurs.

    Si tu as un parc d'OS hétérogène, alors la comparaison n'est pas réellement possible. Certains OS comptent ou ne compte pas les taches dans différents états, bloqués sur certaines ressources... Certains vont distinguer les threads et les processus, d'autres pas. Certains vont aussi normaliser la valeur par rapport au nombre de processeur, afin qu'une valeur de 1 indique toujours une occupation complète de tous les CPU, quelque soit le nombre de CPU. Bref, c'est la foire.

  • # Merci tout le monde.

    Posté par  . Évalué à 0.

    Merci c'est plus clair .

    je vais commencé par un seuil bas et prudent et je le relevai petit à petit si nécessaire...

  • # pourcentage ?

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

    Le "load average" n'est pas un pourcentage : c'est le nombre de tâches dans la file d'attente d'exécution (état R) ou en attente d'entrées-sorties disque (état D) ( cf man proc).

    S'il reste inférieur à 1, c'est que le système traite les taches sans congestion.
    Par expérience , jusqu'à 10, le système continue de répondre.
    Au-dessus de 10, la machine commence à aller mal, et à partir de 30/40, je suis souvent obligé de rebooter plus ou moins violemment (impossible de se connecter à cause des time-out)

    • [^] # Re: pourcentage ?

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

      Presque. Ton deuxième paragraphe est à côté de la plaque mais le premier est presque bon (D c'est "uninterruptible sleep", c'est pas que pour les I/O disques, faut pas faire confiance à la doc) contrairement à toutes les conneries qui ont été dites plus haut.

      Si tu as 42 CPUs et un load de 40 pour cause de tâches en état R, ton système devrait toujours être parfaitement opérationel. En fait en jouant avec les priorités il y a moyen de faire monter le load très haut sans perte significative de réactivité : http://fruli.krunch.be/~krunch/src/jmpld.c

      Donc au final, perso, les alerts je les déclencherais quand le load atteint le nombre de CPUs.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # nagios

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

    Attention, pour un bi-coeur, les limites sont à 200% et non à 100%. Si tu as 6 coeurs, sous 600%, tu es en sous-charge...

    Bref, pour nagios, c'est un peu chiant car les limites dépendent du nombre de coeur.

    Il aurait été préférable de diviser à la source le loadaverage par le nombre de coeur pour dire que 100% = 100% d'utilisation de la machine mais ce n'est pas ce qui a été choisi.

Suivre le flux des commentaires

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