[Système] Souci avec /proc/stat (résolu)

[badbeat]

Bonjour,
Je suis en train de coder un petit monitoring CPU en ruby, via /proc/stat
http://pastie.org/2325310

Le calcul semble bon et correspond ~ à mpstat.

Code : Tout sélectionner

Linux 2.6.39-ARCH (scratchy) 	05/08/2011 	_x86_64_	(8 CPU)

07:03:59     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
07:03:59       1    6,55    0,00    0,77    0,07    0,00    0,01    0,00    0,00   92,61

Mon souci est que il n'y a rien qui tourne sur ce coeur. (j'avais lancer une appli qui consomme 40% hier soir) (les coeurs 1 à 7 sont isolés du kernel et de toute nouvelle application lancée)
Quand je lance un top, le coeur 1 est à ~6% puis au refresh repasse à 0%, mais mpstat et mon code eux restent à ~6%

J'ai beau chercher je ne comprend pas trop d'où sort ce 6%. J'ai l'impression qu'il y a une sorte de cache, mais je ne trouve rien à ce sujet

[Desintegr]

Bienvenue sur le forum.
Pense à formater ton post comme indiqué sur ce topic : http://forums.archlinux.fr/topic68.html

Que renvoie :

Code : Tout sélectionner

ps -e -o comm,%cpu,psr --sort -%cpu | head -n20

quand le cœur 1 tourne à ~6%

[badbeat]

voilà ce que retourne ps:

Code : Tout sélectionner

COMMAND         %CPU PSR
sshd             0.2   0
sshd             0.0   0
sshd             0.0   0
sync_supers      0.0   0
sshd             0.0   0
/usr/sbin/munin  0.0   0
sshd             0.0   0
flush-8:0        0.0   0
kswapd0          0.0   0

le coeur 1 est toujours à ~6%

[Desintegr]

En fait, petite erreur de ma part, ps n'affiche pas l'information que je voulais.

Lance un top, affiche les informations des CPU avec 1, puis le dernier CPU utilisé avec f suivi de j puis Entrer.
Prend ensuite une capture quand le cœur 1 est à 6%.

Ou bien créé un fichier ~/.toprc avec ce contenu :

Code : Tout sélectionner

RCfile for "top with windows"           # shameless braggin'
Id:a, Mode_altscr=0, Mode_irixps=1, Delay_time=3.000, Curwin=0
Def     fieldscur=AEHIOQTWKNMbcdfgJplrsuvyzX
        winflags=30009, sortindx=10, maxtasks=0
        summclr=1, msgsclr=1, headclr=3, taskclr=1
Job     fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX
        winflags=62777, sortindx=0, maxtasks=0
        summclr=6, msgsclr=6, headclr=7, taskclr=6
Mem     fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX
        winflags=62777, sortindx=13, maxtasks=0
        summclr=5, msgsclr=5, headclr=4, taskclr=5
Usr     fieldscur=ABDECGfhijlopqrstuvyzMKNWX
        winflags=62777, sortindx=4, maxtasks=0
        summclr=3, msgsclr=3, headclr=2, taskclr=3

[badbeat]

top normal: http://dc.foohey.me/stuff/screen.jpg
top avec le coeur 1 à 6%: http://dc.foohey.me/stuff/screen2.jpg
top avec le coeur 1 à 0%: http://dc.foohey.me/stuff/screen3.jpg

[Desintegr]

Il s'agit peut-être du processus munin-update.

Essaye de recommencer les captures avec la même configuration en affichant les threads en plus, touche H (en majuscule).

[badbeat]

le munin-update n'a rien à voir, il est lancé sur le core 0, comme je l'ai dit plus haut les cores 1 à 7 sont isolés

J'avais le coeur 2 à 0.0%, je viens de lancer un "taskset -c 2 top", maintenant il bloque à 0.1% et dans le top il passe de 0.1 à 0.0 au refresh

J'ai configurer un kernel très épuré, une option processeur pourrait-elle donner des effets indésirables sur les stats?
J'ai également le USER_HZ (asm/param.h) à 1000

[Desintegr]

Tu peux également voir sur quel processeur sont exécutés les threads de l'ensemble des processus avec :

Code : Tout sélectionner

ps -em -o comm,psr

Mais comme le noyau est SMP, tout risque de changer à chaque instant.
Mais tu dis que ton système est cloisonné au niveau de l'utilisation des processeurs, ça donnera peut-être une idée.

[badbeat]

Code : Tout sélectionner

ps -em -o comm,psr

http://pastie.org/2325756

edit: le % du coeur 1 baisse tout doucement, il est à ~5% et toujours aucune appli de lancée dessus.

/proc/stat
kernel/system statistics. Varies with architecture. Common entries include:

cpu 3357 0 4313 1362393
The amount of time, measured in units of USER_HZ (1/100ths of a second on most architectures, use sysconf(_SC_CLK_TCK) to obtain the right value), that the system spent in user mode, user mode with low priority
(nice), system mode, and the idle task, respectively. The last value should be USER_HZ times the second entry in the uptime pseudo-file.

donc si j'ai bien compris, il fait diviser les valeurs user,nice,system et idle par le USER_HZ ?

[Desintegr]

Sur le log du ps, il n'y a rien qui tourne sur le cœur 1. Bref, c'est difficile à expliquer.

[badbeat]

ce qui m'énerve c'est top qui affiche la même valeur que mpstat et mon code, puis au refresh il donne la vraie valeur, CAD 0%

je man, je google...

Edit: J'ai activé SMT (Hyperthreading) scheduler (CONFIG_SCHED_SMT) dans le kernel.

les valeurs renvoyées par mpstat et /proc/stat sont moins "statiques". je veut dire par là qu'il y a une certaine latence avant que le core retombe à 0% sur mpstat et mon code, tandis que top affiche bien 0%

[badbeat]

Bon ça semble tenir la route avec le SMT activé.

Si quelqun qui passe par là et pourrait tester si après une grosse charge CPU la valeur de mpstat (paquet sysstat) ou/et de mon script baisse immédiatement ou non (par rapport à top) car je ne sait pas du tout si c'est normal, ou pas.

edit(...):
j'ai une appli au taquet, un top et ps retourne

Cpu1 : 44.9%us, 0.9%sy, 0.0%ni, 54.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

un mpstat et mon code:

14:59:20 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
14:59:20 1 12,95 0,00 0,85 0,32 0,00 0,01 0,00 0,00 85,88

qui croire ?

Encore un edit:
En fait c'est pareil... sauf que /proc/stat met énormément de temps à se mettre à jour que ça soit en montée ou en descente, il lui faut 10min pour <>1% !!!!!!!!
j'vais tester avec un kernel tout lourd voir si ça vient de ma config

[Desintegr]

Le noyau de base sous Arch n'est pas si lourd que ça, 2 Mo de base et globalement pareil pour l'initramfs (selon les modules autodétectés), c'est rien pour les machines actuelles.
De plus, il est plutôt bien configuré, la plupart des options sont compilées en modules et chargées uniquement si on en a besoin.

Souvent, à vouloir trop optimiser, on oublie de configurer telle ou telle option et on obtiens au final l'inverse que l'on recherche.

[badbeat]

En fait le problème n'est pas
J'avais oublier l'intervalle, du coup ça marche mieux