Informations sur les jobs terminés

La commande qacct

La commande qacct fourni des informations sur l’utilisation passée de UGE. Un enregistrement de comptabilité est écrit dans le fichier accounting pour chaque job terminé. Ce fichier contient les données des jobs terminés durant les cinq derniers jours. Les données plus anciennes sont dans le fichier accounting correspondant au mois d’exécution.

Par défaut, la commande qacct permet d’accéder aux données des jobs cinq jours en arrière. Pour obtenir l’information sur un job particulier déjà terminé (depuis moins de cinq jours), tapez :

% qacct -j <jobid>

Pour accéder aux données qui datent de plus de cinq jours, utilisez l’option “-f” pour sélectionner le fichier d’accounting du mois concerné :

% qacct -o <loginname> -j -f /opt/sge/ccin2p3/common/accounting.YYYY.MM

Note

Pour plus de détails sur la signification des valeurs renvoyées, voir la section Accounting et temps CPU.

Le code de retour

Dans la sortie de la commande qacct -j , les lignes failed et exit_status peuvent vous permettre de comprendre la raisons pour laquelle un job a échoué. Si tous les deux sont égale à zéro, votre job a été exécuté et bien terminé :

...
failed       0
exit_status  0
...

Sinon, il y a eu un problème.

exit_status

La valeur exit_status renseigne sur la cause de l’arrêt d’un job. Si une limite soft est dépassée, les signaux suivants sont envoyés :

exit_status corresponding signal
152 = 24 (SIGXCPU) + 128 SIGXCPU : dépassement de cpu (_cpu) ou mémoire (_rss)
138 = 10 (SIGUSR1) + 128 SIGUSR1 : dépassement du temps elapsed (_rt)
153 = 25 (SIGXFSZ) + 128 SIGXFSZ : dépassement de taille de fichier (_fsize)

Si une limite hard est dépassée, un signal SIGKILL 137 = 9 (SIGKILL) + 128 est envoyé. Les exit_status inférieurs à 128 sont définis par l’utilisateur.

Un tableau complet avec un bref résumé de la signification de chaque signal d’arrêt Unix est disponible via man 7 signal.

failed

Une valeur failed différente de zéro indique qu’un job n’a pas pu démarrer sur un serveur de calcul :

failed consequence
1: assumedly before job Job could not be started
7: before prolog Job could not be started
8: in prolog Job could not be started
10: in pestart Job could not be started
19: before writing exit_status  
21: in recognizing job  
25: rescheduling Job ran, job will be rescheduled
26: opening input/output le Job could not be started, stderr/stdout could not be opened
28: changing into working directory Job could not be started, error changing to start directory
29: invalid execution state  
37: qmaster enforced h rt limit  
100: assumedly after job Job ran, job killed by a signal

Pour en savoir plus de différents options de la commande qacct , voir man qacct. Pour déchiffrer la sortie de la commande qacct, voir man accounting.

Les logs

Par défaut, lors de la soumission d’un job batch, deux fichiers seront créés dans votre HOME une fois les jobs terminés :

<jobname>.o<jobid> (sortie standard stdout)
<jobname>.e<jobid> (erreur standard stderr)

Lors de la soumission d’un job paramétrique, ces fichiers seront nommés (il y aura autant de fichiers qu’il y a de tâches) :

<jobname>.o<jobid>.<taskid>
<jobname>.e<jobid>.<taskid>

Prenons l’exemple d’un job Hello World dont les deux fichiers de logs se trouvent dans votre HOME :

hello_world.sh.e<jobid>   # vide, s'il n'y a pas eu d'erreurs
hello_world.sh.o<jobid>

La sortie peut être visualisée, par exemple, avec la commande cat :

% cat hello_world.sh.o5947764
***************************************************************
*                  Grid Engine Batch System
*           IN2P3 Computing Centre, Villeurbanne FR
***************************************************************
* User:                    login
* Group:                   ccin2p3
* Jobname:                 hello_world.sh
* JobID:                   5947764
* Queue:                   long
* Worker:                  ccwsge0632.in2p3.fr
* Operating system:        Linux 3.10.0-957.12.2.el7.x86_64
* Project:                 P_ccin2p3
***************************************************************
* Submitted on:            Tue Sep 31 16:22:23 2019
* Started on:              Tue Sep 31 16:29:15 2019
***************************************************************

Hello World!

Mon repertoire de travail est:
/scratch/5947764.1.long
sur le serveur:
ccwsge0632
Done!!

***************************************************************
* Ended on:                Tue Sep 31 16:29:15 2019
* Exit status:             0
* Consumed
*   cpu (HS06):            11:34:10
*   cpu scaling factor:    11.350000
*   cpu time:              3669 / 259200
*   efficiency:            90 %
*   io:                    13.87236
*   vmem:                  1.129G
*   maxvmem:               6.240G
*   maxrss:                3.473G
***************************************************************

Les sorties standards stdout et stderr des jobs sont redirigées vers le disque local du serveur de calcul pendant l’exécution de votre job puis recopiées, par défaut, dans votre espace HOME à la fin du job. Pour changer le positionnement et le nom des sorties stdout et stderr, ainsi que le jobname de votre job, voir la section Options de soumission.

Attention

Il est préférable d’avoir des fichiers de sortie stdout / stderr de taille raisonnable (moins de 100 Mo). Les fichiers plus gros doivent être redirigés vers le TMPDIR et copié dans un espace approprié en fin de job, plutôt que le HOME comme c’est le cas par défaut.

Accounting et temps CPU

Le temps “wallclock” d’un job est le temps passé entre le début du job et sa fin, montre en main. Le temps CPU est quant à lui le temps passé par le job à utiliser réellement le CPU. Ce temps CPU peut être sensiblement inférieur au wallclock dans le cas d’un job avec beaucoup d’entrées-sorties (I/O) : on parle dans ce cas de “job inefficace”.

Par ailleurs, dans le cas d’un job multi-cœur, le temps CPU peut être supérieur au wallclock car l’ordonnanceur fournit le temps CPU cumulé sur l’ensemble des cœurs alors que le wallclock est calculé sur un temps absolu, indépendant du nombre de cœurs utilisés.

On a donc en principe :

wallclock time > CPU_time / #coeurs

Au CC-IN2P3, le temps CPU est couramment exprimé en temps “HS06”, une unité de normalisation qui dépend de la puissance des cœurs. Par exemple, pour un temps CPU de 3h sur un (ou des) cœur(s) ayant un facteur de puissance de 11 HS06, on a la relation :

CPU time (h.HS06) = 3 (h) * 11 (HS06) = 33 h.HS06

Dans le stdout des jobs, la ligne “cpu (HS06)”” indique le temps CPU en temps (jours:heures:minutes:secondes).HS06. Le “cpu scaling factor” correspond au facteur HS06 du processeur et le “cpu time” indique le temps CPU en secondes. Dans le résultat d’une commande qacct, le “wallclock” correspond, comme son nom l’indique, au temps wallclock (en secondes), et le “cpu” est le temps CPU en s.HS06.