SLURM 'srun' vs ' sbatch` et leurs paramètres
j'essaie de comprendre quelle est la différence entre les commandes srun et sbatch . Je me contenterai d'une explication générale, plutôt que de réponses spécifiques aux questions suivantes, Mais voici quelques points de confusion spécifiques qui peuvent être un point de départ et donner une idée de ce que je cherche.
selon la documentation , srun est pour soumettre des travaux, et sbatch est pour soumettre des travaux pour exécution ultérieure, mais la différence pratique est peu claire pour moi, et leur comportement semble être le même. Par exemple, j'ai un cluster avec 2 noeuds, chacun avec 2 CPU. Si j'exécute srun testjob.sh & 5x d'affilée, il mettra en file d'attente la cinquième tâche jusqu'à ce qu'un CPU soit disponible, comme le fera l'exécution sbatch testjob.sh .
Pour rendre la question plus concrète, je pense qu'un bon endroit pour commencer peut-être: quelles sont les choses que je peux faire avec l'un que je ne peux pas faire avec l'autre, et pourquoi?
plusieurs arguments des deux commandes sont les mêmes. Ceux qui semblent les plus pertinents sont: --ntasks , --nodes , --cpus-per-task , --ntasks-per-node . comment sont-ils reliés entre eux, et comment diffèrent-ils pour srun vs sbatch ?
une différence particulière est que srun causera une erreur si testjob.sh n'a pas la permission exécutable i.e. chmod +x testjob.sh alors que sbatch l'exécutera avec plaisir. Ce qui se passe "sous le capot" qui provoque ce le cas?
la documentation mentionne également que srun est couramment utilisé dans les scripts sbatch . Cela conduit à la question: comment interagissent-ils entre eux, et quelle est l'utilisation "canonique" pour chacun d'eux? Plus précisément, est-ce que j'utiliserais srun tout seul?
2 réponses
la documentation dit
srun is used to submit a job for execution in real time
tandis que
sbatch is used to submit a job script for later execution.
ils acceptent tous deux pratiquement le même ensemble de paramètres. La principale différence est que srun est interactif et le blocage (vous obtenez le résultat dans votre terminal et vous ne pouvez pas écrire d'autres commandes jusqu'à ce qu'il soit terminé), tandis que sbatch est le traitement par lots et non-blocage (les résultats sont écrits à un fichier et vous pouvez soumettre d'autres commandes immédiatement).
si vous utilisez srun en arrière-plan avec le signe & , vous supprimez alors la fonction de" blocage " de srun , qui devient interactive mais non-bloquante. Il est encore interactif, ce qui signifie que la sortie va encombrer votre terminal, et les processus srun sont liés à votre terminal. Si vous vous déconnectez, vous perdrez le contrôle sur eux, ou ils pourraient être tués (selon qu'ils sont stdout ou pas). Et ils sera tué si la machine à laquelle vous vous connectez pour soumettre des travaux est redémarrée.
si vous utilisez sbatch , vous soumettez votre travail et il est géré par Slurm ; vous pouvez déconnecter, tuer votre terminal, etc. sans conséquence. Votre travail n'est plus lié à un processus en cours d'exécution.
quelles sont les choses que je peux faire avec l'un que je ne peux pas faire avec l'autre, et pourquoi?
une caractéristique qui est disponible à sbatch et non à srun est job arrrays . Comme srun peut être utilisé dans un script sbatch , il n'y a rien que vous ne puissiez faire avec sbatch .
comment sont-ils reliés entre eux, et en quoi diffèrent-ils pour srun vs sbatch?
tous les paramètres --ntasks , --nodes , --cpus-per-task , --ntasks-per-node ont le même sens dans les deux commande. C'est vrai pour presque tous les paramètres, à l'exception notable de --exclusive .
Ce qui se passe "sous le capot" qui provoque ce le cas?
srun exécute immédiatement le script sur l'hôte distant, tandis que sbatch copie le script dans un stockage interne et le télécharge ensuite sur le noeud de calcul lorsque la tâche commence. Vous pouvez vérifier cela en modifiant votre script de soumission après avoir été soumis, les modifications ne seront pas prises en compte (Voir ci-après ).
comment interagissent-ils les uns avec les autres, et quelle est l'utilisation "canonique" de chacun d'eux?
vous utilisez généralement sbatch pour soumettre un travail et srun dans le script de soumission pour créer des étapes de travail comme Slurm les appelle. srun est utilisé pour lancer le processus. Si votre programme est parallèle Le programme MPI, srun s'occupe de créer tous les processus MPI. Sinon, srun exécutera votre programme autant de fois que spécifié par l'option --ntasks . Il existe de nombreux cas d'utilisation selon que votre programme est parallélisé ou non, qu'il a un long temps de fonctionnement ou non, qu'il est composé d'un seul exécutable ou non, etc. Sauf indication contraire, srun hérite par défaut des options pertinentes du sbatch ou salloc sous lequel il s'exécute (à partir de ici ).
en particulier, est-ce que j'utiliserais le srun tout seul?
autres que pour les petits essais, no. Une utilisation courante est srun --pty bash pour obtenir un shell sur un calcul d'emploi.
cela ne répond pas entièrement à la question, Mais voici plus d'informations que j'ai trouvé qui pourraient être utiles pour quelqu'un dans l'avenir:
à Partir d'un sujet j'ai trouvé avec une question similaire:
en bref, sbatch et salloc allouent des ressources à la tâche, tandis que srun lance des tâches parallèles à travers ces ressources. Lorsqu'il est invoqué dans le cadre d'une attribution de tâches, srun lancera des tâches parallèles sur une partie ou la totalité des ressources allouées. Dans ce cas, srun hérite par défaut des options pertinentes de sbatch ou salloc sous lesquelles il s'exécute. Vous pouvez alors (habituellement) fournir srun différentes options qui supplanteront ce qu'il reçoit par défaut. Chaque invocation de srun dans un emploi est connue comme une étape de travail.
Le srunpeut aussi être invoqué à l'extérieur d'une attribution d'emploi. Dans ce cas, srun demande des ressources, et lorsque ces ressources sont accordés, lance des tâches à travers ces ressources comme un seul emploi et étape de travail.
il y a une page Web relativement nouvelle qui donne plus de détails sur les options-B et --exclusive.
doc / html / cpu_management.shtml
informations supplémentaires sur la page SLURM FAQ .
la commande srun a deux différentes les modes de fonctionnement. Tout d'abord, s'il n'est pas exécuté dans le cadre d'un emploi existant (c.-à-d. pas dans le cadre d'une attribution D'emploi Slurm créée par salloc ou sbatch), il créera une attribution d'emploi et générera une demande. Si elle est exécutée à l'intérieur d'une allocation existante, la commande srun ne fait que lancer l'application. Pour cette question, nous n'aborderons que le premier mode d'opération et comparerons la création d'une attribution de tâches à l'aide des commandes sbatch et srun.
la commande srun est conçue pour utilisez, avec quelqu'un qui surveille la sortie. La sortie de l'application est considérée comme la sortie de la commande srun, typiquement au terminal de l'utilisateur. La commande sbatch est conçue pour soumettre un script pour une exécution ultérieure et sa sortie est écrite dans un fichier. Les options de commande utilisées dans l'attribution des tâches sont presque identiques. La différence la plus notable dans les options est que la commande sbatch supporte le concept des tableaux de tâches, contrairement à srun. Une autre différence significative est la tolérance aux défauts. Les échecs impliquant des tâches sbatch entraînent généralement la requalification et l'exécution de nouveau de la tâche, tandis que les échecs impliquant srun entraînent généralement un message d'erreur généré avec l'espoir que l'utilisateur répondra de manière appropriée.