Démarrage simultané des travaux -hold_jid sur Sun Grid Engine

Comment puis-je démarrer un tas de travaux SGE (Sun Grid Engine) où certains utilisent l'option -hold_jid, mais sans nécessiter de tri intelligent de l'ordre de qsub soumissions.Démarrage simultané des travaux -hold_jid sur Sun Grid Engine

Si je fais ce everthing est très bien, où job2 attend job1 pour terminer:

qsub     job1.sh 
qsub -hold_jid job1.sh job2.sh    # OK: job2 waits for job1

Toutefois, si je soumets à la place dans un ordre différent, comme indiqué ci-dessous, job2 commence à tort sans attendre job1. Vraisemblablement parce que SGE voit qu'il n'y a pas d'emploi1 à attendre puisque job1 n'a pas encore été soumis.

qsub -hold_jid job1.sh job2.sh 
qsub     job1.sh    # BAD: job2 does not wait for job1

J'ai essayé l'option de maintien de l'utilisateur -h puis libérer la cale de l'utilisateur avec qalter, mais libérer la main de l'utilisateur semblent aussi libérer la -hold_jid cale:

qsub -h -hold_jid job1.sh job2.sh 
qsub -h     job1.sh 
qalter -h U job*.sh      # BAD: job2 does not wait for job1

Construire un arbre de dépendance et commencer à soumettre les travaux du niveau de feuille résoudraient mon problème. Cependant, je voudrais éviter cela. J'utilise Sun Grid Engine 6.2u3 sur RHEL 6.

Source

2017-09-16 Axel Bregnsbo

Je pense * que cela peut être dû au fait que vos travaux ne sont pas nommés de façon unique en attente. Par exemple job1 techniquement terminé (job1 passé) et est stocké quelque part dans le journal de comptabilité SGE. Ainsi, lorsque vous soumettez job2, même si job1 a été exécuté depuis longtemps, job2 sera toujours exécuté. Pour tester, essayez de nommer les travaux en utilisant des noms uniques ou utilisez jobid. – Vince

"mais la libération de l'utilisateur semble également libérer le hold" -hold_jid' ": avec d'autres tests, j'ai découvert que ce n'est pas le cas. 'qsusb' interprète l'option' -hold_jid' immédiatement lorsque la commande est émise et non lorsque le travail est planifié. Ainsi, la commande 'qsub -h -hold_jid job1.sh job2.sh' cherchera' job1.sh' dans la file d'attente, voyez qu'il n'y en a pas, et placez job2 dans la file d'attente sans attente. –

Si @Vince a raison et que SGE attend vraiment des travaux qui n'ont pas encore été lancés, la seule façon d'atteindre votre objectif serait d'ajouter une pièce unique à tous vos noms d'emplois.

L'utilisation de jobid ne fonctionnera pas si les travaux ne sont pas lancés dans le bon ordre car vous ne pouvez pas deviner le travail d'un travail futur. Si job1 n'a pas été lancé encore, job2 exécution qsub ne pouvait pas deviner ce qui sera job1 jobid attendre ...

Par exemple:

uniqueID=`date "+%Y-%m-%d_%H-%M-%S"` 
qsub -N "job2_$uniqueID" -hold_jid "job1_$uniqueID" job2.sh 
qsub -N "job1_$uniqueID" job1.sh

De cette façon, quel que soit l'ordre de lancer l'emploi, job2 attendra job1.

Source

2017-09-17 17:10:49

Ne fonctionne pas. Exactement le même comportement que dans ma question ci-dessus, c'est-à-dire que le premier lancement de job1 fait patienter job2, mais le premier lancement de job2 ne le tient pas. –

Démarrage simultané des travaux -hold_jid sur Sun Grid Engine

Répondre

Questions connexes