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

J'essaie de comprendre quelle est la différence entre SLURM de srun et sbatch 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 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 de sbatch testjob.sh.

De faire de 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?

Nombre 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?

L'un particulier de la différence, c'est que srun provoquera une erreur si testjob.sh n'est pas exécutable, c'est à dire l'autorisation chmod +x testjob.sh alors que sbatch seront heureux de vous exécuter. Ce qui se passe "sous le capot" qui provoque ce le cas?

La documentation mentionne également que srun est couramment utilisé à l'intérieur de 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'utilise jamais srun par lui-même?

InformationsquelleAutor dkv | 2017-05-03
  1. 60

    La documentation dit

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

    tout 

    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 tout de suite).

    Si vous utilisez srun dans le fond, avec les & signe, puis vous supprimez le 'blocage' fonction de 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 le 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 au fond). 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 à sbatch et de ne pas srun est emploi arrrays. Comme 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 le même sens dans les deux commandes. 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 immédiatement exécute le script sur la machine distante, tandis que sbatch 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 cette).

    Comment ils interagissent 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 de soumettre un emploi et 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 le --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 la sbatch ou salloc lequel il s'exécute, en vertu de (à partir de ici).

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

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

    • Merci pour la réponse, c'est mieux que tout ce que je pouvais espérer. Un suivi, car c'était l'un de mes points de confusion: pourquoi s'embêter à appeler srun à l'intérieur du script de soumission? Peut-être que je suis confus au sujet de la signification d'une "étape de travail." Par exemple, si j'ai un script qui s'appelle runjob.sh qui contient #!/bin/bash srun myjob.sh, est-t-il une différence entre un appel (un) sbatch runjob.sh vs (b) sbatch myjob.sh vs (c) srun myjob.sh vs (d) srun runjob.sh? (Le dernier est bête, mais je suis curieux).
    • peut-être que vous pourriez parcourir les diapositives d'une session de formation, j'ai prononcé récemment pour des idées sur la façon srun est utilisé à l'intérieur d'un script de soumission: cism.l'ucl.ac.être/Services/Formations/slurm/2016/slurm.pdf
    • Il ressemble à tous les exemples dans les diapositives (ainsi que le tutoriel sur le CECI page) utilisation srun à l'intérieur de la sbatch script de soumission. Cependant, j'ai constaté que les commandes sans srun dans le script de soumission sera exécuté de la même manière. Est-il réellement une différence entre les quatre invocations je l'ai mentionné ci-dessus?
    • Tous les exemples fonctionnera de la même manière que si (1) la répartition est pour un CPU et (2) le programme est purement séquentielle. Pour voir les différences, demande plus d'une tâche. Une autre différence est que si vous n'utilisez pas srun dans sbatch, le sstat commande ne sera pas de retour toutes les informations utiles
    • Comment avez-vous fait de la diapositive 11, @damienfrancois? Je veux dire, mon #SBATCH --argument ne sont pas correctement mis en évidence, et ressemblent à des commentaires (dans Vim). Avez-vous un thème personnalisé?
    • J'utilise un custom Slurm de la syntaxe de plugin: github.com/SchedMD/slurm/tree/master/contribs/...
    • cette version peut plus uptodate: github.com/damienfrancois/slurm-helper/blob/master/slurm.vim

    InformationsquelleAutor damienfrancois
  2. 4

    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 sous. 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.

    La 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.

    La 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.

    InformationsquelleAutor dkv