profiler les I/O

dva2tlse · Le 04/10/2013, à 14:41

Bonjour le forum,
j'ai déjà fait appel à vous quelques fois, et j'ai une nouvelle question à poser concernant le même sujet; il s'agit d'un gros (pour moi en tous cas) programme en fortran que je suis en train de développer et qui devra tourner assez vite, enfin pour lequel la vitesse d'exécution est critique; j'ai appris à paralléliser avec openmp (l'une des machines sur lesquelles je bosse a quarante proc's), et avec du profilage je sais où porter mes efforts d'amélioration, mais je voudrais maintenant savoir comment se répartissent les temps de calcul, d'accès à la mémoire (si on peut les dissocier) et d'I/O, puisque je crains que celles-ci ne soient importantes en durée, mais je ne sais pas dans quelle proportion, et il me faut le savoir pour prendre des décisons judicieuses.
Merci de m'aider encore sur ce point,
David

Dernière modification par dva2tlse (Le 04/10/2013, à 14:42)

Kooothor · Le 04/10/2013, à 15:29

Salut,

Tu connais igprof ? http://igprof.org/

Sinon je t'invite à lire : http://en.wikipedia.org/wiki/List_of_pe … ysis_tools

@+
~ktr

claudius01 · Le 04/10/2013, à 16:18

Bonjour,

Pour une répartition entre les I/O et autres, il y a sar qui fournit une sortie du genre:

# Lancement d'un 1st 'find' qui fera bcp d'I/O
$ sudo find / -name "sar" &

$ sar 1 100
Linux 3.5.0-30-generic (claudius-VirtualBox)      04/10/2013      _x86_64_        (1 CPU)

15:59:33        CPU     %user     %nice   %system   %iowait    %steal     %idle
15:59:34        all      1,08      0,00      9,68      0,00      0,00     89,25
15:59:35        all      2,20      0,00      2,20      0,00      0,00     95,60
15:59:36        all      0,00      0,00      1,18      0,00      0,00     98,82
15:59:37        all      1,12      0,00      4,49      0,00      0,00     94,38
...
16:00:11        all      4,71      0,00     11,76     83,53      0,00      0,00
16:00:12        all      1,15      0,00      6,90     91,95      0,00      0,00
16:00:13        all      1,12      0,00      8,99     89,89      0,00      0,00
16:00:14        all      1,15      0,00      6,90     91,95      0,00      0,00
16:00:15        all      0,00      0,00      8,24     91,76      0,00      0,00
16:00:16        all      0,00      0,00     13,58     86,42      0,00      0,00
16:00:17        all      2,47      0,00      8,64     88,89      0,00      0,00
16:00:18        all      1,16      0,00      6,98     91,86      0,00      0,00
16:00:19        all      0,00      0,00      8,64     91,36      0,00      0,00
16:00:20        all      3,33      0,00      2,22      5,56      0,00     88,89
16:00:21        all      3,33      0,00      6,67      0,00      0,00     90,00
16:00:22        all      1,09      0,00      6,52      0,00      0,00     92,39
...

cf. aussi le blog: http://www.thegeekstuff.com/2011/03/sar-examples/

Cordialement, A+
--
Claudius

grim7reaper · Le 04/10/2013, à 16:21

Salut,

En première grosse approximation, tu peux lancer le programme avec la commande time.
Ça va te donner le temps utilisateur (ton code) et le temps système (appels systèmes, souvent I/O mais pas que… d’où la grosse approximation).
Ça peut déjà te donner une idée si ton programme est limité par le CPU ou les I/O (CPU qui se tourne les pouces).

Édit : j’avais oublié la commande sar dont Claudius parle, oui autant utiliser sar (ça te donnera plus d’info).

Dernière modification par grim7reaper (Le 04/10/2013, à 16:24)

dva2tlse · Le 04/10/2013, à 16:31

Merci les gars,
je suis à peine rentré chez moi après avoir posé ma question depuis le boulot qu'il y a déjà plein de pistes.
Pour l'instant je développe avec gfortran, donc je vais farfouilller dans les options de gprof pour trouver quelque chose qui me convienne, mais je l'ai déjà utilisé et ai donc survolé la doc, et il ne m'a pas semblé voir la fonctionnalité dont j'ai besoin pour voir si les I/O et les recherches en mémoire sont longues. Mais je vais donc chercher... et ce qui m'est dit ci-dessus à propos de sar et time correspond déjà pas mal à ce que je cherche à faire.
Merci,
David

dva2tlse · Le 06/10/2013, à 13:40

Ok merci encore les gars, mais maintenant je vais essayer de prévoir ce qu'il me sera possible de faire dans ce domaine demain au boulot (j'ai la chance d'avoir un boulot qui me passionne même le week-end)(au grand désespoir de ma nana, mais là elle dort, ARF)(midi)

Alors comment faire avec ces outils pour "profiler les I/O" de mon programme ? Celui ci s'appelle rfomp1 et tourne sans arguments puisque je les ai tous mis "en dur" dans le programme pour la durée de sa mise au point; donc je n'aurai qu'à faire ce qui suit : (trois sections séparées par des -------, puis une question finale)

----------------------------------------------------------------------
-Pour utiliser time :
$ time -f "%E real,%U user,%S sys,%P percent,%I input,%O output" ./rfomp1

$ export TIME=""%E real,%U user,%S sys,%P percent,%I input,%O output"
$ time ./rfomp1

The default format is: %Uuser %Ssystem %Eelapsed %PCPU (%Xtext+%Ddata %Mmax)k %Iinputs+%Ooutputs (%Fmajor+%Rminor)pagefaults %Wswaps
U Total number of CPU-seconds that the process used directly (in user mode), in seconds.
S Total number of CPU-seconds used by the system on behalf of the process (in kernel mode), in seconds.
E Elapsed real (wall clock) time used by the process, in [hours:]minutes:seconds.
P Percentage of the CPU that this job got. This is just user + system times divided by the total running time. It also prints a percentage sign.
I Number of file system inputs by the process.
O Number of file system outputs by the process.

Ok pour ça, mais cela ne me donnera les diverses infos que j'aurai demandées que sur l'exécution totale de mon programme, sans que je puisse savoir précisément quelle partie du programme attend des I/O ou quelle autre calcule à fond.

----------------------------------------------------------------------
-Pour utiliser top, il va se présenter le même genre d'inadéquation à mon besoin réel; soit c'est interactif et ça ne m'intéresse pas, soit ça va dans un fichier que je peux lire à la fin du déroulement de mon programme, mais de la même façon qu'avec time, les info's recueillies concerneront l'intégralité de mon programme, et non pas ses étapes intermédiaires.

$ top -d delay -n iterations -p pid -b(=Batch)
$ PID=$(ps -efu dael|grep rfomp1|grep -v grep|awk '{print $2}'
$ top -d delay -n iterations -p $PID (existe-t'il un moyen de choisir le PPID ?(champ b, le a est le PID))
2c. CPU States The CPU states are shown in the Summary Area. They are always shown as a percentage and are for the time between now and the last refresh.
wa -- iowait
Amount of time the CPU has been waiting for I/O to complete.

----------------------------------------------------------------------
-pour utiliser sar, ici aussi même remarque que pour time.

sar (-u(=CPU), -P ProcessorN°, [ interval [ count ] ]
For example, the following gives the system CPU statistics 3 times (with 1 second interval). $ sar 1 3
$ sar -P all 1 1 (->%iowait)

----------------------------------------------------------------------
-Alors "the big question" se trouve ici : Comment profiler les I/O de mon programme ! J'ai besoin de savoir quels sont les sous-programmes de mon fortran qui attendent après des I/O, et dans quelle proportion, par rapport à ceux qui calculent à fond.
J'ai mis le verbe "profiler" dans le nom de ce fil de discussion, parce que ce que je recherche est un peu comme le résultat d'un profilage, à savoir être informé après coup, des fonction ou sous-programmes qui utilisent le plus telle ou telle ressource de la machine, sauf que ce qui m'intéresse ici est la "ressource I/O" et non pas la ressource cpu qu'afficherait un profilage de base.
Merci de m'aider encore si possible,
David
----------------------------------------------------------------------
PS: Ceci n'est qu'un pense-bête pour me rappeler un truc à faire demain : verif

grim7reaper · Le 06/10/2013, à 13:57

Oui ces commandes ne vont te donner qu’une information globale. Pas fonction par fonction.
Donc ça va te permettre de savoir si oui ou non ton programme est limité par les I/O.
Après, je ne sais pas comment est fait ton programme, mais en général tu charges tes données, tu fais tes calculs, puis tu écris les résultats. Donc si les I/O sont vraiment un problème, le code à analyser va être facile à localiser (appels à read et write) donc je ne suis pas sûr que tu gagnes beaucoup d’informations à savoir quel sous-programmes exactement. Mais bon, je ne connais pas ton code.

dva2tlse · Le 06/10/2013, à 15:49

Salut grim7reaper,
merci de t'intéresser à mon affaire; je vais donc essayer d'exposer cela de façon compréhensible et ça devrait m'aider aussi.
Le programme que je développe doit faire 300 mille tâches unitaires en une semaine environ pour être utile; la première fois que le sous programme le plus important a tourné, il a mis vingt minutes sur une vieille HP 9000 asthmatique. C'est du fortran puisque je connais bien mieux que le C qui aurait pu servir aussi. Assez rapidement on a changé de machine, et maintenant je bosse sur un red hat linux à quarante processeurs, et ça effectue 16 tâches unitaires en 90s sur 16 proc's en étant parallèlisé avec openmp.
Donc je peux espérer 40 tâches unitaire en 90s sur les 40 proc's, ce qui ferait 300000/40*90/3600/24=7,8 jours pour le total.

Pour gagner ce qu'il me reste à gagner, j'aimerais que les threads qui font des I/O le fassent pendant que d'autres calculent et vice versa, et c'est dans ce but que je voudrais avoir une image réaliste de la situation actuelle.
David

claudius01 · Le 07/10/2013, à 14:08

Bonjour,

J'ai lu et relu ce fil de discussion et, sauf erreur de ma part, aucune information chiffrée n'est présentée pour bien cerner certains points comme :

- La machine avec ses N cores est-elle occupée à plus de 80% ou 90%, voire plus (cad avec 10% à 20% idle voire moins) lors du travail demandé ?
=> Si c''est le cas, parfait ; il n'y a aucune latence n'y d'attente passive excessive suite à l'utilisation de ressources critiques (non thread safe) prises par sémaphore par exemple. Le summum est d'occuper une machine à 100% qui fasse naturellement un travail attendu dans le plus court laps de temps...
De plus, et toujours dans ce cas, quel est le % d'I/O et du fait de l'architecture retenue, que sont ces I/O : mémoire, disque ou réseau ?
Enfin, question bête : Si les I/O "bloquent", n'y aurait-il pas des flush forcés par l'application qui pourraient être laissées à l'initiative de l'OS qui le fera toujours mieux que le plus expérimenté des développeurs ?

=> Si ce n'est pas le cas (une machine qui se tourne les pouces ou presque), comprendre pourquoi car cela peut être dû justement à des attentes passives de ces libérations de zones critiques (j'exclus les attentes actives à bannir qui feraient monter le % CPU inutilement).

- Je rejoins grim7reaper sur le fait qu'il faille d'abord s'intéresser aux chiffres globaux collectés sur une période significative et après seulement s'intéresser à leur ventilation dans telle ou telle partie du programme.

- Toutes les options d'optimisation du compilateur Fortran (que je ne connais pas) ont-elles été explorées ?

En espérant que cela t'aide pour que nous puissions d'aider ;-)

[Edit] Corrections éditoriales...

Cordialement, A+
--
Claudius

Dernière modification par claudius01 (Le 07/10/2013, à 20:21)

dva2tlse · Le 09/10/2013, à 15:30

Bonjour Cladius01,
je vais prendre un petit peu de temps pour te rÅpondre bien que je sois au boulot et que je ne devrais donc pourtant pas toucher au net', mais d'autres fils de discussion m'ont fait remarquer que ton avis ou tes questions pourraient m'Átre utiles (et finalement faire gagner du pognon È mon patron).
En ce qui concerne la machine È 40 cores, elle sert È de grosses applications de calcul de structure (mon mÅtier) avec pas mal d'I/O sur des fichiers de donnÅes d'entrÅe, et beaucoup de CPU en interactif principalement (donc pas la nuit); les quelque tÀches faites en batch, sont des trucs rÅpÅtitifs mais pas trop gourmands.
Je ne suis pas encore parvenu È utiliser les 40 proc's, j'en suis È 16 et je bute temporairement sur une application subalterne qui fabriquera certaines donnÅes d'entrÅe. Quand je pourrais avoir facilement assez de donnÅes d'entrÅe, j'essaierai de passer È 20 puis 32 puis 40 cores.
De toute faµon, omp (la bibliothÉque qui permet la parallÅlisation) permet de se limiter È 20 cores (par exemple) tant que d'autres ont besoin de la moitiÅ de la machine, mais il est envisagÅ que quand tout marchera È fond, la machine ne serve qu'È µa pendant une semaine. (mais µa ne viendra que progressivement, en environ un an)
AprÉs une petite bagarre interne dans ma boite, tout tourne sur les disques internes È la machine, donc pas de latence due au rÅseau. (cependant je ne connais pas les perfoamances du ou des disques, mais µa doit Átre du niveau du reste, donc plutÂt bon)
Je ne connais mÁme pas encore les % d'I/O, donc je regarderai µa globalement, avant d'affiner si besoin et si possible.
Je ne sais pas du tout ce que peut faire le compilateur, mais il sera possible d'en changer si jamais il n'allait pas, ce qui m'Åtonnerait de GNU.
Merci et È une prochaine fois sÃrement, dÉs que j'aurai des questions insolubles tout seul.
David

Edit: un dernier truc avant de partir . j'ai lancé la commande que j'avvais établie au post' là haut :
$ time -f "%E real,%U user,%S sys,%P percent,%I input,%O output" ./rfomp1
et ça me répond ça, que je ne sais même pas interpréter :
2:47.26 real,874.86 user,1431.31 sys,1378% percent,0 input,0 output

Dernière modification par dva2tlse (Le 09/10/2013, à 15:48)

grim7reaper · Le 09/10/2013, à 16:35

dva2tlse a écrit :

Je ne sais pas du tout ce que peut faire le compilateur, mais il sera possible d'en changer si jamais il n'allait pas, ce qui m'étonnerait de GNU.

Autant niveau C et C++, gcc se défend bien.
Autant gfortran c’est pas une référence (il reste relativement bon quand même hein, c’est pas une merde non plus), mais le compilo’ Intel est assez loin devant en général (de ma maigre expérience).

dva2tlse a écrit :

$ time -f "%E real,%U user,%S sys,%P percent,%I input,%O output" ./rfomp1
et ça me répond ça, que je ne sais même pas interpréter :
2:47.26 real,874.86 user,1431.31 sys,1378% percent,0 input,0 output

Si tu as tourné sur 16 cœurs, ça fait du 1378/16 =~ 86.12% CPU en moyenne.
Pas si mal.

dva2tlse · Le 09/10/2013, à 19:00

Salut grim7reaper,
bonjour et merci encore; vos interventions à claudius01 et à toi m'aident beaucoup, en ce sens qu'elles m'évitent de me sentir perdu tout seul avec ce boulot démentiel; c'est sans conteste l'un des cinq plus intéressants que j'aie faits en vingt et quelques années de boite, mais pas grand monde d'autre que moi n'y connait grand chose, à part mon chef qui parle fortran et m'a demandé de développer l'outil, mais je ne peux pas trop lui montrer mes insuffisances tous les deux jours. (!)
Pour le compilo', en effet j'ai déjà lu quelque part (sans en avoir aucune expérience cependant) que le intel (ifort je cois) était un peu mieux que le GNU, mais nous n'en sommes pas encore à chatouiller les fractions de secondes; on verra les optimisations plus tard.
Pour le "time", en effet j'ai tourné sur 16 proc's, donc 1378 % c'est pas mal; et je l'ai même vu, une fois où je devais être vraiment tout seul, à plus de 1500 %; 1553 je crois, et ça, ça m'éclate bien, d'extirper de la bécane tout ce qu'elle a dans le ventre.
Par contre, de même que j'ai relu ce post' pour retrouver la commade "time" complète, j'ai relu aussi qu'il était question quelque part de "sar" pour "profiler les I/O" (n'oublions pas la raison d'être première de ce fil) hébin la bécane qui est une red hat ne connait pas "sar". Alors que faire ? (j'ai encore la possibilité d'aller voir sur un forum de (ce) linux)
Pour l'instant, la seule info' que j'aie sur les I/O est le %I de time, et son %O donnent ça : 0 input,0 output. Comment est il possible que le "Number of file system inputs by the process" (le %I) et le "Number of file system outputs by the process" (le %O) valent tous les deux 0, alors que j'ai de tonnes d'entrée (plusieurs mégas dans une petite vingtaine de fichiers) et moins de sorties, mais quelques kilos quand même, ou même des dizaines ou centaines. Je dois mal interpréter ce qu'ils appellent "file system inputs/outputs", mais savez vous ce que ca représente ?
@claudius-> "Enfin, question bête : Si les I/O "bloquent", n'y aurait-il pas des flush forcés par l'application qui pourraient être laissées à l'initiative de l'OS qui le fera toujours mieux que le plus expérimenté des développeurs ?"
J'avais en effet des "flush" comme directives ou instructions de openmp, mais c'était à mes tout débuts quand pas mal de données étaient partagées entre tous les threads du programme; maintenant que je sais que la machine a assez de mémoire pour 16 threads, chaque proc' travaille sur son propre lot de données indépendamment des autres et il n'y a plus besoin de flush. Par contre à propos de la mémoire, cet après midi j'ai essayé abruptement de passer à 40 proc's, et il m'a répondu une "Memory Fault", mais c'était peut-être une segfault ordinaire puisque certains tableaux de variables annexes étient encore de dimension 16 et pas encore 40. (ceci est une idée qui m'est venue en écrivant)
Bon, allez, ça ira pour aujourd'hui.
À bientôt certainement et avec encore plein de remerciements pour l'occasion que vous me donnez d'apprendre des trucs,
David
PS je viens de voir que "sar" devrait marcher sous red hat.
PS2 jeudi matin au boullot; en fait "sar" n'est pas installé sur la machine d'ici, donc il faut que je demande à l'admin de faire un coup d'"apt-get" ou de "yum" pour le mettre.
Mais est il possible de faire sans ? Et que sont ces (foutus) "file system inputs/outputs" annoncés par "time" ?

Dernière modification par dva2tlse (Le 10/10/2013, à 07:55)

grim7reaper · Le 10/10/2013, à 13:26

Je pense que time se base sur la fonction getrusage et dans le man on voit que :

man 2 getrusage a écrit :

ru_inblock (since Linux 2.6.22)
The number of times the file system had to perform input.
ru_oublock (since Linux 2.6.22)
The number of times the file system had to perform output.

Bon ça ne t‘avances pas trop (si ce n’est qu’il faut un noyau Linux pas trop vieux pour que ces informations soient disponibles).

Au passage, time en général fait appel au builtin du shell (donc le résultat peut varier d‘un shell à l‘autre). Exemple :
Bash :

% time cat /proc/self/comm
cat

real    0m0.001s
user    0m0.000s
sys     0m0.000s

ZSH :

% time cat /proc/self/comm 
cat
cat /proc/self/comm  0,00s user 0,00s system 0% cpu 0,001 total

Pour utiliser la vrai commande time, qui peut donner pas mal d’info en mode verbeux, il faut utiliser son nom complet (/usr/bin/time)

/usr/bin/time -v cat /proc/self/comm
cat
        Command being timed: "cat /proc/self/comm"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: ?%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 580
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 191
        Voluntary context switches: 1
        Involuntary context switches: 3
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

dva2tlse · Le 10/10/2013, à 15:04

Bonjour,
comme sar n'est pas installé sur la bécane sur laquelle je bosse, j'en suis réduit à utiliser strace qui recense les appels système et peut donner des foultitudes d'infos sur chacun. La première utilisation que j'en ai faite m'a sorti des tonnes d'appels à "futex" mais qu'est-ce que c'est (je n'ai pas vraiment pigé le man) et que me conseillez vous ? Est-ce que cela semble correct et utile ?
strace -e trace=open,close,read,write ./rfomp1
Mais c'est horriblement lent, donc je ne trouve ça pas très utilisable.
David

Dernière modification par dva2tlse (Le 10/10/2013, à 15:06)

grim7reaper · Le 10/10/2013, à 16:07

Futex (fast userspace mutex) est une implémentation des mutex spécifique à Linux. Ils permettent d‘éviter pas mal d’appels systèmes coûteux par rapport aux mutex traditionnels.
Comme tu fais du code parallèle, ça me choque pas de voir des appels à futex.

strace c‘est un super outil pour voir ce que fait ton programme, mais ça ne te donnera aucune information sur le temps passé dans les I/O.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/10/2013, à 14:41

profiler les I/O

#2 Le 04/10/2013, à 15:29

Re : profiler les I/O

#3 Le 04/10/2013, à 16:18

Re : profiler les I/O

#4 Le 04/10/2013, à 16:21

Re : profiler les I/O

#5 Le 04/10/2013, à 16:31

Re : profiler les I/O

#6 Le 06/10/2013, à 13:40

Re : profiler les I/O

#7 Le 06/10/2013, à 13:57

Re : profiler les I/O

#8 Le 06/10/2013, à 15:49

Re : profiler les I/O

#9 Le 07/10/2013, à 14:08

Re : profiler les I/O

#10 Le 09/10/2013, à 15:30

Re : profiler les I/O

#11 Le 09/10/2013, à 16:35

Re : profiler les I/O

#12 Le 09/10/2013, à 19:00

Re : profiler les I/O

#13 Le 10/10/2013, à 13:26

Re : profiler les I/O

#14 Le 10/10/2013, à 15:04

Re : profiler les I/O

#15 Le 10/10/2013, à 16:07

Re : profiler les I/O

Pied de page des forums