Pourquoi une moyenne mobile simple de 1/5/15 minute n'est-elle pas utilisée dans le calcul de la charge Linux?

Jusqu'à récemment, je pensais que la moyenne de charge (comme illustré par exemple en haut) était une moyenne mobile sur les n dernières valeurs du nombre de processus dans l'état "exécutable" ou "en cours d'exécution". Et n aurait été défini par la "longueur" de la moyenne mobile: puisque l'algorithme de calcul de la moyenne de charge semble se déclencher toutes les 5 secondes, n aurait été de 12 pour la moyenne de charge de 1 min, 12x5 pour la moyenne de charge de 5 min et 12x15 pour la moyenne de charge de 15 min.

Mais ensuite j'ai lu cet article: http://www.linuxjournal.com/article/9001 . L'article est assez ancien mais le même algorithme est implémenté aujourd'hui dans le noyau Linux. La moyenne de charge n'est pas une moyenne mobile mais un algorithme dont je ne connais pas le nom. Quoi qu'il en soit, j'ai fait une comparaison entre l'algorithme du noyau Linux et une moyenne mobile pour une charge périodique imaginaire:

graphique de charge .

Il ya une énorme différence.

Enfin mes questions sont:

Pourquoi cette implémentation a-t-elle été choisie par rapport à une vraie moyenne mobile, qui a un vrai sens pour tout le monde?
Pourquoi tout le monde parle de "1min de charge moyenne" car bien plus que la dernière minute est prise en compte par l'algorithme. (mathématiquement, toutes les mesures depuis le démarrage; en pratique, en tenant compte de l'erreur d'arrondi - encore beaucoup de mesures)

— user368507
source

C'est une moyenne mobile exponentielle (EMA), également utilisée par exemple en finance (analyse technique). Les avantages sont probablement les mêmes - l'EMA peut être calculée à partir de la valeur précédente et actuelle et les valeurs récentes ont plus de poids que les valeurs plus anciennes. Dans une AMM standard, la valeur la plus ancienne contribue autant à la moyenne que la plus récente, et nous pensons parfois que les valeurs les plus récentes sont plus importantes.

— jg-faustus

Cette différence remonte à l'original Berkeley Unix, et découle du fait que le noyau ne peut pas réellement garder une moyenne mobile; il lui faudrait pour cela conserver un grand nombre de lectures passées, et surtout dans l'ancien temps, il n'y avait tout simplement pas de mémoire disponible. L'algorithme utilisé à la place a l'avantage que tout le noyau doit conserver est le résultat du calcul précédent.

Gardez à l'esprit que l'algorithme était un peu plus proche de la vérité lorsque les vitesses de l'ordinateur et les cycles d'horloge correspondants étaient mesurés en dizaines de MHz au lieu de GHz; il y a beaucoup plus de temps pour que les écarts se glissent ces jours-ci.

— geekosaure
source

Ok, cela explique le choix de l'implémentation. Savez-vous pourquoi beaucoup de gens pensent que la moyenne des trois charges est calculée au cours des dernières 1min / 5min / 15min? Je pense que c'est faux, l'algorithme calcule une moyenne sur toutes les dernières valeurs. Je comprends que les anciennes valeurs ont moins d'importance que les nouvelles valeurs mais néanmoins, les valeurs plus anciennes que 1 minute ont encore une influence non négligeable sur la moyenne de charge de 1 minute. Donc à mon avis "1min / 5min / 15min" n'a aucun sens, mais je peux me tromper (?)

— user368507

Parce que c'est ce que la documentation, et tous les programmes qui les ont signalés en commençant par le BSD d'origine uptimeet w, l'ont affirmé; vous avez dû regarder les sources du noyau pour découvrir que ce n'était pas vrai.

— geekosaur

c'est vraiment dommage

— user368507

@ user5528 Les temps 1min/5min/15min ne raisonnent. Ils déterminent le temps après lequel l'influence de la charge actuelle diminue d'un facteur fixe (probablement e = 2,71 .. ou peut-être 2). Essayez-le.

— maaartinus

@maaartinus Oui. 1min / 5min / 15min déterminent le temps après lequel les anciennes mesures ont une pondération inférieure ou égale à 1 / e dans le calcul EMA. Cette précision n'apparaît pas dans le temps de disponibilité de l' homme ou le sommet de l'homme .

— user368507