SLURM `srun` vs` sbatch` et leurs paramètres

Question

Je suis en train d'essayer de comprendre quelle est la différence entre SLURM de l' srun et sbatch des commandes. Je serai heureux avec une explication générale, plutôt que des réponses aux questions suivantes, mais voici quelques points particuliers de la confusion qui peut être un point de départ et de donner une idée de ce que je suis à la recherche pour.

Selon la documentation, srun est pour l'envoi de tâches, et sbatch est pour l'envoi de tâches pour exécution ultérieure, mais en pratique, la différence est claire pour moi, et leur comportement semble être le même. Par exemple, j'ai un cluster avec 2 nœuds, chacun avec 2 Processeurs). Si j'exécute srun testjob.sh & 5x de suite, il faudra bien la queue de la cinquième jusqu'à ce qu'un CPU devient disponible, tout comme l'exécution d' 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 celui que j'ai ne peut pas faire avec les autres, et pourquoi?

La plupart des arguments pour les deux commandes sont les mêmes. Celles qui semblent les plus pertinentes sont --ntasks, --nodes, --cpus-per-task, --ntasks-per-node. Comment sont-ils liés les uns aux autres, et en quoi elles diffèrent pour srun vs sbatch?

Une différence particulière est qu' srun entraînera une erreur, si testjob.sh n'ont pas d'exécutable, c'est à dire l'autorisation chmod +x testjob.sh alors qu' sbatch seront heureux de vous exécuter. Ce qui se passe "sous le capot" qui provoque ce le cas?

La documentation mentionne également qu' srun est couramment utilisé à l'intérieur de l' sbatch scripts. Cela conduit à la question: Comment ils interagissent les uns avec les autres, et qu'est-ce que le "canonique" cas d'utilisation pour chacun d'eux? Plus précisément, j'ai jamais utiliser srun par soi-même?

Answer 1

La documentation dit

srun is used to submit a job for execution in real time

alors que

sbatch is used to submit a job script for later execution.

Ils acceptent tous deux pratiquement le même jeu de paramètres. La principale différence est que, srun est interactif et de blocage (vous obtenez le résultat de votre terminal et vous ne pouvez pas écrire d'autres commandes jusqu'à ce qu'il est fini), alors que sbatch est le traitement par lot et non-bloquant (les résultats sont écrits dans un fichier et vous pouvez envoyer d'autres commandes).

Si vous utilisez srun dans l'arrière-plan avec l' & , puis vous retirez le "blocage" srun, qui devient interactif mais non bloquant. Il est encore interactif bien, ce qui signifie que la sortie de l'encombrement de votre terminal, et l' srun processus 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 utilisent des stdout ou pas). Et ils seront tués si l'ordinateur auquel vous vous connectez pour la soumission de travaux est en cours de redémarrage.

Si vous utilisez sbatch, vous vous soumettez votre travail et il est géré par Slurm ; vous pouvez vous déconnecter, de 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 celui que j'ai ne peut pas faire avec les autres, et pourquoi?

Une fonctionnalité qui est disponible à l' sbatch et de ne pas srun est travail arrrays. En tant que srun peut être utilisé à l'intérieur d'un sbatch script, il n'y a rien que vous ne pouvez pas faire avec sbatch.

Comment sont-ils liés les uns aux autres, et en quoi elles diffèrent pour srun vs sbatch?

Tous les paramètres --ntasks, --nodes, --cpus-per-task, --ntasks-per-node ont la même signification dans les deux commandes. C'est vrai pour presque tous les paramètres, à l'exception notable de l' --exclusive.

Ce qui se passe "sous le capot" qui provoque ce le cas?

srun immédiatement exécute le script sur la machine distante, tandis que sbatch des copies le script dans un espace de stockage interne, puis l'envoie sur le nœud de calcul lorsque le travail commence. Vous pouvez vérifier ceci en modifiant votre script de soumission après qu'il a été soumis; les modifications ne seront pas prises en compte (voir ceci).

Comment interagissent-ils les uns avec les autres, et qu'est-ce que le "canonique" cas d'utilisation pour chacun d'eux?

Vous utilisez généralement sbatch soumettre un travail et d' srun dans le script de soumission à créer des étapes de travail que Slurm les appelle. srun est utilisé pour lancer le processus. Si votre programme est un parallèle MPI programme, srun prend en charge la création de tous les processus MPI. Si non, srun permettra de exécuter votre programme autant de fois que spécifié par l' --ntasks option. Il existe de nombreux cas d'utilisation en fonction de si votre programme est mis en parallèle ou non, a une longue durée ou pas, est composé d'un seul fichier exécutable ou pas, etc. À moins d'indication contraire, srun hérite par défaut, les options pertinentes de l' sbatch ou salloc qui s'exécute sous (à partir d' ici).

Plus précisément, j'utilise jamais srun par lui-même?

D'autres que pour les petits tests, aucun. Une utilisation courante est srun --pty bash pour obtenir un shell sur un calcul d'emploi.

Answer 2

Ce n'est pas réellement répondre pleinement à la question, mais voici quelques informations que j'ai trouvé qui peut être utile pour quelqu'un dans le futur:

---

À partir d'un sujet que j'ai trouvé avec une question similaire:

En un mot, sbatch et salloc allouer des ressources pour le travail, tandis que d'srun lance en parallèle des tâches dans l'ensemble de ces ressources. Lorsqu'il est invoqué dans un travail de répartition, srun lancera en parallèle des tâches au sein de certaines ou de toutes les ressources allouées. Dans ce cas, srun hérite par défaut, les options pertinentes de la sbatch ou salloc lequel il s'exécute. Vous pouvez ensuite (normalement) à fournir srun différentes options qui remplacera ce qu'il reçoit par défaut. Chaque invocation de srun dans un travail qui est connu comme une étape de travail.

srun peut également être invoquée à l'extérieur d'un travail de répartition. Dans ce cas, srun demandes de ressources, et lorsque ces ressources sont attribuées, lance les tâches entre ces ressources comme un simple emploi et de l'étape de travail.

Il y a un relativement nouveau site web qui va plus dans le détail concernant l'-B et-options exclusives.

doc/html/cpu_management.shtml

---

Des informations supplémentaires à partir de la SLURM FAQ page.

Le srun de commande dispose de deux modes de fonctionnement. Tout d'abord, si pas exécuter à l'intérieur d'un travail (c'est à dire pas dans un Slurm répartition de l'emploi créé par salloc ou sbatch), puis il va créer un emploi d'allocation et pondre une demande. Si la course au sein d'une allocation, le srun commande que génère l'application. Pour cette question, nous nous contenterons d'aborder le premier mode de fonctionnement et de comparer la création d'un emploi d'allocation de l'aide de l'sbatch et srun commandes.

Le srun de commande est conçu pour une utilisation interactive, avec quelqu'un de la surveillance de la sortie. La sortie de l'application est considérée comme sortie de la srun de commande, généralement dans le terminal de l'utilisateur. Le sbatch de commande est conçu pour présenter un script pour exécution ultérieure et sa sortie est écrite dans un fichier. Options de commande utilisés dans le travail de répartition sont presque identiques. Le plus notable différence dans les options, c'est que le sbatch de commande prend en charge le concept de travail tableaux, alors que srun ne le fait pas. Une autre différence significative est dans la tolérance aux pannes. Les échecs impliquant sbatch emplois sont souvent le résultat de l'emploi à requeued et exécuté à nouveau, alors que l'échec impliquant srun généralement un message d'erreur générée par l'attente que l'utilisateur aura à répondre de manière appropriée.