Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[top] charge %CPU incohérente [résolu]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index French
View previous topic :: View next topic  
Author Message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2874
Location: Paris

PostPosted: Tue Oct 02, 2012 1:22 pm    Post subject: [top] charge %CPU incohérente [résolu] Reply with quote

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

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


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

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.
_________________
-PC: 2500K/P8Z68V, 8Go, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC ; NF9D-2700, 4Go ; DS61, i3 2100T, 16Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RN312
http://boycottsystemd.org/


Last edited by El_Goretto on Thu Oct 04, 2012 1:15 pm; edited 1 time in total
Back to top
View user's profile Send private message
DuF
Advocate
Advocate


Joined: 09 Dec 2002
Posts: 2647
Location: Paris

PostPosted: Tue Oct 02, 2012 4:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
scherz0
Apprentice
Apprentice


Joined: 02 Oct 2008
Posts: 154

PostPosted: Tue Oct 02, 2012 8:55 pm    Post subject: Re: [top] charge %CPU incohérente Reply with quote

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.
Back to top
View user's profile Send private message
DuF
Advocate
Advocate


Joined: 09 Dec 2002
Posts: 2647
Location: Paris

PostPosted: Tue Oct 02, 2012 10:23 pm    Post subject: Re: [top] charge %CPU incohérente Reply with quote

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 :P 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 :
Code:
  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       


Code:
  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.
Back to top
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2874
Location: Paris

PostPosted: Wed Oct 03, 2012 10:14 am    Post subject: Reply with quote

@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...)
_________________
-PC: 2500K/P8Z68V, 8Go, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC ; NF9D-2700, 4Go ; DS61, i3 2100T, 16Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RN312
http://boycottsystemd.org/
Back to top
View user's profile Send private message
scherz0
Apprentice
Apprentice


Joined: 02 Oct 2008
Posts: 154

PostPosted: Wed Oct 03, 2012 11:01 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2874
Location: Paris

PostPosted: Thu Oct 04, 2012 1:15 pm    Post subject: Reply with quote

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

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

Code:
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:
Code:
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 ;)
_________________
-PC: 2500K/P8Z68V, 8Go, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC ; NF9D-2700, 4Go ; DS61, i3 2100T, 16Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RN312
http://boycottsystemd.org/
Back to top
View user's profile Send private message
scherz0
Apprentice
Apprentice


Joined: 02 Oct 2008
Posts: 154

PostPosted: Thu Oct 04, 2012 3:52 pm    Post subject: Reply with quote

El_Goretto wrote:

Ceci dit, atop n'est pas non plus parfait pour les mesures:
[...]
Je pète les plafonds de mes 2 cores ;)

Hem... Aurais-tu appuyé sur la touche 'p' ? :wink:
man atop :
Code:

       p    Show the process activity accumulated per program (i.e. process name).
Back to top
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2874
Location: Paris

PostPosted: Thu Oct 04, 2012 10:26 pm    Post subject: Reply with quote

@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.
_________________
-PC: 2500K/P8Z68V, 8Go, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC ; NF9D-2700, 4Go ; DS61, i3 2100T, 16Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RN312
http://boycottsystemd.org/
Back to top
View user's profile Send private message
scherz0
Apprentice
Apprentice


Joined: 02 Oct 2008
Posts: 154

PostPosted: Fri Oct 05, 2012 6:33 am    Post subject: Reply with quote

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'affichage
  • La durée de vie du processus
  • Le 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 ;-). 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:
Back to top
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2874
Location: Paris

PostPosted: Fri Oct 05, 2012 8:35 am    Post subject: Reply with quote

scherz0 wrote:
[...]


8O
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).
_________________
-PC: 2500K/P8Z68V, 8Go, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC ; NF9D-2700, 4Go ; DS61, i3 2100T, 16Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RN312
http://boycottsystemd.org/
Back to top
View user's profile Send private message
scherz0
Apprentice
Apprentice


Joined: 02 Oct 2008
Posts: 154

PostPosted: Fri Oct 05, 2012 10:04 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
XavierMiller
Moderator
Moderator


Joined: 23 Jul 2004
Posts: 5536
Location: ~Brussels - Belgique

PostPosted: Fri Oct 05, 2012 10:15 am    Post subject: Reply with quote

On se calme les pt'its loups, et on prend une petite camomille ;)
_________________
Xavier Miller
(FR) Merci de respecter les règles du forum.
http://www.xaviermiller.be
Back to top
View user's profile Send private message
DuF
Advocate
Advocate


Joined: 09 Dec 2002
Posts: 2647
Location: Paris

PostPosted: Sat Oct 06, 2012 10:42 am    Post subject: Reply with quote

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


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').
When the kernel patch `cnt' has been installed or "storage accounting" is active, the accumulated read- and write throughput on disk is shown. When the kernel patch `cnt' has been installed, the num‐
ber of received and sent network packets are shown.
The last columns contain the accumulated occupation percentage for the chosen resource (default: cpu) and the program name.

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 :
Code:
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 :
Code:
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index French All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum