Comment chronométrer un programme Linux

Vous voulez analyser combien de temps d’horloge murale, de temps de noyau, etc., un programme Linux prend pour s’exécuter ? Qu’il s’agisse de tests de performances, d’optimisation de code ou simplement de curiosité générale, ce guide rapide vous aidera à démarrer !

Synchronisation des programmes Linux

Chronométrer un programme Linux aide à comprendre combien de temps a été passé. Le Linux polyvalent time La commande peut être utilisée pour cela. le time La commande mesure l’heure réelle (c’est-à-dire l’heure de l’horloge murale), l’heure utilisateur et l’heure système. Le temps utilisateur est le temps pendant lequel le programme s’exécute en mode utilisateur, ou en d’autres termes, en dehors du noyau. L’heure sys est l’heure à laquelle le programme s’exécute à l’intérieur du noyau.

Il est important de noter que le temps utilisateur et le temps système sont respectivement le temps CPU réel passé en mode utilisateur et dans le noyau. En d’autres termes, lorsqu’un programme est bloqué pendant un certain temps et n’utilise pas le processeur, ce temps ne comptera pas pour utilisateur ou alors sys fois. Sachant cela, nous pouvons mesurer avec précision combien de temps CPU effectif a été utilisé (en les combinant).

Le Linux temps Outil

Étant donné que utilisateur et sys times ne rapportent que le temps CPU, alors que réel time indique l’heure réelle de l’horloge murale, il est (ainsi) très courant de voir le time sortie de retour d’outil où une combinaison de utilisateur + système n’est pas égal réel temps. Un exemple peut être vu lors de la synchronisation sleep:

time sleep 1

Ici, nous avons chronométré le sleep commande à l’aide du time outil. Comme on peut le voir, notre réel l’heure (1,001 secondes) correspond à l’heure de notre horloge murale et à l’heure demandée (sleep 1 demande un sommeil d’une seconde) très bien. Nous voyons également qu’il a fallu consacrer très peu de temps CPU à la commande dans son ensemble : combiner utilisateur + système temps, nous voyons que seulement 0,001 secondes ont été dépensées.

On peut aussi, probablement à tort, en déduire que le noyau n’était pas impliqué dans cette commande, car le système le temps est effectivement 0. Cependant, comme le time Le manuel indique : « Lorsque le temps d’exécution d’une commande est très proche de zéro, certaines valeurs (par exemple, le pourcentage de CPU utilisé) peuvent être signalées comme zéro (ce qui est faux) ou un point d’interrogation. »

Utilisant temps Pour la mesure des performances

On peut utiliser time pour évaluer combien de temps prendront des actions données (c’est-à-dire l’heure de l’horloge murale) et combien de temps CPU elles ont consommé en le faisant. À titre d’exemple simple, nous pourrions évaluer si un cache du système de fichiers fonctionne sur notre système. Pour ce faire, nous pourrions sauter dans le /usr répertoire, qui pourrait facilement contenir 200 000 à 500 000 fichiers sur une installation Linux courante.

Une fois là-bas, nous pouvons utiliser le find outil, chronométré par time pour évaluer combien de temps il faudrait pour parcourir tous les dossiers et répertorier tous les fichiers dans le /usr annuaire:

cd /usr
time find . >/dev/null 2>&1

Comme nous pouvons le voir, il faut 12,484 secondes pour lister tous les fichiers dans le /usr répertoire (et en dessous). Nous avons redirigé la sortie stdout (sortie standard) de la commande vers >/dev/null et rediriger également toutes les erreurs stderr (erreur standard) vers /dev/null en utilisant une redirection de stderr vers stdout, c’est-à-dire 2>&1.

Nous voyons également que notre temps CPU est de 1,043 secondes (utilisateur) + 2,908 secondes (sys) pour un total de 3,951 secondes de temps CPU.

Testons-le une autre fois en effaçant nos inodes (et autres) cache(s) :

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
cd /usr
time find . >/dev/null 2>&1

La première commande supprimera le cache des inodes, les dentries (entrées de répertoire) et le cache de page. Cette fois, le résultat est revenu un peu plus vite, avec 1,255 seconde de gain sur la commande. Probablement un cache physique sur disque a aidé ici.

Pour montrer à quel point la mise en cache Linux fonctionne en général, réexécutons la commande mais cette fois sans supprimer les caches Linux :

Toute une différence ! Nous constatons une grande réduction du temps requis dans les trois zones chronométrées et notre commande s’exécute en moins d’une demi-seconde !

Utilisant temps Pour l’optimisation du code

Une fois que nous nous sentons à l’aise d’utiliser le time commande à la ligne de commande, nous pouvons étendre son utilisation pour optimiser nos scripts et notre code Bash. Par exemple, une approche couramment utilisée par certains professionnels consiste à exécuter une commande donnée plusieurs fois, comme 1000 exécutions, et à calculer le temps total (ou moyen) de ces exécutions.

Ensuite, une commande alternative peut être utilisée. Cette commande alternative (ou solution/mise en œuvre – c’est-à-dire plusieurs commandes prises ensemble comme un seul morceau de code à chronométrer) peut ensuite être chronométrée à nouveau. Sous Linux (ou plus précisément dans le codage Bash, etc.), il existe souvent de nombreuses façons d’aborder un problème donné ; il existe généralement plusieurs outils disponibles pour obtenir/atteindre le même résultat.

Tester celui qui fonctionne le mieux optimise le temps d’exécution du programme et potentiellement d’autres facteurs tels que les E/S disque (réduction de l’usure du disque) ou l’utilisation de la mémoire (permettant à plus de programmes de s’exécuter sur la même instance). Pour optimiser l’heure de l’horloge murale, un certain outil utilise, en moyenne, ainsi que le temps CPU consommé par l’outil (un autre facteur/considération d’optimisation important) peut être mesuré par le time outil.

Explorons un exemple pratique d’utilisation de la ligne de commande pour exécuter une commande que nous souhaitons utiliser dans l’un de nos scripts. La commande obtiendra une liste de processus et affichera la deuxième colonne. Nous utilisons les deux awk et sed pour ce faire, et exécutez chaque commande 1000 fois pour voir la différence de performances globales.

time for ((i=1;i<=1000;i++)); do ps -ef | awk '{print $2}' >/dev/null 2>&1; done
time for ((i=1;i<=1000;i++)); do ps -ef | sed 's|^[^ ]+[ t]+||;s|[ t].*||' >/dev/null 2>&1; done

Bien qu’elle ait l’air plus complexe (elle utilise une double expression régulière pour analyser la deuxième colonne), notre deuxième commande est un peu plus rapide que notre première commande en ce qui concerne l’heure de l’horloge murale.

En utilisant une configuration très similaire (c’est-à-dire time for ((i=1;i<=1000;i++)); do command_to_be_timed >/dev/null 2>&1; done où command_to_be_timed est la commande à tester pour l’horloge murale ou le temps CPU), on peut tester n’importe quelle commande, ou ensemble de commandes (comme c’est le cas ici ; nous avons utilisé à la fois le ps et awk/sed commandes).

Suivre ces étapes pour plusieurs commandes chronophages (dans n’importe quel script Linux) nous aidera à réduire le temps d’exécution global et/ou (si vous optimisez vers un temps CPU réduit) la charge système de nos scripts.

Si vous souhaitez en savoir plus sur les expressions régulières, Comment modifier du texte à l’aide d’expressions régulières avec l’éditeur de flux sed est susceptible de vous intéresser.

Emballer

Dans cet article, nous avons exploré Linux time commander. Nous avons clarifié ce réel, utilisateur et système fois indiquent et comment ces deux derniers sont liés à l’utilisation du processeur. Nous avons également examiné plusieurs exemples d’utilisation temps de manière pratique.

Si vous avez aimé lire cet article, jetez un œil à Asserts, erreurs et plantages : quelle est la différence ? et Qu’est-ce que Stack Smashing ? Peut-il être corrigé ?.