Les moyennes de charge sont une mesure critique de l’industrie-mon entreprise dépense des millions d’instances de cloud Auto – scaling basées sur eux et d’autres métriques-mais sous Linux, il y a un mystère autour d’eux. Les moyennes de charge Linux suivent non seulement les tâches exécutables, mais également les tâches en état de veille ininterrompue. Pourquoi? Je n’ai jamais vu une explication. Dans cet article, je vais résoudre ce mystère et résumer les moyennes de charge comme référence pour tous ceux qui essaient de les interpréter.,
Les moyennes de charge Linux sont des « moyennes de charge système » qui montrent la demande de thread en cours d’exécution (tâche) sur le système sous la forme d’un nombre moyen de threads en cours d’exécution et en attente. Cela mesure la demande, qui peut être supérieure à ce que le système traite actuellement. La plupart des outils affichent trois moyennes, pour 1, 5 et 15 minutes:
quelques interprétations:
- Si les moyennes sont de 0,0, votre système est inactif.
- Si la moyenne de 1 minute est supérieure aux moyennes de 5 ou 15 minutes, la charge augmente.,
- Si la moyenne de 1 minute est inférieure aux moyennes de 5 ou 15 minutes, la charge diminue.
- s’ils sont supérieurs à votre nombre de CPU, vous pourriez avoir un problème de performance (cela dépend).
comme un ensemble de trois, Vous pouvez dire si la charge augmente ou diminue, ce qui est utile. Ils peuvent également être utiles lorsqu’une seule valeur de demande est souhaitée, par exemple pour une règle de mise à l’échelle automatique dans le cloud. Mais pour comprendre plus en détail est difficile sans l’aide d’autres paramètres., Une seule valeur de 23 à 25, en soi, ne signifie Rien, mais pourrait signifier quelque chose si le nombre de CPU est connu et s’il est connu pour être une charge de travail liée au CPU.
Au lieu d’essayer de déboguer les moyennes de charge, je passe généralement à d’autres métriques. Je vais en discuter dans la section » meilleures mesures » vers la fin.
historique
Les moyennes de charge d’origine ne montrent que la demande CPU: le nombre de processus en cours d’exécution plus ceux en attente d’exécution., Il y a une belle description de ceci dans la RFC 546 intitulée « Tenex load Averages », août 1973:
la moyenne de charge TENEX est une mesure de la demande de CPU. La moyenne de charge est une moyenne du nombre de processus exécutables sur une période donnée. Par exemple, une moyenne de charge horaire de 10 signifierait que (pour un seul système CPU) à tout moment pendant cette heure, on pourrait s’attendre à voir 1 processus en cours d’exécution et 9 autres prêts à s’exécuter (c’est-à-dire non bloqués pour les e/s) en attente du CPU.
la version de ceci sur ietf.,org renvoie à une analyse PDF d’un graphique de charge moyenne dessiné à la main de juillet 1973, montrant que cela a été surveillé pendant des décennies:
source: https://tools.ietf.org/html/rfc546
de nos jours, le code source des anciens systèmes d’exploitation peut également être trouvé en ligne. Voici un sauf de L’assemblage de macro DEC de TENEX (début des années 1970) SCHED.MAC:
Et voici un extrait de Linux today (include/linux/sched/loadavg.h):
#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */#define EXP_5 2014 /* 1/exp(5sec/5min) */#define EXP_15 2037 /* 1/exp(5sec/15min) */
Linux Code également en dur les constantes 1, 5 et 15 minutes.,
Il existe des métriques de moyenne de charge similaires dans les systèmes plus anciens, y compris Multics, qui avaient une moyenne de file d’attente de planification exponentielle.
Les Trois Nombres
Ces trois nombres sont les 1, 5 et 15 minutes de charges moyennes. Sauf qu’ils ne sont pas vraiment des moyennes, et ils ne sont pas 1, 5 et 15 minutes. Comme on peut le voir dans la source ci-dessus, 1, 5 et 15 minutes sont des constantes utilisées dans une équation, qui calculent des sommes mobiles exponentiellement amorties d’une moyenne de cinq secondes. Les moyennes de charge de 1, 5 et 15 minutes résultantes reflètent la charge bien au-delà de 1, 5 et 15 minutes.,
Si vous prenez un système inactif, puis commencez une charge de travail liée au processeur à un seul thread (un thread dans une boucle), quelle serait la moyenne de charge d’une minute après 60 secondes? Si c’était une moyenne simple, ce serait 1.0. Ici, c’est que l’expérience, graphique:
moyenne de Chargement expérience de visualiser exponentielle d’amortissement
La soi-disant « une minute en moyenne » seulement atteint environ 0.62 par la marque une minute. Pour en savoir plus sur l’équation et des expériences similaires, Dr., Neil Gunther a écrit un article sur les moyennes de charge: comment cela fonctionne, plus il y a beaucoup de commentaires de bloc source Linux dans loadavg.C.
Linux Uninterruptible Tasks
lorsque les moyennes de charge sont apparues pour la première fois sous Linux, elles reflétaient la demande de CPU, comme avec d’autres systèmes d’exploitation. Mais plus tard, Linux les a modifiés pour inclure non seulement des tâches exécutables, mais aussi des tâches à l’état non interruptible (TASK_UNINTERRUPTIBLE ou nr_uninterruptible). Cet état est utilisé par les chemins de code qui veulent éviter les interruptions par les signaux, ce qui inclut les tâches bloquées sur les E/S de disque et certains verrous., Vous avez peut-être déjà vu cet état: il apparaît comme l’état « D » dans la sortie ps et top. La page de manuel ps(1) l’appelle « sommeil ininterrompu (généralement IO) ».
L’ajout de l’état non interruptible signifie que les moyennes de charge Linux peuvent augmenter en raison d’une charge de travail d’E / S de disque (ou NFS), pas seulement de la demande du processeur. Pour tous ceux qui connaissent les autres systèmes d’exploitation et leurs moyennes de charge CPU, y compris cet état est au début profondément déroutant.
pourquoi? Pourquoi, exactement, Linux a-t-il fait cela?
Il existe d’innombrables articles sur les moyennes de charge, dont beaucoup soulignent le gotcha Linux nr_uninterruptible., Mais je n’en ai vu aucun qui explique ou même qui risque de deviner pourquoi il est inclus. Ma propre supposition aurait été qu’il est censé refléter la demande dans un sens plus général, plutôt que simplement la demande du processeur.
rechercher un ancien patch Linux
comprendre pourquoi quelque chose a changé sous Linux est facile: vous lisez l’historique des commits git sur le fichier en question et lisez la description du changement. J’ai vérifié l’historique sur loadavg.c, mais la modification qui a ajouté l’état non interruptible est antérieure à ce fichier, qui a été créé avec du code à partir d’un fichier antérieur., J’ai vérifié l’autre fichier, mais cette piste a également été froide: le code lui-même a sauté autour de différents fichiers. Dans l’espoir de prendre un raccourci, j’ai vidé « git log-p » pour L’ensemble du référentiel Linux Github, qui était de 4 Go de texte, et j’ai commencé à le lire à l’envers pour voir quand le code est apparu pour la première fois. Cela, aussi, était une impasse. Le changement le plus ancien dans L’ensemble du dépôt Linux remonte à 2005, lorsque Linus a importé Linux 2.6.12-rc2, et ce changement est antérieur à cela.
Il existe des dépôts Linux historiques (ici et ici), mais cette description de changement est également absente de ceux-ci., En essayant de découvrir, au moins, quand ce changement s’est produit, j’ai cherché des archives TAR sur kernel.org et a constaté qu’il avait changé par 0.99.15, et non par 0.99.13 – cependant, l’archive tar pour 0.99.14 était manquante. Je l’ai trouvé ailleurs, et j’ai confirmé que le changement était dans Linux 0.99 patchlevel 14, Nov 1993. J’espérais que la description de la version 0.99.14 par Linus expliquerait le changement, mais cela aussi était une impasse:
« les modifications apportées à la dernière version officielle (p13) sont trop nombreuses pour être mentionnées (ou même mémorisées)…, »- Linus
il mentionne des changements majeurs, mais pas le changement de la moyenne de charge.
sur la base de la date, j’ai recherché les archives de la liste de diffusion du noyau pour trouver le correctif réel, mais le plus ancien e-mail disponible date de juin 1995, lorsque l’administrateur système écrit:
« en travaillant sur un système pour faire évoluer ces archives de »
ma recherche commençait à se sentir maudite., Heureusement, j’ai trouvé des archives de liste de diffusion linux-devel plus anciennes, sauvées des sauvegardes de serveur, souvent stockées sous forme de tarballs de résumés. J’ai cherché plus de 6 000 résumés contenant plus de 98 000 e-mails, dont 30 000 dataient de 1993. Mais il manquait en quelque sorte à tous. Il semblait vraiment que la description originale du patch pourrait être perdue à jamais, et le « pourquoi » resterait un mystère.
l’origine de uninterruptible
heureusement, j’ai finalement trouvé le changement, dans un fichier de boîte aux lettres compressé à partir de 1993 oldlinux.org., Le voici:
c’est incroyable de lire les pensées derrière ce changement d’il y a presque 24 ans.
cela confirme que les moyennes de charge ont été délibérément modifiées pour refléter la demande d’autres ressources système, pas seulement les processeurs. Linux est passé de » moyennes de charge CPU « à ce que l’on pourrait appeler »moyennes de charge système ».
son exemple d’utilisation d’un disque d’échange plus lent est logique: en dégradant les performances du système, la demande sur le système (mesurée en cours d’exécution + file d’attente) devrait augmenter. Cependant, les moyennes de charge ont diminué car elles ne suivaient que les États D’exécution du processeur et non les États d’échange., Matthias pensait que c’était non intuitif, ce qui est le cas, alors il l’a réparé.
non interruptible aujourd’hui
Mais les moyennes de charge Linux ne sont-elles pas parfois trop élevées, plus que ce qui peut être expliqué par les e / s de disque? Oui, bien que je suppose que cela est dû à un nouveau chemin de code utilisant TASK_UNINTERRUPTIBLE qui n’existait pas en 1993. Dans Linux 0.99.14, il y avait 13 chemins de code qui définissaient directement TASK_UNINTERRUPTIBLE ou TASK_SWAPPING (l’état d’échange a ensuite été supprimé de Linux). De nos jours, dans Linux 4.12, il y a près de 400 chemins de code qui définissent TASK_UNINTERRUPTIBLE, y compris certaines primitives de verrouillage., Il est possible que l’un de ces chemins de code ne soit pas inclus dans les moyennes de charge. La prochaine fois que j’ai des moyennes de charge qui semblent trop élevées, je verrai si c’est le cas et si cela peut être corrigé.
J’ai envoyé un e-mail à Matthias (pour la première fois) pour lui demander ce qu’il pensait de son changement de charge moyenne presque 24 ans plus tard. Il a répondu en une heure (comme je l’ai mentionné sur Twitter), et a écrit:
« le point de « charge moyenne » est d’arriver à un nombre relatif à l’achalandage du système d’un point de vue humain. Task_uninterruptible signifie (signifiait?,) que le processus attend quelque chose comme une lecture de disquequi contribue à la charge du système. Un système fortement lié au disque peut être extrêmement lent mais n’a qu’une moyenne TASK_RUNNING de 0,1, ce qui n’aide personne. »
(d’Obtenir une réponse si rapidement, ou même une réponse à toutes, vraiment fait ma journée. Merci!)
Matthias pense donc toujours que cela a du sens, du moins compte tenu de ce que TASK_UNINTERRUPTIBLE signifiait.
mais TASK_UNITERRUPTIBLE correspond à plus de choses aujourd’hui. Devrions-nous changer les moyennes de charge pour être juste la demande CPU et disque?, Peter Zijstra, responsable du planificateur, m’a déjà envoyé une option intelligente à explorer pour ce faire: inclure task_struct- > in_iowait dans les moyennes de charge au lieu de TASK_UNINTERRUPTIBLE, afin qu’il corresponde plus étroitement aux E/S du disque. cela soulève cependant une autre question, qui est ce que nous voulons vraiment? Voulons-nous mesurer la demande sur le système en termes de threads, ou simplement la demande de ressources physiques? Si c’est le premier, alors attendre sur les verrous non interruptibles devrait être inclus car ces threads sont une demande sur le système. Ils ne sont pas inactifs., Donc, peut-être que les moyennes de charge Linux fonctionnent déjà comme nous le voulons.
pour mieux comprendre les chemins de code non interruptibles, j’aimerais un moyen de les mesurer en action. Ensuite, nous pouvons examiner différents exemples, quantifier le temps passé en eux, et voir si tout cela a un sens.
mesure des tâches non interruptibles
ce qui suit est un graphique de flamme hors processeur d’un serveur de production, couvrant 60 secondes et montrant uniquement les piles du noyau, où je filtre pour inclure uniquement celles dans L’état TASK_UNINTERRUPTIBLE (SVG)., Il fournit de nombreux exemples de chemins de code non interruptibles:
Si vous êtes nouveau dans les graphiques de flamme hors processeur: vous pouvez cliquer sur les images pour zoomer, en examinant les piles complètes qui apparaissent comme une tour de cadres. La taille de l’axe des x est proportionnelle au temps passé bloqué hors CPU, et l’ordre de tri (de gauche à droite) n’a aucune signification réelle. La couleur est bleue pour les piles hors CPU (j’utilise des couleurs chaudes pour les piles sur CPU), et la saturation a une variance aléatoire pour différencier les images.,
j’ai généré cela en utilisant mon outil offcputime de bcc (cet outil a besoin des fonctionnalités eBPF de Linux 4.8+), et mon logiciel flame graph:
j’utilise awk pour changer la sortie de microsecondes en millisecondes. L’offcputime « state state 2 » correspond à task_uninterruptible (voir sched.h), et est une option que je viens d’Ajouter pour ce post. Josef Bacik de Facebook l’a fait pour la première fois avec son outil kernelscope, qui utilise également des graphiques bcc et flame. Dans mes exemples, je montre simplement les piles du noyau, mais offcputime.py prend également en charge l’affichage des piles utilisateur.,
quant au graphique de flamme ci-dessus: il montre que seulement 926 ms sur 60 secondes ont été passées en sommeil ininterrompu. Cela ne fait qu’ajouter 0,015 à nos moyennes de charge. Il est temps dans certains chemins de cgroup, mais ce serveur ne fait pas beaucoup d’e/s de disque.
En voici un plus intéressant, cette fois-ci ne couvrant que 10 Secondes (SVG):
/* wait to be given the lock */ while (true) { set_task_state(tsk, TASK_UNINTERRUPTIBLE); if (!waiter.task) break; schedule(); }
Il s’agit d’un code d’acquisition de, Linux a des versions non interruptibles et interruptibles de mutex acquire functions (par exemple, mutex_lock () vs mutex_lock_interruptible (), et down () et down_interruptible () pour les sémaphores). Les versions interruptibles permettent à la tâche d’être interrompue par un signal, puis de se réveiller pour la traiter avant que le verrou ne soit acquis. Le temps dans le verrouillage sans interruption dort n’ajoute généralement pas beaucoup aux moyennes de charge, mais dans ce cas, ils ajoutent 0,30., Si c’était beaucoup plus élevé, il vaudrait la peine d’analyser pour voir si la contention de verrouillage pourrait être réduite (par exemple, je commencerais à creuser sur systemd-journal et proc_pid_cmdline_read()!), ce qui devrait améliorer les performances et abaisser la moyenne de charge.
est-il logique que ces chemins de code soient inclus dans la moyenne de charge? Oui, j’avais qu’à le dire. Ces threads sont en train de faire du travail et se bloquent sur un verrou. Ils ne sont pas inactifs. Ils sont la demande sur le système, mais pour les ressources logicielles plutôt que les ressources matérielles.,
décomposition des moyennes de charge Linux
La valeur moyenne de charge Linux peut-elle être entièrement décomposée en composants? Voici un exemple: sur un système CPU idle 8, j’ai lancé tar pour archiver certains fichiers non mis en cache. Il passe plusieurs minutes principalement bloqué sur les lectures de disque. Voici les statistiques, collectées à partir de trois fenêtres de terminal différentes:
j’ai également collecté un graphique de flamme hors processeur juste pour L’état non interruptible (SVG):
la moyenne de charge finale d’une minute est de 1,19. Permettez-moi de décomposer cela:
- 0.33 est du temps CPU de tar (pidstat)
- 0.,67 provient du disque non interruptible de tar lit, déduit (offcpu flame graph a ceci à 0.69, je soupçonne qu’il a commencé à collecter un peu plus tard et couvre une plage de temps légèrement différente)
- 0.04 provient d’autres consommateurs de CPU (utilisateur iostat + système, moins le processeur de tar de pidstat)
- 0.11 provient des travailleurs du noyau/ul>
cela ajoute jusqu’à 1,15. Il me manque toujours 0.,04, dont certaines peuvent être des erreurs d’arrondi et de décalage d’intervalle de mesure, mais beaucoup peuvent être dues au fait que la moyenne de charge est une somme mobile amortie de manière exponentielle, alors que les autres moyennes que j’utilise (pidstat, iostat) sont des moyennes normales. Avant 1.19, la moyenne d’une minute était de 1.25, donc une partie de cela nous traînera toujours haut. Combien? D’après mes graphiques précédents, à la marque d’une minute, 62% de la mesure provenait de cette minute, et le reste était plus ancien. Donc 0,62 x 1,15 + 0,38 x 1,25 = 1,18. C’est assez proche du 1.19 rapporté.,
c’est un système où un thread (tar) plus un peu plus (un peu de temps dans les threads de travail du noyau) font du travail, et Linux rapporte la moyenne de charge comme 1.19, ce qui est logique. S’il mesurait les « moyennes de charge CPU », le système aurait rapporté 0,37 (déduit du résumé de mpstat), ce qui est correct pour les ressources CPU uniquement, mais cache le fait qu’il y a une demande pour plus d’un thread de travail.
j’espère que cet exemple montre que les nombres signifient vraiment quelque chose de délibéré (CPU + onduleur), et vous pouvez les décomposer et comprendre.,
donner un sens aux moyennes de charge Linux
j’ai grandi avec des systèmes D’exploitation où les moyennes de charge signifiaient des moyennes de charge CPU, donc la version Linux m’a toujours dérangé. Le vrai problème est peut-être que les mots « moyennes de charge » sont à peu près aussi ambigus que « E/S ». Quel type d’E/S? Disk I/O? Système de fichier I/O? Réseau I/O? … De même, en charge des moyennes? Moyennes de charge CPU? Moyennes de charge du système?, Le clarifier de cette façon me permet de le comprendre comme ceci:
- sous Linux, les moyennes de charge sont (ou essaient d’être) des « moyennes de charge système », pour le système dans son ensemble, mesurant le nombre de threads qui fonctionnent et attendent de fonctionner (CPU, disque, verrous non interruptibles). Autrement dit, il mesure le nombre de threads qui ne sont pas complètement inactifs. Avantage: inclut la demande pour différentes ressources.
- sur d’autres systèmes D’exploitation, les moyennes de charge sont des « moyennes de charge CPU », mesurant le nombre de threads CPU en cours d’exécution + CPU exécutables. Avantage: peut être plus facile à comprendre et à raisonner (pour les processeurs uniquement).,
notez qu’il existe un autre type possible: « moyennes de charge de ressources physiques », qui inclurait la charge pour les ressources physiques uniquement (CPU + disque).
peut-être qu’un jour, nous ajouterons des moyennes de charge supplémentaires à Linux, et laisserons l’utilisateur choisir ce qu’il veut utiliser: une « moyenne de charge CPU » distincte, « moyenne de charge Disque », « moyenne de charge réseau », etc. Ou utilisez simplement différentes métriques.
qu’est Ce qu’un « bon » ou « mauvais » charge moyenne?,
moyennes de charge mesurées dans un outil moderne certaines personnes ont trouvé des valeurs qui semblent fonctionner pour leurs systèmes et charges de travail: ils savent que lorsque la charge dépasse x, la latence des applications est élevée et les clients commencent à se plaindre. Mais il n’y a pas vraiment de règles pour cela.
avec les moyennes de charge CPU, on peut diviser la valeur par le nombre de CPU, puis dire que si ce ratio est supérieur à 1.0, vous exécutez à saturation, ce qui peut causer des problèmes de performances., C’est quelque peu ambigu, car c’est une moyenne à long terme (au moins une minute) qui peut masquer la variation. Un système avec un rapport de 1.5 pourrait fonctionner correctement, tandis qu’un autre à 1.5 qui était bursty dans la minute pourrait mal fonctionner.
j’ai déjà administré un serveur de messagerie à deux processeurs qui, pendant la journée, fonctionnait avec une moyenne de charge CPU comprise entre 11 et 16 (un rapport compris entre 5,5 et 8). La latence était acceptable et personne ne s’est plaint. C’est un exemple extrême: la plupart des systèmes souffriront avec un rapport charge/CPU de seulement 2.,
quant aux moyennes de charge système de Linux: elles sont encore plus ambiguës car elles couvrent différents types de ressources, vous ne pouvez donc pas simplement diviser par le nombre de CPU. C’est plus utile pour les comparaisons relatives: si vous savez que le système fonctionne correctement à une charge de 20, et qu’il est maintenant à 40, Il est temps de creuser avec d’autres métriques pour voir ce qui se passe.
meilleures métriques
lorsque les moyennes de charge Linux augmentent, vous savez que vous avez une demande plus élevée en ressources (Processeurs, Disques et certains verrous), mais vous ne savez pas lesquels. Vous pouvez utiliser d’autres mesures pour clarifier., Par exemple, pour les processeurs:
les deux premiers sont des mesures d’utilisation, les trois derniers sont des mesures de saturation. Les mesures d’utilisation sont utiles pour la caractérisation de la charge de travail et les mesures de saturation pour identifier un problème de performance. Les meilleures mesures de saturation du processeur sont les mesures de latence de la file d’attente d’exécution (ou du Planificateur): le temps pendant lequel une tâche/thread était dans un État exécutable, mais devait attendre son tour. Ceux-ci vous permettent de calculer l’ampleur d’un problème de performance, par exemple, le pourcentage de temps passé par un thread dans la latence du planificateur., Mesurer la longueur de la file d’attente d’exécution peut plutôt suggérer qu’il y a un problème, mais il est plus difficile d’estimer l’ampleur.
l’installation schedstats a été faite un noyau accordable dans Linux 4.6 (noyau sysctl.sched_schedstats) et modifié pour être désactivé par défaut. La comptabilité des retards expose la même métrique de latence du planificateur, qui est dans cpustat et je viens de suggérer de l’ajouter à htop aussi, car cela faciliterait l’utilisation par les gens., Plus facile que, disons, de gratter la mesure de temps d’attente (latence du planificateur) à partir de la sortie (non documentée) /proc/sched_debug:
En dehors des métriques CPU, vous pouvez également rechercher des métriques d’utilisation et de saturation pour les périphériques de disque. Je me concentre sur de telles métriques dans la méthode USE, et j’ai une liste de contrôle Linux de celles-ci.
bien qu’il existe des métriques plus explicites, cela ne signifie pas que les moyennes de charge sont inutiles. Ils sont utilisés avec succès dans les stratégies de mise à l’échelle pour les microservices de cloud computing, ainsi que d’autres mesures. Cela aide les microservices à répondre à différents types D’augmentations de charge, CPU ou e/s de disque., Avec ces politiques, il est plus sûr de se tromper sur la mise à l’échelle (coût de l’argent) que de ne pas augmenter (coût des clients), il est donc souhaitable d’inclure plus de signaux. Si nous augmentons trop, Nous déboguerons pourquoi le lendemain.
la seule chose pour laquelle je continue à utiliser les moyennes de charge est leurs informations historiques. Si on me demande de vérifier une instance peu performante sur le cloud, puis de me connecter et de constater que la moyenne d’une minute est beaucoup plus faible que la moyenne de quinze minutes, c’est un gros indice que je pourrais être trop tard pour voir le problème de performance en direct., Mais je ne passe que quelques secondes à contempler les moyennes de charge, avant de passer à d’autres mesures.
Conclusion
en 1993, un ingénieur Linux a trouvé un cas non intuitif avec des moyennes de charge, et avec un patch de trois lignes les a changés pour toujours de « moyennes de charge CPU » à ce que l’on pourrait appeler « moyennes de charge système. »Son changement comprenait des tâches à l’état non interruptible, de sorte que les moyennes de charge reflétaient la demande de ressources de disque et pas seulement de processeurs., Ces moyennes de charge système comptent le nombre de threads travaillant et en attente de travail, et sont résumées comme un triplet de moyennes de somme mobile à amortissement exponentiel qui utilisent 1, 5 et 15 minutes comme constantes dans une équation. Ce triplet de nombres vous permet de voir si la charge augmente ou diminue, et leur plus grande valeur peut être pour des comparaisons relatives avec eux-mêmes.
l’utilisation de l’état uninterruptible a depuis augmenté dans le noyau Linux, et inclut de nos jours des primitives de verrouillage uninterruptible., Si la moyenne de charge est une mesure de la demande en termes de threads en cours d’exécution et en attente (et non strictement les threads qui veulent des ressources matérielles), ils fonctionnent toujours comme nous le souhaitons.
dans ce post, j’ai déterré le correctif Linux load average de 1993 – qui était étonnamment difficile à trouver – contenant l’explication originale de l’auteur. J’ai également mesuré les traces de pile et le temps dans l’état non interruptible en utilisant bcc/eBPF sur un système Linux moderne, et visualisé cette fois sous la forme d’un graphique de flamme hors processeur., Cette visualisation fournit de nombreux exemples de mises en veille non interruptibles et peut être générée chaque fois que nécessaire pour expliquer des moyennes de charge inhabituellement élevées. J’ai également proposé d’autres métriques que vous pouvez utiliser pour comprendre la charge du système plus en détail, au lieu des moyennes de charge.
je terminerai en citant un commentaire en haut de kernel / sched / loadavg.c dans la source Linux, par le responsable du planificateur Peter Zijlstra:
* ce fichier contient les bits magiques nécessaires pour calculer la figure loadavg globale
*. C’est un nombre stupide mais les gens pensent que c’est important., Nous passons par
* de grandes douleurs pour le faire fonctionner sur de grandes machines et des noyaux chatouilleux.- Saltzer, J., et J. Gintell. « L’Instrumentation de Multics,” CACM, août 1970 (explique les exponentielles).
- référence de commande Multics system_performance_graph (mentionne la moyenne de 1 minute).
- code source TENEX (le code moyen de charge est dans le schéma.MAC).
- RFC 546 « Tenex load Averages for July 1973 » (explique la mesure de la demande CPU).
- Bobrow, D., et coll., « TENEX: a Paged Time Sharing System for the PDP-10 », Communications of the ACM, mars 1972 (explique le triplet de charge moyenne).
- Gunther, N. » Unix Load Average Part 1: How It Works » PDF (explique les calculs exponentiels).
- e-mail de Linus à propos de Linux 0.99 patchlevel 14.
- l’e-mail de modification de la moyenne de charge est activé oldlinux.org (dans alan-old-funet-lists / kernel.1993.gz, et non dans les répertoires linux, que j’ai cherché en premier).
- Linux kernel/sched.C source avant et après la charge moyenne changement: 0.99.13, 0.99.14.
- archive TAR Pour Linux 0.,99 versions sont en cours kernel.org.
- le code moyen de charge Linux actuel: loadavg.c, loadavg.h
- Les outils d’analyse bcc incluent mon offcputime, utilisé pour tracer TASK_UNINTERRUPTIBLE.
- les graphes de flamme ont été utilisés pour visualiser les chemins non interruptibles.
Merci à Deirdre Straughan pour les modifications.
