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, 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 tableau, 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-1127.10.1.el7.x86_64 *
* Project: P_ccin2p3 *
**********************************************************************
* Submitted on: Mon Aug 17 11:37:21 CEST 2020 *
* Started on: Mon Aug 17 11:37:33 CEST 2020 *
**********************************************************************
Hello World!
Mon repertoire de travail est:
/scratch/5947764.1.long
sur le serveur:
ccwsge0632
Done!!
**********************************************************************
* Submitted on: Mon Aug 17 11:37:21 CEST 2020 *
* Started on: Mon Aug 17 11:37:33 CEST 2020 *
* Ended on: Tue Aug 18 11:58:25 CEST 2020 *
* Exit status: 0 *
**********************************************************************
* Requested *
* CPU cores: 1 core(s) *
* CPU time: 48:00:00 (172800 seconds) (1) *
**********************************************************************
* Consumed *
* wallclock: 24:20:52 (87652 seconds) *
* CPU time: 24:09:01 (86941 seconds) *
* CPU scaling factor: 10.87 *
* normalized CPU time: 262:30:52 (945052 HS06 seconds) *
* CPU efficiency: 99 % (2) *
* vmem: 2.374 GB (3) *
* maxvmem: 2.403 GB (3) *
* maxrss: 487.258 MB (3) *
**********************************************************************
Notes:
(1) Formula: requested CPU time * requested CPU cores
(2) Formula: CPU time / ( wallclock * requested CPU cores )
(3) See man sge_accounting
For more information: qacct -j 5947764
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 répertoire 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 vers 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. 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 “normalized CPU time” 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.