Version imprimable
Bonjour,
J'utilise la commande time pour faire une mesure de performance et j'obtiens le résultat suivant:
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?Code:
2
3
Cette mesure est stable et il n'y a pas d'autres applications qui tournent sur ma machine.
Merci de votre aide.
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.
la différence est pas si grande que ça et semble tout à fait cohérante à prioriCitation:
Envoyé par LGnord
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
:mrgreen: exagéré volontairement pour mieux me faire comprendre :mrgreen:Code:
2
3
4
5
6
7
8
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 :
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...Code:
2
3
4
5
6
7
8
9
10
11
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...
:mrgreen:
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
:mrgreen:
@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.
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
J'ai envie de dire que le temps CPU et le temps des I/O sont parallélisés.Code:
2
3
A partir de 200MB, il y a un delta qui apparaît:
200MB
Code:
2
3
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
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.Code:
2
3
Comment calcules-tu le load average?Citation:
Envoyé par frp31
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.