# [Kernel] Comportement du 3.3.8 en overload [RESOLU]

## xkomodor

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/15/topics/16205#message-16214

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

Merci de vos retours et conseils éventuels.

XKomodor | JulienLast edited by xkomodor on Wed Jul 11, 2012 9:18 am; edited 2 times in total

----------

## El_Goretto

 *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à?  :Smile: 

 *xkomodor wrote:*   

> Merci de vos retours et conseils éventuels.

 

La drogue c'est mal, m'voyez?   :Twisted Evil: 

http://kernel.org/

----------

## xkomodor

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à? 
> ...

 

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

De "bonne guerre", j'ai corrigé   :Wink: 

Merci

XKomodor | Julien

----------

## guilc

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

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

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

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 :

```
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....

@+

----------

## guilc

 *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 :
> 
> ```
> ...

 

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   :Laughing: 

----------

## kwenspc

 *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....
> ...

 

Allez, un ptit git blame des familles les gens!

----------

## guilc

 *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....
> ...

 

un git bisect tu veux dire plutot  :Wink: 

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   :Laughing: 

----------

## Leander256

 *guilc wrote:*   

> 
> 
> un git bisect tu veux dire plutot 
> 
> Je te souhaites bien du courage, tu vas y passer du temps !
> ...

 

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

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 :pLast edited by xkomodor on Thu Jul 12, 2012 9:34 pm; edited 1 time in total

----------

## DuF

 *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 ?
> ...

 

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 :  *Quote:*   

> → 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  :Laughing: 

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 :

 *Quote:*   

> 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 ç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   :Wink:  )Last edited by DuF on Thu Jul 12, 2012 9:37 pm; edited 3 times in total

----------

## xkomodor

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

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

Salut,

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

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

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

 *guilc wrote:*   

> 
> 
> un git bisect tu veux dire plutot 
> 
> (...)
> ...

 

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

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

----------

## El_Goretto

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

 *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   :Laughing:  )

----------

## El_Goretto

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

 *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".
> ...

 

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 .

----------

