# [top] charge %CPU incohérente [résolu]

## El_Goretto

Vilain moi, comme l'a fait remarquer DuF, je crée un thread dédié.

Post initial:

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

 

Réponse de DuF:

 *DuF wrote:*   

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

 

Je suis d'accord avec tes 2 derniers points, je me suis mal exprimé (je parlais de blague avec les nombres de cores/machine, et j'ai bien précisé que je regardais la partie "user").

Pour le premier point, tu as raison, je vais tâcher de recouper les infos avec vmstat et dstat.

Je prend note et je regarde.

----------

## DuF

Je viens rapidement de comparer htop et mpstat -P ALL 2 et j'ai pas vu de différence flagrante à faible charge. Mais comme ma machine manquait d'activité peut-être que tes observations sont liées à une activité plus importante sur la machine.

----------

## scherz0

 *Quote:*   

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

 

Ça me parait difficilement comparable : si la durée moyenne d'une tàche est inférieure à l'intervalle entre deux affichages, à la fin de l'intervalle tu n'observes dans la liste qu'une partie des tàches qui ont contribué au calcul du %CPU durant cet intervalle.

Si make -j 2 lance une dizaine de processus par seconde, et que l'intervalle de mise à jour de top est une seconde, 4/5 des processus dérmarrent et se terminent entre deux affichages : ils ne sont jamais listés.

----------

## DuF

 *scherz0 wrote:*   

> Ça me parait difficilement comparable : si la durée moyenne d'une tàche est inférieure à l'intervalle entre deux affichages, à la fin de l'intervalle tu n'observes dans la liste qu'une partie des tàches qui ont contribué au calcul du %CPU durant cet intervalle.
> 
> Si make -j 2 lance une dizaine de processus par seconde, et que l'intervalle de mise à jour de top est une seconde, 4/5 des processus dérmarrent et se terminent entre deux affichages : ils ne sont jamais listés.

 

C'est un point très intéressant. 

J'ai regardé le man top pour voir s'il avait un moyen de forcer l'affichage de tous les éléments qui ont consommés pendant l'intervalle même s'ils ne sont plus là au moment du rafraîchissement. Pour l'instant je n'ai pas trouvé, en même temps cela ne semble pas super utile.

Sinon on peut raccourcir le délai de rafraîchissement, mais personnellement un top -d 00.10 me demande des yeux bioniques que je n'ai pas   :Razz:  Par contre ça peut être utile pour tracer et agréger dans un fichier des données et permettre d'analyser le comportement, mais la quantité de données peut très/trop vite monter.

Je viens de faire un test avec top -d 00.10 puis un top rafraîchit par défaut :  

```
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                         

23888 root      20   0  169m 135m 3976 R  105  3.6   0:01.46 cc1plus                                                                                                                                                                         

23905 root      20   0 93024  57m 3904 R  105  1.5   0:00.51 cc1plus                                                                                                                                                                         

23860 root      20   0  208m 178m 7356 R   96  4.7   0:01.59 cc1plus                                                                                                                                                                         

23871 root      20   0  240m 210m 7164 R   96  5.5   0:01.57 cc1plus                                                                                                                                                                         

23922 root      20   0 43256  14m 2976 R   35  0.4   0:00.04 cc1plus       
```

```
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                         

26542 root      20   0  337m 308m 7472 R   99  8.1   0:03.05 cc1plus                                                                                                                                                                         

26559 root      20   0  326m 298m 7152 R   93  7.9   0:02.80 cc1plus                                                                                                                                                                         

26576 root      20   0  152m 121m 3972 R   33  3.2   0:00.99 cc1plus                                                                                                                                                                         

26593 root      20   0 61780  32m 2976 R   18  0.9   0:00.53 cc1plus                                                                                                                                                                         

26610 root      20   0 59112  30m 2976 R   10  0.8   0:00.31 cc1plus               
```

J'ai répété l'opération pour vérifier l'ordre de grandeur et globalement ça s'observe facilement.

On voit bien qu'avec un écart de temps court la CPU mesurée "parait" plus élevée. Il n'en est rien de l'activité qui est la même, mais si sur une heure je trace une courbe avec les points du top rapide je serai aux alentours de 87 là où la même courbe avec un rafraîchissement plus faible donnera 50.

Je pense que cela explique l'impression dont parle El_Goretto quand il fait un top.

----------

## El_Goretto

@scherz0: je vais valider l'hypothèse des process trop courts pour être correctement affichés avec atop en mode agrégation. Il me manque une fonctionnalité d'accounting dans la quenelle, du coup ça va retarder mes tests. (c'est dingue si c'est çà, de penser que maintenant les process de compilation kernel sont trop "rapides" pour être mesurés à l'ancienne...)

----------

## scherz0

 *El_Goretto wrote:*   

> @scherz0: je vais valider l'hypothèse des process trop courts pour être correctement affichés avec atop en mode agrégation. Il me manque une fonctionnalité d'accounting dans la quenelle, du coup ça va retarder mes tests. (c'est dingue si c'est çà, de penser que maintenant les process de compilation kernel sont trop "rapides" pour être mesurés à l'ancienne...)

 

Attention, je parlais de top et ses dérivés que tu avais mentionnés dans le message original.

Ça ne concerne pas atop qui peut exploiter le mécanisme d'accounting, à condition que soit activé dans le noyau (BSD_PROCESS_ACCT=y).

----------

## El_Goretto

 *scherz0 wrote:*   

>  *El_Goretto wrote:*   @scherz0: je vais valider l'hypothèse des process trop courts pour être correctement affichés, avec atop en mode agrégation.  
> 
> Attention, je parlais de top et ses dérivés que tu avais mentionnés dans le message original.
> 
> Ça ne concerne pas atop qui peut exploiter le mécanisme d'accounting

 

Mais on est d'accord, je rajoute la virgule qui manquait ci-dessus  :Smile: 

Donc oui, c'est confirmé par atop, en fait ça compile trop vite en fait... mince, je vieillis...

```
CPU | sys      14% |  user    182% | irq       1% |  idle      1% | wait      1% |  guest     0% 

NPROCS     SYSCPU      USRCPU      VSIZE     SWAPSZ      RSIZE     RDDSK      WRDSK     RNET     SNET      CPU     CMD        1/3

   130      3.41s      67.77s     111.2M         0K     46196K       60K         0K        ?        ?     180%     cc1

     1      0.48s       3.53s       1.9G         0K     454.9M        4K       240K        ?        ?      10%     java

   130      0.38s       1.06s     67664K         0K     12000K        0K         0K        ?        ?       4%     as

   128      0.49s       0.59s         0K         0K         0K        0K         0K        ?        ?       3%     fixdep

   150      0.37s       0.50s     99496K         0K      3336K        0K         0K        ?        ?       2%     sh

   130      0.15s       0.30s     44596K         0K      1492K        0K         0K        ?        ?       1%     gcc

   128      0.07s       0.16s         0K         0K         0K        0K         0K        ?        ?       1%     mv

    12      0.01s       0.17s     146.3M         0K      4092K     3356K      8792K        ?        ?       0%     make

   129      0.06s       0.05s         0K         0K         0K        0K         0K        ?        ?       0%     rm
```

--

edit:

Ceci dit, atop n'est pas non plus parfait pour les mesures:

```
NPROCS     SYSCPU      USRCPU      VSIZE     SWAPSZ      RSIZE     RDDSK      WRDSK     RNET     SNET      CPU     CMD        1/1

     8      0.34s       4.82s     108.3M         0K     39048K        8K         0K        ?        ?     200%     cc1

     1      0.02s       0.20s       1.9G         0K     455.9M        0K        64K        ?        ?      10%     java

     6      0.04s       0.02s         0K         0K         0K        0K         0K        ?        ?       3%     fixdep

     8      0.00s       0.05s     69476K         0K     11420K        0K         0K        ?        ?       2%     as

     1      0.03s       0.02s     78264K         0K      8580K        0K         0K        ?        ?       2%     atop

     8      0.03s       0.02s     118.1M         0K      3336K        0K         0K        ?        ?       2%     sh

     2      0.00s       0.01s     41440K         0K      2692K      144K       436K        ?        ?       0%     make
```

Je pète les plafonds de mes 2 cores  :Wink: 

----------

## scherz0

 *El_Goretto wrote:*   

> 
> 
> Ceci dit, atop n'est pas non plus parfait pour les mesures:
> 
> [...]
> ...

 

Hem... Aurais-tu appuyé sur la touche 'p' ?   :Wink: 

man atop :

```

       p    Show the process activity accumulated per program (i.e. process name).

```

----------

## El_Goretto

@scherz0: et ben oui, c'était le but depuis le début ("aggrégé"). N'expliquant pas le fait de dépasser 100% x nb core.

----------

## scherz0

 *El_Goretto wrote:*   

> @scherz0: et ben oui, c'était le but depuis le début ("aggrégé"). N'expliquant pas le fait de dépasser 100% x nb core.

 

Si, c'est logique.  À condition de ne pas chercher à additionner des choses qui ne peuvent pas l'être (le pourcentage est une fraction, pas une quantité.)

Pour calculer un pourcentage CPU, il faut diviser le temps CPU par une durée de référence. La durée de référence peut-être :

L'intervalle d'affichageLa durée de vie du processusLe temps du système (uptime)...

Le choix de cette durée de référence dépend de ce qu'on veut mesurer. Dans le cas de top, c'est l'intervalle d'affichage : il est le même pour toutes les processus de la liste, tu peux les additionner  :Wink: .  Mais c'est peu utile, comme expliqué dans un message précédent.

Dans le cas de atop, je pense qu'il s'agit du temps d'exécution du processus. Dans ta liste, le %CPU de chaque programme est exprimé par rapport une valeur de référence qui lui est propre, donc aucune arithmétique possible sur ces %CPU.  Si tu veux vraiment faire des addtitions, la somme des (SYSCPU+USRCPU) ne doit pas dépasser nbcore * uptime   :Wink: 

----------

## El_Goretto

 *scherz0 wrote:*   

>  [...] 

 

 :Shocked: 

Loin de moi l'idée de vouloir être désobligeant, mais évitons de poster du texte sans apport d'information :/

L'observation (de l'edit) sur atop indique un problème avec l'outil de mesure, et un % CPU (se basant sur le temps de mesure, évidemment) est une quantité relativement triviale. Donc réussir à dépasser le temps total de la mesure en additionnant toutes les fractions de temps n'a pas de raison de se produire quand l'intervalle de mesure est suffisamment grand pour éviter les erreur d'arrondi (ici, 5-6 secondes).

----------

## scherz0

 *Quote:*   

> Loin de moi l'idée de vouloir être désobligeant, mais évitons de poster du texte sans apport d'information :/

 

Inutile d'être désobligeant, j'ai apporté de l'information en t'expliquant comment les calculs que tu fais sont erronées.  Si tu la rejettes parce c'est exprimé avec un peu d'ironie et que ça bouscules tes certitudes, soit.  Sinon, je reste disposé à aider.

----------

## xaviermiller

On se calme les pt'its loups, et on prend une petite camomille  :Wink: 

----------

## DuF

 *scherz0 wrote:*   

> Dans le cas de atop, je pense qu'il s'agit du temps d'exécution du processus.Dans ta liste, le %CPU de chaque programme est exprimé par rapport une valeur de référence qui lui est propre, donc aucune arithmétique possible sur ces %CPU. Si tu veux vraiment faire des addtitions, la somme des (SYSCPU+USRCPU) ne doit pas dépasser nbcore * uptime  

 

Vu que le sujet me chatouille et que je préfère les choses certaines aux incertitudes j'aimerai bien comprendre le fonctionnement de atop sur ce point, comme El_Goretto me semble-t-il   :Wink: 

Je vais exprimer ma compréhension de la sortie de atop puis mon avis et je compte sur vos connaissances pour qu'on arrive à quelque chose de réellement précis. Je précise dès le départ que je risque de grossir, exagérer certaines idées mais ce sera dans le seul but d'éviter toute ambiguïté sur l'idée exprimée.

Si on part du principe que le %CPU de la section "OUTPUT DESCRIPTION - PROCESS LEVEL" (pour reprendre le nommage de atop) est exprimée par rapport à une valeur qui lui est propre, on pourrait supposer que le moindre process qui plafonne la CPU à 100% apparaîtrait => absence d'intérêt total d'un tel comportement vu que des process à exécution très courte mais prenant 100% de cpu apparait en nombre dans l'intervalle de temps d'affichage.

Maintenant le man de atop dit pour cette colonne : 

 *Quote:*   

> The occupation percentage of this process related to the available capacity for this resource on system level.

 

On peut en déduire qu'il s'agit de ce qui est consommé par rapport à ce qui est disponible et qu'il ne semble pas y avoir de notion de référence propre. C'est ennuyeux, personnellement j'aurai bien aimé une précision comme quoi la valeur est le consommé par rapport à ce qui est disponible ramené à l'intervalle d'affichage des valeurs.

Maintenant si on ajoute le fonctionnement par cumul de l'activité trié par le nom de processus :

 *Quote:*   

> Show the process activity accumulated per program (i.e. process name).
> 
> Per program the following fields are shown: number of processes active or terminated during last interval (or in total if combined with command `a'), accumulated cpu consumption during last interval in
> 
>             system- and user mode, the current virtual and resident memory space consumed by active processes (or all processes of the user if combined with command `a').
> ...

 

Donc là il est bien question de processus actif et terminé pendant le précédent intervalle ainsi que du cumul de la CPU consommée sur le dernier intervalle en mode système et utilisateur. 

Dis comme ça, on comprend bien que la première colonne 'NBPROCS' correspond au nombre de processus actif et terminé et que les colonnes 'SYSCPU' et 'USRCPU' correspondent à la consommation CPU système et utilisateur exprimée en secondes.

Il est dit aussi que le %CPU est l'expression du pourcentage d'occupation cumulée triée par nom de programme.

Logiquement, en connaissant la durée sur laquelle est mesurée l'ensemble des valeurs, le recoupement des valeurs de temps en les additionnant ne devrait pas dépasser l'intervalle de temps de mesure et ce devrait être la même chose pour le %CPU.

Par exemple, si j'ai 8 cores et que mon intervalle de temps de rafraîchissement de mes données est de 10s pour atop, alors le maximum de mon système me donne droit à 80s de ressources consommées et 800% de CPU disponible. D'ailleurs attention, en utilisant la touche 'z' pour mettre en pause, le prochain calcul sera basé sur l'intervalle totale pause incluse donc ça sera plus compliquée de déterminer les valeurs de références. En prenant donc ces éléments, on peut aussi faire un calcul simple, exemple : 

```
NPROCS               SYSCPU                USRCPU               VSIZE               SWAPSZ                RSIZE               RDDSK                WRDSK               RNET              SNET                CPU               CMD

    38                2.54s                45.68s              782.2M                   0K               651.9M                   ?                    ?                  ?                 ?               483%               cc1plus

```

En additionnant 2.54+45.68 on obtient 48.22 soit les 483% affichés plus loin.

En compilant libreoffice, j'ai constaté précisément ce comportement :

- pour les temps SYSCPU et USRCPU de chaque processus et si je les additionne je retombe bien sur les valeurs globales au centième de secondes près

- mais le %CPU diverge toujours un peu (pas forcément beaucoup), souvent par le haut, et il peut aussi dépasser les 800% de CPU pour un programme ce que ne fais jamais la section globale.

- J'aurai tendance à penser que ce %CPU fait un arrondi.

- l'intervalle de référence utilisé est bien le rafraîchissement de atop, si on modifie cette valeur en passant par exemple à 15s, j'obtiens bien 120s de temps CPU par intervalle (le % lui reste sur 800%).

Par contre je ne m'explique pas le dépassement des 800% par un seul programme :

```
NPROCS            SYSCPU             USRCPU            VSIZE            SWAPSZ             RSIZE            RDDSK             WRDSK            RNET           SNET             CPU            CMD

   113             2.35s             81.61s           667.0M                0K            398.2M                ?                 ?               ?             ?           800%           cc1plus

NPROCS           SYSCPU             USRCPU            VSIZE            SWAPSZ             RSIZE            RDDSK             WRDSK            RNET           SNET             CPU            CMD

    66             3.64s             80.84s           781.0M                0K            519.2M                ?                 ?               ?              ?            800%            cc1plus

```

A part pour des raisons de limites des ressources disponibles, de priorité de processus par rapport à d'autres, etc. et que cela puisse biaiser les valeurs mesurées devenant peu cohérentes.

----------

