Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle
d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ?
En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite
en mode noyau, ce qui est assez embêtant pour une utilisation de linux
en firewall, par exemple.
La réponse se trouve peut-être dans le deuxième champ de la ligne cpu de
/proc/stat...
Une autre question me vient à l'esprit. Est ce que /proc/loadavg prend
en compte les threads noyau ?
Merci.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
esus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Manu a écrit : | Bonjour, | | Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle | d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ? | En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite | en mode noyau, ce qui est assez embêtant pour une utilisation de linux | en firewall, par exemple.
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à côté de la plaque.
Toutefois top et gtop (applet) fournissent cette distinction en CPU utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre programme en t'inspirant des sources de ces images.
- -- «Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?» Taliesin, barde gallois (V-VI siècles) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Manu a écrit :
| Bonjour,
|
| Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle
| d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ?
| En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite
| en mode noyau, ce qui est assez embêtant pour une utilisation de linux
| en firewall, par exemple.
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à
côté de la plaque.
Toutefois top et gtop (applet) fournissent cette distinction en CPU
utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre
programme en t'inspirant des sources de ces images.
- --
«Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?»
Taliesin, barde gallois (V-VI siècles)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Manu a écrit : | Bonjour, | | Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle | d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ? | En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite | en mode noyau, ce qui est assez embêtant pour une utilisation de linux | en firewall, par exemple.
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à côté de la plaque.
Toutefois top et gtop (applet) fournissent cette distinction en CPU utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre programme en t'inspirant des sources de ces images.
- -- «Quand tu dors, es-tu un corps, une âme ou un repaire de sensations?» Taliesin, barde gallois (V-VI siècles) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
esus wrote:
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à côté de la plaque.
C'est plus de la curiosité qu'un réel besoin.
Toutefois top et gtop (applet) fournissent cette distinction en CPU utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre programme en t'inspirant des sources de ces images.
J'avais jamais fait attention que 'top' affichait ce détail :| Effectivement il doit s'inspirer de /proc/stat car on retrouve execatement les mêmes champs. Pour le calcul, je suppose que 'top' fait la différence de chacun des champs toutes les n secondes et calcul les pourcentages en partant du principe que le total des différences représente 100%.
- Manu
PS: un strace confirme que top utilise /proc/stat.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
esus wrote:
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à
côté de la plaque.
C'est plus de la curiosité qu'un réel besoin.
Toutefois top et gtop (applet) fournissent cette distinction en CPU
utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre
programme en t'inspirant des sources de ces images.
J'avais jamais fait attention que 'top' affichait ce détail :|
Effectivement il doit s'inspirer de /proc/stat car on retrouve
execatement les mêmes champs.
Pour le calcul, je suppose que 'top' fait la différence de chacun des
champs toutes les n secondes et calcul les pourcentages en partant du
principe que le total des différences représente 100%.
- Manu
PS: un strace confirme que top utilise /proc/stat.
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Comme tu ne précises pas ton besoin ma réponse va sans doute tomber à côté de la plaque.
C'est plus de la curiosité qu'un réel besoin.
Toutefois top et gtop (applet) fournissent cette distinction en CPU utilisateur et CPU kernel, au besoin tu dois pouvoir écrire ton propre programme en t'inspirant des sources de ces images.
J'avais jamais fait attention que 'top' affichait ce détail :| Effectivement il doit s'inspirer de /proc/stat car on retrouve execatement les mêmes champs. Pour le calcul, je suppose que 'top' fait la différence de chacun des champs toutes les n secondes et calcul les pourcentages en partant du principe que le total des différences représente 100%.
- Manu
PS: un strace confirme que top utilise /proc/stat.
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat
OoO Lors de la soirée naissante du mardi 23 décembre 2003, vers 17:16, Manu disait:
J'avais jamais fait attention que 'top' affichait ce détail :| Effectivement il doit s'inspirer de /proc/stat car on retrouve execatement les mêmes champs. Pour le calcul, je suppose que 'top' fait la différence de chacun des champs toutes les n secondes et calcul les pourcentages en partant du principe que le total des différences représente 100%.
top n'invente rien, il utilise les statistiques collectées réguliè- rement par le noyau. Tu trouveras plus de détails dans un bouquin comme ``Understanding the Linux Kernel'' : <URL:http://www.oreilly.com/catalog/linuxkernel2/>
Il y a également sans doute pas mal de docs en lignes qui abordent ce point. De plus, ça se passe un peu de la même façon sur tous les Unix, tu peux donc aller regarder en bibliothèque un bouquin sur les systèmes d'exploitation comme celui de Tannenbaum. -- printk(KERN_WARNING "Multi-volume CD somehow got mounted.n"); 2.2.16 /usr/src/linux/fs/isofs/inode.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO Lors de la soirée naissante du mardi 23 décembre 2003, vers 17:16,
Manu <nobody@guzu.net.invalid> disait:
J'avais jamais fait attention que 'top' affichait ce détail :|
Effectivement il doit s'inspirer de /proc/stat car on retrouve
execatement les mêmes champs. Pour le calcul, je suppose que 'top'
fait la différence de chacun des champs toutes les n secondes et
calcul les pourcentages en partant du principe que le total des
différences représente 100%.
top n'invente rien, il utilise les statistiques collectées réguliè-
rement par le noyau. Tu trouveras plus de détails dans un bouquin
comme ``Understanding the Linux Kernel'' :
<URL:http://www.oreilly.com/catalog/linuxkernel2/>
Il y a également sans doute pas mal de docs en lignes qui abordent ce
point. De plus, ça se passe un peu de la même façon sur tous les Unix,
tu peux donc aller regarder en bibliothèque un bouquin sur les
systèmes d'exploitation comme celui de Tannenbaum.
--
printk(KERN_WARNING "Multi-volume CD somehow got mounted.n");
2.2.16 /usr/src/linux/fs/isofs/inode.c
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
OoO Lors de la soirée naissante du mardi 23 décembre 2003, vers 17:16, Manu disait:
J'avais jamais fait attention que 'top' affichait ce détail :| Effectivement il doit s'inspirer de /proc/stat car on retrouve execatement les mêmes champs. Pour le calcul, je suppose que 'top' fait la différence de chacun des champs toutes les n secondes et calcul les pourcentages en partant du principe que le total des différences représente 100%.
top n'invente rien, il utilise les statistiques collectées réguliè- rement par le noyau. Tu trouveras plus de détails dans un bouquin comme ``Understanding the Linux Kernel'' : <URL:http://www.oreilly.com/catalog/linuxkernel2/>
Il y a également sans doute pas mal de docs en lignes qui abordent ce point. De plus, ça se passe un peu de la même façon sur tous les Unix, tu peux donc aller regarder en bibliothèque un bouquin sur les systèmes d'exploitation comme celui de Tannenbaum. -- printk(KERN_WARNING "Multi-volume CD somehow got mounted.n"); 2.2.16 /usr/src/linux/fs/isofs/inode.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
Manu wrote:
La réponse se trouve peut-être dans le deuxième champ de la ligne cpu de /proc/stat...
Je me suis fait un petit script utilisant rrdtool pour afficher une jolie courbe des différentes variations des champs cpu0 de /proc/stat et puis j'ai essayé de chargé ma machine pour voir si le champs 'system' correspondait à une réelle estimation du temps total passé dans le noyau ou plus simplement le temps passé en mode noyau PAR LES PROCESSUS. J'ai installé ça sur ma passerelle (un P200) et je l'ai ping floodé (en 100Mbits/s) depuis une machine plus rapide. Résultat, le champ 'system' indiqué dans /proc/stat indique bien le temps total passé dans le noyau par CPU, et ce ping flood chargeait la machine à 75%...
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu wrote:
La réponse se trouve peut-être dans le deuxième champ de la ligne cpu de
/proc/stat...
Je me suis fait un petit script utilisant rrdtool pour afficher une
jolie courbe des différentes variations des champs cpu0 de /proc/stat et
puis j'ai essayé de chargé ma machine pour voir si le champs 'system'
correspondait à une réelle estimation du temps total passé dans le noyau
ou plus simplement le temps passé en mode noyau PAR LES PROCESSUS.
J'ai installé ça sur ma passerelle (un P200) et je l'ai ping floodé (en
100Mbits/s) depuis une machine plus rapide.
Résultat, le champ 'system' indiqué dans /proc/stat indique bien le
temps total passé dans le noyau par CPU, et ce ping flood chargeait la
machine à 75%...
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
La réponse se trouve peut-être dans le deuxième champ de la ligne cpu de /proc/stat...
Je me suis fait un petit script utilisant rrdtool pour afficher une jolie courbe des différentes variations des champs cpu0 de /proc/stat et puis j'ai essayé de chargé ma machine pour voir si le champs 'system' correspondait à une réelle estimation du temps total passé dans le noyau ou plus simplement le temps passé en mode noyau PAR LES PROCESSUS. J'ai installé ça sur ma passerelle (un P200) et je l'ai ping floodé (en 100Mbits/s) depuis une machine plus rapide. Résultat, le champ 'system' indiqué dans /proc/stat indique bien le temps total passé dans le noyau par CPU, et ce ping flood chargeait la machine à 75%...
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Manu
Vincent Bernat wrote:
top n'invente rien, il utilise les statistiques collectées réguliè- rement par le noyau. Tu trouveras plus de détails dans un bouquin comme ``Understanding the Linux Kernel'' : <URL:http://www.oreilly.com/catalog/linuxkernel2/>
Et non :) Je l'ai à la maison, mais il n'en parle pas. La raison est simple je pense, les stats c'est pas compliqué :)
Du coup j'ai regardé. La base du comptage est le "tick" (1 tick = 1 interruption liée au timer). Selon le mode actuel (mode utilisateur ou noyau) les champs 'user' ou 'system' sont incrémentés ('nice' peut également l'être à la place de 'user' pour les raisons qu'on devine). Le champ 'idle' est calculé en faisant la différence entre le nombre total de ticks et la somme des ticks des trois autres champs. Lors de la consultation de /proc/stat le temps pour chacun des champs est calculé par rapport à la granularité du timer (période entre 2 ticks).
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat wrote:
top n'invente rien, il utilise les statistiques collectées réguliè-
rement par le noyau. Tu trouveras plus de détails dans un bouquin
comme ``Understanding the Linux Kernel'' :
<URL:http://www.oreilly.com/catalog/linuxkernel2/>
Et non :)
Je l'ai à la maison, mais il n'en parle pas.
La raison est simple je pense, les stats c'est pas compliqué :)
Du coup j'ai regardé. La base du comptage est le "tick" (1 tick = 1
interruption liée au timer). Selon le mode actuel (mode utilisateur ou
noyau) les champs 'user' ou 'system' sont incrémentés ('nice' peut
également l'être à la place de 'user' pour les raisons qu'on devine).
Le champ 'idle' est calculé en faisant la différence entre le nombre
total de ticks et la somme des ticks des trois autres champs.
Lors de la consultation de /proc/stat le temps pour chacun des champs
est calculé par rapport à la granularité du timer (période entre 2 ticks).
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
top n'invente rien, il utilise les statistiques collectées réguliè- rement par le noyau. Tu trouveras plus de détails dans un bouquin comme ``Understanding the Linux Kernel'' : <URL:http://www.oreilly.com/catalog/linuxkernel2/>
Et non :) Je l'ai à la maison, mais il n'en parle pas. La raison est simple je pense, les stats c'est pas compliqué :)
Du coup j'ai regardé. La base du comptage est le "tick" (1 tick = 1 interruption liée au timer). Selon le mode actuel (mode utilisateur ou noyau) les champs 'user' ou 'system' sont incrémentés ('nice' peut également l'être à la place de 'user' pour les raisons qu'on devine). Le champ 'idle' est calculé en faisant la différence entre le nombre total de ticks et la somme des ticks des trois autres champs. Lors de la consultation de /proc/stat le temps pour chacun des champs est calculé par rapport à la granularité du timer (période entre 2 ticks).
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Jeremy JUST
On 23 Dec 2003 09:14:40 GMT Manu wrote:
Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ? En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite en mode noyau, ce qui est assez embêtant pour une utilisation de linux en firewall, par exemple.
Attention, la charge donnée par `uptime' est une estimation globale, pour l'ensemble de la machine. Elle n'est pas liée qu'à l'utilisation des CPU.
Quand tu fais énormément d'accès aux disques, tu peux avoir une occupation des CPU inférieure à 1% et une charge de l'ordre de 6-8 (vu couramment sur un bi-Athlon 1800+).
-- Jérémy JUST
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
On 23 Dec 2003 09:14:40 GMT
Manu <nobody@guzu.net.invalid> wrote:
Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle
d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ?
En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite
en mode noyau, ce qui est assez embêtant pour une utilisation de linux
en firewall, par exemple.
Attention, la charge donnée par `uptime' est une estimation globale,
pour l'ensemble de la machine. Elle n'est pas liée qu'à l'utilisation des
CPU.
Quand tu fais énormément d'accès aux disques, tu peux avoir une
occupation des CPU inférieure à 1% et une charge de l'ordre de 6-8 (vu
couramment sur un bi-Athlon 1800+).
--
Jérémy JUST <jeremy_just@netcourrier.com>
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Y a-t-il moyen d'avoir une idée plus précise sur la charge CPU réelle d'un machine autrement qu'en utilisant uptime ou /proc/loadavg ? En effet ceux-ci ne semblent pas prendre en compte la charge CPU induite en mode noyau, ce qui est assez embêtant pour une utilisation de linux en firewall, par exemple.
Attention, la charge donnée par `uptime' est une estimation globale, pour l'ensemble de la machine. Elle n'est pas liée qu'à l'utilisation des CPU.
Quand tu fais énormément d'accès aux disques, tu peux avoir une occupation des CPU inférieure à 1% et une charge de l'ordre de 6-8 (vu couramment sur un bi-Athlon 1800+).
-- Jérémy JUST
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
