View previous topic :: View next topic |
Author |
Message |
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Tue Oct 02, 2012 1:22 pm Post subject: [top] charge %CPU incohérente [résolu] |
|
|
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. _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)
Last edited by El_Goretto on Thu Oct 04, 2012 1:15 pm; edited 1 time in total |
|
Back to top |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Tue Oct 02, 2012 4:34 pm Post subject: |
|
|
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 |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Tue Oct 02, 2012 8:55 pm Post subject: Re: [top] charge %CPU incohérente |
|
|
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 |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Tue Oct 02, 2012 10:23 pm Post subject: Re: [top] charge %CPU incohérente |
|
|
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 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 |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Wed Oct 03, 2012 10:14 am Post subject: |
|
|
@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...) _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Wed Oct 03, 2012 11:01 am Post subject: |
|
|
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 |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Thu Oct 04, 2012 1:15 pm Post subject: |
|
|
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 _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Thu Oct 04, 2012 3:52 pm Post subject: |
|
|
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' ?
man atop :
Code: |
p Show the process activity accumulated per program (i.e. process name).
|
|
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Thu Oct 04, 2012 10:26 pm Post subject: |
|
|
@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. _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Fri Oct 05, 2012 6:33 am Post subject: |
|
|
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 |
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Fri Oct 05, 2012 8:35 am Post subject: |
|
|
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). _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
scherz0 Apprentice
Joined: 02 Oct 2008 Posts: 154
|
Posted: Fri Oct 05, 2012 10:04 am Post subject: |
|
|
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 |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8706 Location: ~Brussels - Belgique
|
Posted: Fri Oct 05, 2012 10:15 am Post subject: |
|
|
On se calme les pt'its loups, et on prend une petite camomille _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Sat Oct 06, 2012 10:42 am Post subject: |
|
|
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
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 |
|
|
|
|
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
|
|