Discussion :

[LGnord]

Bonjour,

J'utilise la commande time pour faire une mesure de performance et j'obtiens le résultat suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
real   13m26.318s
user   10m22.007s
sys    0m6.226s

Je suis surpris que le real time et le user time soient très différents. Comment interpréter ce résultat? Pendant plus de 3 minutes, mon application tourne mais le cpu ne fait rien? Est-ce un problème d'IO?

Cette mesure est stable et il n'y a pas d'autres applications qui tournent sur ma machine.

Merci de votre aide.

[jlliagre]

Les valeurs ne sont pas si différentes que ça. Il faudrait que tu en dises plus sur la commande mesurée pour avoir une idée plus précise

En général, ce sont en effet des entrées/sorties (disque, réseau, clavier) qui sont à l'origine de cet écart, parfois des sleep dans le code.

[frp31]

Bonjour,

J'utilise la commande time pour faire une mesure de performance et j'obtiens le résultat suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
real   13m26.318s
user   10m22.007s
sys    0m6.226s

Je suis surpris que le real time et le user time soient très différents. Comment interpréter ce résultat? Pendant plus de 3 minutes, mon application tourne mais le cpu ne fait rien? Est-ce un problème d'IO?

Cette mesure est stable et il n'y a pas d'autres applications qui tournent sur ma machine.

Merci de votre aide.

la différence est pas si grande que ça et semble tout à fait cohérante à priori
ton sys à 6.226 secondes est tout à fait logique avec un user time de 10min et un sys à 13 rien de choquant -vue qu'on connait pas ta config et ton appli ça semble des valeurs normales- en particulier sur archi x86

ton application n'a pas tourné 13-10 minutes
mais bien 0min6.226secondes ( c'est pas si vrai que ça mais c'est comme ça qu'il faut le comprendre), ta session Utilisateur lié à l'exécution de l'application a elle duré 10minutes soit 3 de moins que le temps total assujeti à cette dernière.

il faut se rappeler que 1 core CPU ne fait qu'une seule tache à la fois, et sur x86 passe 90% de sa vie ces cyles (au sens éléctronique du terme) à faire 2 choses :

• Mettre les bits dans le bon sens pour traiter l'information
• faire un NOP (attendre le bus)
• lire OUEXCLUSIF ecrire sur le bus

tu peux voir ça comme cet exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
1hz = 1cycle à la seconde
une commande mov registreinterne,variable = 5 cycles
1 lire le bus (la donnée variable) 
2 remettre les bits dans le bon ordre
3 appeler la fonction assembleur correspondante dans le composant (core CPU)
4 realiser l'opération
5 envoyer l'acknowledgement sur le bus
total 5 secondes

exagéré volontairement pour mieux me faire comprendre
tu multiplies ça par des milions d'instructions, dans des dizaines de processus, il devient évident que les processus partagent le temps CPU, entre eux, + toutes les couches d'abstractions software, et hardware avant d'atteindre la CPU, et les éventuels attente d'accusé de receptions matériels entre les différents composants de la machine...bref tout ça prend un temps monstre et en gros pour faire simple 90% du temps le CPU ne fait concrétement rien ( pour l'utilisateur) parce que même l'opérande NOP no operation prend 1 cycle d'horloge ... soit sur un CPU monocore de 3Ghz : 1 troismilliardieme de secondes...

alors 0'6"222 de temps réellement accompli à une seule tache sur un temps total de 13minutes pour réaliser la tache c'est vraiment pas anormal... surtout avec seulement 3minutes de différence avec le temps "utilisateur"

un exemple flagrant :
une écriture dans un fichier le CPU fait presque rien en comparaison du temps d'attente lié à la vitesse hardware d'écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$ time dd if=/dev/zero of=toto count=100000000
ls -lrth toto
^C2566909+0 records in
2566909+0 records out
1314257408 bytes transferred in 34.612 secs (37970775 bytes/sec)
    0m54.65s real     0m0.75s user     0m15.21s system
$ ls -lrth
total 2567684
[...]
-rw-r--r--   1 francois  francois   1.2G Jan  2 17:40 toto
$ rm toto &

la différence est flagrante dans un cas comme celui là aussi bien system que real sont abérants comparés avec user ... mais pourtant c'est très logique vu le type d'activité demandée...

bref pour un utilisateur normal ce genre de concidérations, ça sert à rien à part la curiosité, et seul le temps total doit t’intéresser...


une valeur plus utile à surveiller est le load average parce que là sur x86 la régle est très simple
1 core = un load entre 0 et 5 pas inquiétude à avoir
1 core = un load entre 5 et 10 si ça dure plus de quelques secondes, hors opérations spécialement lourdes comme encodage vidéo à la volée, ou compression à la volée ou ce genre de manipulation là faut s'inquitter...
1 core = un load >10 la il faut s'inquietter voir même tuer les processus les plus gourmands AVANT de réfléchir et d'analyser le problème.

exemple une machine 4 cores avec un load de 20 de moins de 30 secondes : on est dans le second cas.... on s'inquiette pas si au bout de 30 secondes on a vu que ça recommençait à baisser...
autre exemple sur une machine bicores le load et > à 30 là faut vraiment s'alarmer....
pourquoi c'est interessant comme valeur ? parce que ça tiens compte de l'utilisation CPU mais aussi des I/O et de la RAM et d'autres facteurs aussi.... donc comme vue globale c'est parfait

[jlliagre]

@frp31 désolé mais ton analyse du temps passé est incorrecte et tes explications sur les cycles CPU pour le moins confuses et sans lien réel avec ce que time retourne ...

L'application s'est exécutée en 13 minutes 26 secondes.

Un processeur a été sollicité durant 10 minutes et 28 secondes, essentiellement dans du code applicatif et seulement 6.2 secondes dans le noyau.

On peut juste en conclure:
- que le programme n'est probablement pas multi-threadé car sinon, on aurait pu avoir un temps user+sys supérieur aux temps "elapsed".
- qu'il fait pas mal de traitements ou calculs (77% de son temps)
- que les appels systèmes sont efficaces, ne prenant que moins de 1% du temps écoulé
- que le temps passé en I/Os ou autres attentes est de l'ordre de 3 minutes mais on ne peut rien en conclure sans en connaitre le détail.

[LGnord]

Merci beaucoup pour toutes vos réponses et comme demandé je vais donner quelques détails.

Mon but:
J'ai une application qui provoque une out of memory quand son entré est volumineuse. J'ai deux solutions: ajouter de la mémoire ou traiter l'entré comme un flux (et éviter de la charger en mémoire).

J'essaye donc de comprendre si mon application prend du temps en calcul (temps CPU) ou en I/O (lecture depuis le disque et lecture/écriture dans la RAM)

J'ai donc une série d'entrés de plus en plus grande: 1MB, 10MB,...,500MB,...

Comme le montre le résultat suivant, pour une taille inférieure à 100MB, le user time et le real time sont très proches:

100MB

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
real  2m6.788s
user  2m3.207s
sys   0m1.236s

J'ai envie de dire que le temps CPU et le temps des I/O sont parallélisés.


A partir de 200MB, il y a un delta qui apparaît:

200MB

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
real   13m26.318s
user   10m22.007s
sys    0m6.226s

J'ai envie de dire que les I/O prennent le dessus.

Quand la taille est trop grande, une out of memory apparaît avec la mesure suivante:
500MB

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
real   2m24.785s
user   0m13.007s
sys    0m1.007s

J'ai envie de dire que le chargement de mon entré ne consomme pas de CPU. Mais cela me semble en contraction avec le résultat obtenu pour 100MB.

[LGnord]

une valeur plus utile à surveiller est le load average parce que là sur x86 la régle est très simple

Comment calcules-tu le load average?

[jlliagre]

Quelques commentaires:

- Le temps pris à lire/écrire la RAM est du temps CPU, pas du temps I/O.

- Si tu veux quantifier les I/O, regarde les statistiques I/O (iostat) plutôt que la charge CPU.

- Si tu veux quantifier l'occupation mémoire de ton processus et du système, utilises top et free.

- Si les données sont en cache, il n'y a pas d'I/O disque associées à leur lecture.

- Une dégradation de ce type indique en général que tout ne tient pas en RAM et que le système est donc obligé de paginer dans le swap. C'est ce qui doit expliquer le temps perdu.

- Dans ton test à 500 Mo, le programme s'est probablement planté avant d'avoir lu toutes les données.