[Kernel] Comportement du 3.3.8 en overload [RESOLU]

Message

xkomodor · Post by **xkomodor** » Mon Jul 09, 2012 9:25 pm

Bonjour le forum,

Je suis utilisateur de Calculate Linux et Gentoo au quotidien.

Je me suis rendu compte que sur plusieurs machines le kernel 3.3.8 issu aussi bien des gentoo-sources ainsi que de la version construite par les admins de Calculate Linux avait plus que tendance à surcharger le système.

Pour l'occasion, j'ai ouvert un post sur le forum de Calculate Linux sur le lien suivant en prenant des captures de mon htop dans les mêmes conditions c'est à dire juste après l'ouverture de session de KDE dans les 2 cas de figure.

J'ai pu faire les tests en utilisant le kernel 3.3.8 en le mettant en concurrence avec le 3.2.5 toujours de Calculate Linux.

La situation étant tellement préoccupante que j'ai dû downgrader un serveur web sous Gentoo (100% pur sucre) de la version donc 3.3.8 où je notais des charges de 0.50 en moyenne en permanence et qu'en passant au 3.2.12-gentoo je revenais à la normale avec une charge de 0.05 !

Voici le lien vers mon post avec les captures sur le forum de Calculate Linux :
http://www.calculate-linux.org/boards/1 ... sage-16214

Ainsi, je viens vers vous pour savoir si vous aviez le même soucis ?

Merci de vos retours et conseils éventuels.

XKomodor | Julien

El_Goretto · Post by **El_Goretto** » Mon Jul 09, 2012 9:47 pm

xkomodor wrote:Bonjour le forum,
Je me suis rendu compte que sur plusieurs machines le kernel 3.8.8 [...] avait plus que tendance à surcharger le système.

Diantre, pourtant on n'est plus le 1er avril depuis un moment déjà?

xkomodor wrote:Merci de vos retours et conseils éventuels.

La drogue c'est mal, m'voyez?

http://kernel.org/

xkomodor · Post by **xkomodor** » Mon Jul 09, 2012 10:03 pm

Salut,

El_Goretto wrote:
xkomodor wrote:Bonjour le forum,
Je me suis rendu compte que sur plusieurs machines le kernel 3.8.8 [...] avait plus que tendance à surcharger le système.
Diantre, pourtant on n'est plus le 1er avril depuis un moment déjà?

xkomodor wrote:Merci de vos retours et conseils éventuels.
La drogue c'est mal, m'voyez?

http://kernel.org/

Mouarf, des fois je me demande si je ne suis pas dyslexique sur mon clavier moi !

De "bonne guerre", j'ai corrigé

Merci

XKomodor | Julien

Post by **guilc** » Tue Jul 10, 2012 7:31 am

Effectivement, en jetant un coup d'oeil à mes graphes j'ai aussi une augmentation de la charge moyenne depuis le passage en 3.3 (et idem en 3.4), que ce soit sur mon desktop (kde) ou sur ma gateway (mais là, la différence est beaucoup moins visible).

Tu peux t'amuser à éplucher tous les commits pour voir d'où ça viens, mais bon courage.
Mon avis est que : ça n'impacte pas la réactivité du système, donc ce n'est pas un problème. La charge n'est pas et n'a jamais été un outil de mesure précis : c'est juste un indicateur permettant d'estimer le backlog du scheduleur.

[EDIT]
Je complète mon propos avec le graphe :
Le desktop (Core 2 Quad Q9400) : https://www.xwing.info/system-load-year.png on voit l'augmentation courant avril
La gateway (Atom D510) : https://www.xwing.info/rrd/system-load-year.png on voit aussi l'augmentation courant avril, mais là c'est plus minime

El_Goretto · Post by **El_Goretto** » Tue Jul 10, 2012 8:56 am

Plus sérieusement, je suis passé d'un 3.2 à un 3.4 sur mon home serveur, et oui, maintenant que tu le dit, la métrique "load" semble un poil plus élevée. Mais même observation que guilc, la capacité de traitement et la réactivité du système ne semble pas affectée, à vu de nez. Un atom N330 (simili-quad) avec un load de 14/16 répond toujours très bien (I2P+freenet 24/24 avec un emerge ou un backup + du tunnelling ssh, etc).

xkomodor · Post by **xkomodor** » Wed Jul 11, 2012 9:17 am

Salut,

Merci de vos retours.

Je vais rester sur les anciens kernels qui pour le moment ne me posent pas de problème et voir si les futurs versions "corrigent" cet aspect.

XKomodor | Julien

DuF · Post by **DuF** » Wed Jul 11, 2012 7:08 pm

Bonjour,

Je ne vais pas revenir sur le fait que le "load average" n'a pas d'intérêt (si tant est qu'il s'agisse du sujet), mais bon, ça peut servir comme indicateur de "changement".

Perso, en noyau 3.4.0, le "load average" indiqué avec mon i7-3770 est de :

Code: Select all

duf@genduf ~ $ cat /proc/loadavg 
0.22 0.26 0.31 1/364 7961

Et pour identifier la raison du changement de comportement, faudrait se taper les changelog du noyau pour voir ce qui a pu bouger sur les schedulers, tous les pilotes utilisés qui touchent de près ou de loin à des I/O....

@+

Post by **guilc** » Thu Jul 12, 2012 7:52 am

DuF wrote:Bonjour,

Je ne vais pas revenir sur le fait que le "load average" n'a pas d'intérêt (si tant est qu'il s'agisse du sujet), mais bon, ça peut servir comme indicateur de "changement".

On est bien d'accord

DuF wrote: Perso, en noyau 3.4.0, le "load average" indiqué avec mon i7-3770 est de :
Code: Select all
duf@genduf ~ $ cat /proc/loadavg 
0.22 0.26 0.31 1/364 7961

On reste de toute façon dans des valeurs négligeable. Dans tous les cas, y compris pour les 0.5 de xkomodor, c'est non significatif et ce sont des valeurs où la réactivité du système n'est absolument pas impactée. En fait, je réfute le terme de système "surchargé" :p
Pour moi, ce n'est pas un problème et ça ne mérite pas de rester scotché en 3.2 (enfin, l'un dans l'autre, pour des serveurs, 3.2 c'est le dernier kernel "LTS", donc pourquoi pas non plus !)

DuF wrote: Et pour identifier la raison du changement de comportement, faudrait se taper les changelog du noyau pour voir ce qui a pu bouger sur les schedulers, tous les pilotes utilisés qui touchent de près ou de loin à des I/O....

On est bien d'accord. Mais à la simple idée de faire ça, je.... rends les armes

kwenspc · Post by **kwenspc** » Thu Jul 12, 2012 10:04 am

guilc wrote:
DuF wrote: Et pour identifier la raison du changement de comportement, faudrait se taper les changelog du noyau pour voir ce qui a pu bouger sur les schedulers, tous les pilotes utilisés qui touchent de près ou de loin à des I/O....
On est bien d'accord. Mais à la simple idée de faire ça, je.... rends les armes

Allez, un ptit git blame des familles les gens!

Post by **guilc** » Thu Jul 12, 2012 12:12 pm

kwenspc wrote:
guilc wrote:
DuF wrote: Et pour identifier la raison du changement de comportement, faudrait se taper les changelog du noyau pour voir ce qui a pu bouger sur les schedulers, tous les pilotes utilisés qui touchent de près ou de loin à des I/O....
On est bien d'accord. Mais à la simple idée de faire ça, je.... rends les armes
Allez, un ptit git blame des familles les gens!

un git bisect tu veux dire plutot

Je te souhaites bien du courage, tu vas y passer du temps !
1) git bissect
2) compiler
3) rebooter
4) regarder le comportement
5) recommencer 1)

Quand tu en seras à quelques centaines de bissections, je penses que tu lâcheras l'affaire

Leander256 · Post by **Leander256** » Thu Jul 12, 2012 3:43 pm

guilc wrote: un git bisect tu veux dire plutot
Je te souhaites bien du courage, tu vas y passer du temps !
1) git bissect
2) compiler
3) rebooter
4) regarder le comportement
5) recommencer 1)

Quand tu en seras à quelques centaines de bissections, je penses que tu lâcheras l'affaire

Il me semblait que bissect fonctionnait par dichotomie, donc en coupant au milieu à chaque fois, et donc en temps logarithmique plutôt que linéaire. Si on prend 65536 commits entre deux noyaux (nombre complètement au pif), ça ne fait "que" 16 étapes. On m'aurait menti?

xkomodor · Post by **xkomodor** » Thu Jul 12, 2012 4:48 pm

Salut,

Je reviens un peu sur le sujet juste pour ma culture personnelle, car il est vrai que je m'accorde à lire des chiffres sans finalement trop savoir ce qu'il se passe derrière et vu qu'on lit un peu tout et rien à ce sujet ....

Dans le cas où cette "charge" qui vous m'avez convaincu, ne peut-être que finalement insignifiante par rapport à la machine en elle-même, pourriez-vous me donner un ou deux liens qui me permettraient d'en savoir un peu plus ?

J'utilise le 3.2.5 en attendant en place du 3.3.8 sur mon portable et j'avais un peu peur de voir par exemple l'autonomie de mon x61 revue à la baisse.

Merci de votre retour.

XKomodor | Julien

PS : Il est vrai que je ne prête que peu d'intérêt à cette charge, j'utilise un ptit serveur perso sous OpenBSD qui n'arrive jamais à 0 mais plutôt à 0.20 en moyenne. Maintenant, sur ce serveur web lorsque vous avez une moyenne de 0.10 en pleine journée avec pas mal d'utilisateur et qu'au final en pleine nuit, donc peu de trafic vous le voyez à 0.50 même des fois 1.00 ca fait faire un certain stress :p

DuF · Post by **DuF** » Thu Jul 12, 2012 9:17 pm

xkomodor wrote:Salut,

Je reviens un peu sur le sujet juste pour ma culture personnelle, car il est vrai que je m'accorde à lire des chiffres sans finalement trop savoir ce qu'il se passe derrière et vu qu'on lit un peu tout et rien à ce sujet ....

Dans le cas où cette "charge" qui vous m'avez convaincu, ne peut-être que finalement insignifiante par rapport à la machine en elle-même, pourriez-vous me donner un ou deux liens qui me permettraient d'en savoir un peu plus ?

J'utilise le 3.2.5 en attendant en place du 3.3.8 sur mon portable et j'avais un peu peur de voir par exemple l'autonomie de mon x61 revue à la baisse.

Merci de votre retour.

XKomodor | Julien

PS : Il est vrai que je ne prête que peu d'intérêt à cette charge, j'utilise un ptit serveur perso sous OpenBSD qui n'arrive jamais à 0 mais plutôt à 0.20 en moyenne. Maintenant, sur ce serveur web lorsque vous avez une moyenne de 0.10 en pleine journée avec pas mal d'utilisateur et qu'au final en pleine nuit, donc peut de trafic vous le voyez à 0.50 même des fois 1.00 ca fait faire un certain stress :p

Pour ma part je trouve l'article de wikipédia plutôt bien : http://fr.wikipedia.org/wiki/Load_average

Il a l'avantage d'être court, simple et compréhensible.

Nous avons été un peu catégorique sur cet indicateur mais il peut avoir un intérêt : alerter l'utilisateur pour qu'il soit vigilant mais globalement la conclusion de l'article de Wikipédia résume bien la situation :

→ Pour améliorer les performances: examiner le taux d'utilisation global du processeur. Minimiser si possible les I/O

Donc pourquoi perdre son temps avec cet indicateur quand il suffit de regarder directement les "bons" indicateurs (je le mets entre guillemets car il n'y a pas de bons ou mauvais indicateurs mais il y en a qui sont plus utiles, pertinents et rapides à interpréter).

En plus avec les processeurs multi-cores d'aujourd'hui, ça perd encore plus d'intérêt.

Si on ajoute à ça que des changements de code de pilotes du noyau peuvent aussi influer.... ça devient compliqué.

[EDIT]
Si l'objectif est la supervision de serveurs, il n'y a pas 36 000 indicateurs à suivre. Pour ma part, les plus structurants sont :
- Consommation CPU (qu'elle soit de type user, système, wa).
- Mémoire (pas de saturation et/ou d'activité de swap).
- Suivre un indicateur lié à l'activité des utilisateurs (temps de réponse de pages webs, requêtes sql, nombre de hits/s, etc.).

L'avantage de ce dernier indicateur, c'est qu'il permettra d'alerter sur tous les problèmes systèmes ou d'infrastructures sous-jacents, s'il est bien choisi

Et puis les indicateurs c'est bien, mais il faut savoir les interpréter. Je vais donc prendre un exemple typique où en général tout le monde s'affole alors qu'en fait le système travaille tout simplement comme il faut :

Imaginons une application qui a un serveur d'application et un serveur SQL sur la même machine physique.
On regarde l'activité système du serveur et on observe que la CPU est très très élevée, à la limite de la saturation, disons 85 points de CPU des ressources totales sur 100.
Avec plus de détail on voit que 90% du temps CPU consommé est de type wait IO et le reste principalement du user avec un peu de système.
Tout de suite c'est l'alerte, problème de performance disques, baies, san, réseau (bah oui, ça retombe toujours sur le réseau quand on trouve pas ).
En fait, en regardant de plus près l'activité de la base de données, on observe qu'elle remonte de très grande quantité de données. C'est l'usage et le type de données qui veut ça. Et au final le temps CPU réellement consommé est très faible.
Mieux, on fait tourner de très violents calculs à côté et on ne sature pas la CPU, elle est juste de type différente et cela n'affecte que très faiblement l'activité de l'application.
En conclusion, cette CPU élevée de type wait IO est principalement dû au fait que les disques durs vont plus lentement que les CPUs (ah bon ? ) Et donc si le traitement des données est plus rapide que la récupération des données en tant que tel, alors on a ce type de comportement, car le CPU fait son calcul et dit, j'attends les données suivantes pour travailler et se met en wait.

Tout ça pour dire qu'il est autant important de connaître l'activité technique que fonctionnelle, car d'un point de vue technique le comportement du serveur était aberrant mais du point de vue fonctionnel il est logique et attendu. Souvent les pires dans ces cas là sont les DBAs qui veulent faire des optimisations sans comprendre le fonctionnement des applications (petit message à mes amis DBA

)

xkomodor · Post by **xkomodor** » Thu Jul 12, 2012 9:31 pm

Salut,

Merci DuF pour ton retour et ton explication.

Effectivement j'y vois maintenant plus clair sur cette notion.

Je vous remercie tous de l'attention que vous avez pu apporter à mon post.

XKomodor | Julien

DuF · Post by **DuF** » Thu Jul 12, 2012 9:36 pm

Désolé j'ai éditer mon message pendant que tu postais le tiens, j'aurais du le mettre après pour plus de clarté.

xkomodor · Post by **xkomodor** » Fri Jul 13, 2012 8:34 am

Salut,

Ne soit pas désolé, c'est une mine d'information et avec exemple à l'appuie.

Merci pour ton retour et du temps passé aux explications que tu avais sans doute déjà développées tantôt !

Je vais avec ces pistes de recherche tenter d'affiner un peu plus mon "monitoring" et surtout une meilleure compréhension de ce qui se passe "sous le capot".

XKomodor | Julien

kwenspc · Post by **kwenspc** » Fri Jul 13, 2012 11:35 am

guilc wrote: un git bisect tu veux dire plutot
(...)
Quand tu en seras à quelques centaines de bissections, je penses que tu lâcheras l'affaire

ah oui git bisect... m'arrive d'en faire pourtant

Si le comportement se retrouve dans une vm, ça pourrait être faisable mais oui, bonjour les itérations...

El_Goretto · Post by **El_Goretto** » Mon Jul 16, 2012 11:20 am

Tiens, je ne sais pas si ce fix est en rapport avec le sujet du thread, mais on dirait que dans le 3.5 à venir, il y ait des corrections sur le calcul du load.
https://lwn.net/Articles/506819/ :
Rewrite and fix load-avg computation

DuF · Post by **DuF** » Wed Jul 18, 2012 5:24 pm

El_Goretto wrote:Tiens, je ne sais pas si ce fix est en rapport avec le sujet du thread, mais on dirait que dans le 3.5 à venir, il y ait des corrections sur le calcul du load.
https://lwn.net/Articles/506819/ :
Rewrite and fix load-avg computation

Effectivement et j'aurai tendance à penser que ce calcul est basé sur des choses qui bougent un peu trop d'un système à l'autre (a priori, j'avoue que j'ai lu en diagonale, là ils vont prendre en compte les évolutions liées aux schedulers) pour être pérenne (histoire d'être cohérent avec ce qui a déjà été dit plus haut

)

El_Goretto · Post by **El_Goretto** » Tue Oct 02, 2012 11:21 am

Ce n'est pas tout à fait les mêmes symptômes, mais il y a quelque chose qui me chagrine, sur ma machine hardened en kernel 3.4 et 3.5 (je ne sais pas si c'était le cas avant ou pas): le total de %CPU "normal" rapporté par top et htop (en haut de l'affichage) n'est pas égal au total des %CPU des tâches (chaque ligne). Et je ne parle pas de la blague du nombre de cores/machine égale à 100% ou plus, non, là, j'ai une compilation noyau avec make -j2 sur un dual core:
j'ai les 2 cores chacun à 90% de charge CPU "normale/user" (pas de nice, pas de IOWAIT, pas de etc etc...), mais les process de compilation ne référencent parfois que 20% en additionnant les % des threads cc1.

Pourtant j'ai bien un utilisateurs pouvant voir normalement tous les process/thread, et comme je le disais, il n'y a pas de charge CPU "système", que du "normal" / "user".

Vous avez observé la même chose? Ce serait dû à une spécificité du patchset hardened?

DuF · Post by **DuF** » Tue Oct 02, 2012 11:48 am

El_Goretto wrote:Ce n'est pas tout à fait les mêmes symptômes, mais il y a quelque chose qui me chagrine, sur ma machine hardened en kernel 3.4 et 3.5 (je ne sais pas si c'était le cas avant ou pas): le total de %CPU "normal" rapporté par top et htop (en haut de l'affichage) n'est pas égal au total des %CPU des tâches (chaque ligne). Et je ne parle pas de la blague du nombre de cores/machine égale à 100% ou plus, non, là, j'ai une compilation noyau avec make -j2 sur un dual core:
j'ai les 2 cores chacun à 90% de charge CPU "normale/user" (pas de nice, pas de IOWAIT, pas de etc etc...), mais les process de compilation ne référencent parfois que 20% en additionnant les % des threads cc1.

Pourtant j'ai bien un utilisateurs pouvant voir normalement tous les process/thread, et comme je le disais, il n'y a pas de charge CPU "système", que du "normal" / "user".

Vous avez observé la même chose? Ce serait dû à une spécificité du patchset hardened?

Bonjour El_Goretto,

Le sujet étant intéressant, on peut peut être ouvrir un nouveau fil de discussion ?

Sinon pour ton point et en regardant vite fait top et htop je dirai que :
- les valeurs globales devraient être identiques à ce que sort une comande vmstat par exemple.
- les valeurs listées par process/threads peuvent dépasser 100% pour la cpu (si un process prend 2*75% sur 2 cores)
- les valeurs listées par process/threads, j'aurai tendance à penser que la cpu affichée se limite à de la pure CPU user

Après il faudrait regarder le code de top/htop/vmstat/mpstat... pour voir sur quels appels ils se basent pour récupérer ces valeurs. En plus en ce moment ça bouge beaucoup du côté de perf, donc pour le suivi des process/threads il doit y avoir moyen de faire des choses sympas.

Par exemple suivre le comportement de top/htop avec mpstat -A 2 .

[Kernel] Comportement du 3.3.8 en overload [RESOLU]

[Kernel] Comportement du 3.3.8 en overload [RESOLU]

Re: [Kernel] Comportement du 3.8.8 en overload

Re: [Kernel] Comportement du 3.8.8 en overload

[top] charge %CPU incohérente

Re: [top] charge %CPU incohérente