Informations de /proc//usage (Solaris)

Le
Jérémy JUST
Bonjour,

Pour avoir des informations détaillées sur les processus, je lis le
contenu de /proc/<PID>/usage. Le problème est que je ne comprends pas le
sens concret de certaines informations J'ai collé la structure
correspondante ci-dessous. Je m'interroge notamment sur:
- text/data/kernel page fault sleep time,
- minor/major page faults,
- swaps,
- input/output blocks.

En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il
est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il
attend des données de la mémoire ou du swap, est-ce qu'il s'est fait
swapper).
Peut-être y a-t-il d'autres façons de savoir tout ça?





Partie intéressante de /usr/include/sys/procfs.h (Solaris 7 à 9)
<<<<<
/*
* Resource usage. /proc/<pid>/usage /proc/<pid>/lwp/<lwpid>/lwpusage
*/
typedef struct prusage {
id_t pr_lwpid; /* lwp id. 0: process or defunct */
int pr_count; /* number of contributing lwps */
timestruc_t pr_tstamp; /* current time stamp */
timestruc_t pr_create; /* process/lwp creation time stamp */
timestruc_t pr_term; /* process/lwp termination time stamp */
timestruc_t pr_rtime; /* total lwp real (elapsed) time */
timestruc_t pr_utime; /* user level cpu time */
timestruc_t pr_stime; /* system call cpu time */
timestruc_t pr_ttime; /* other system trap cpu time */
timestruc_t pr_tftime; /* text page fault sleep time */
timestruc_t pr_dftime; /* data page fault sleep time */
timestruc_t pr_kftime; /* kernel page fault sleep time */
timestruc_t pr_ltime; /* user lock wait sleep time */
timestruc_t pr_slptime; /* all other sleep time */
timestruc_t pr_wtime; /* wait-cpu (latency) time */
timestruc_t pr_stoptime; /* stopped time */
timestruc_t filltime[6]; /* filler for future expansion */
ulong_t pr_minf; /* minor page faults */
ulong_t pr_majf; /* major page faults */
ulong_t pr_nswap; /* swaps */
ulong_t pr_inblk; /* input blocks */
ulong_t pr_oublk; /* output blocks */
ulong_t pr_msnd; /* messages sent */
ulong_t pr_mrcv; /* messages received */
ulong_t pr_sigs; /* signals received */
ulong_t pr_vctx; /* voluntary context switches */
ulong_t pr_ictx; /* involuntary context switches */
ulong_t pr_sysc; /* system calls */
ulong_t pr_ioch; /* chars read and written */
ulong_t filler[10]; /* filler for future expansion */
} prusage_t;
>>>>>

--
Jérémy JUST <jeremy_just@netcourrier.com>
Vos réponses
Trier par : date / pertinence
DINH Viêt Hoà
Le #449725

- text/data/kernel page fault sleep time,


le temps d'attente entre le moment où le processus a demandé une page au
noyau et le moment où il l'a reçu, et ceci pour des pages dans les
segments de données précisés.

- minor/major page faults,


une faute de page un accès à une page alors qu'elle n'est pas réellement
en mémoire physique. La différence entre une faute mineure et majeure
est un accès au disque (cas de la faute majeure).
Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page
Exemple de faute majeure : accès à une page mémoire dont les données ont
été placées sur disque (fichier d'échange (swap))

- swaps,


nombre d'accès au swap

En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il
est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il
attend des données de la mémoire ou du swap, est-ce qu'il s'est fait
swapper...).
Peut-être y a-t-il d'autres façons de savoir tout ça?


Dans quel but ?

Pourquoi ne pas utiliser les méthodes standard de profiling
de programmes ?

--
DINH V. Hoa,

"on peut rouler dans une épave avec un caisson de basse" -- sunZ

Jérémy JUST
Le #449724
On Mon, 5 Apr 2004 02:25:34 +0200
DINH Viêt Hoà
- text/data/kernel page fault sleep time,
le temps d'attente

[...]


Merci pour ces précieuses informations!


Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page


Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.


En fait, je cherche mieux savoir ce que fait un processus
Dans quel but ?



J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).


Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.


Pourquoi ne pas utiliser les méthodes standard de profiling de
programmes ?


Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un
programme, et non la façon dont une machine le fait tourner?

Dans mon cas, j'utilise des applications de calcul déjà écrites et
figées, et je voudrais évaluer les différences de comportement sur
différents processeurs, en éliminant le plus possible les autres facteurs.
Je sais bien que certains facteurs ne pourront être éliminés, comme le
temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces
influences?
Je regarderai de plus près les « text/data/kernel page fault sleep
time », pour voir si ça semble correspondre.


Je suis preneur de toute suggestion. Je mène ces tests en tant que
simple utilisateur, et j'avoue être assez démuni... :(

--
Jérémy JUST

Jérémy JUST
Le #449723
On Mon, 5 Apr 2004 02:25:34 +0200
DINH Viêt Hoà
- text/data/kernel page fault sleep time,
le temps d'attente

[...]


Merci pour ces précieuses informations!


Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page


Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.


En fait, je cherche mieux savoir ce que fait un processus
Dans quel but ?



J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).


Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.


Pourquoi ne pas utiliser les méthodes standard de profiling de
programmes ?


Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un
programme, et non la façon dont une machine le fait tourner?

Dans mon cas, j'utilise des applications de calcul déjà écrites et
figées, et je voudrais évaluer les différences de comportement sur
différents processeurs, en éliminant le plus possible les autres facteurs.
Je sais bien que certains facteurs ne pourront être éliminés, comme le
temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces
influences?
Je regarderai de plus près les « text/data/kernel page fault sleep
time », pour voir si ça semble correspondre.


Je suis preneur de toute suggestion. Je mène ces tests en tant que
simple utilisateur, et j'avoue être assez démuni... :(

--
Jérémy JUST

DINH Viêt Hoà
Le #449722

Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page


Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.


Après, savoir si ses compteurs sont encore utilisés ... ou s'ils sont
restés là à titre historique ...

Il existe vmstat sous solaris pour avoir ces compteurs de façon globale.
Si seul ton programme tourne sur la machine, tu peux considérer que la
valeur de ces compteurs seront proche de la valeur que tu recherches.

J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).


Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.


S'il s'agit de vérifier si un programme a swappé, ne suffit-il pas de
lire la valeur affichée par vmstat ?

--
DINH V. Hoa,

"écrire 'dsl' au lieu de 'désolé', c'est pas un problème d'orthographe,
c'est un problème de capillarité palmaire" -- ed


Publicité
Poster une réponse
Anonyme