sbatch - En ligne dans le Cloud

PROGRAMME:

Nom

sbatch - Soumettez un script batch à Slurm.

SYNOPSIS

sbat [Options] scénario [args...]

DESCRIPTION

sbatch soumet un script batch à Slurm. Le script batch peut être donné à sbatch via un
nom de fichier sur la ligne de commande, ou si aucun nom de fichier n'est spécifié, sbatch lira dans un
script à partir de l'entrée standard. Le script batch peut contenir des options précédées de "#SBATCH"
avant toute commande exécutable dans le script.

sbatch se ferme immédiatement après que le script a été transféré avec succès vers le Slurm
contrôleur et attribué un ID de tâche Slurm. Le script batch n'est pas forcément accordé
ressources immédiatement, il peut rester dans la file d'attente des travaux en attente pendant un certain temps avant son
les ressources nécessaires deviennent disponibles.

Par défaut, la sortie standard et l'erreur standard sont dirigées vers un fichier du nom
"slurm-%j.out", où le "%j" est remplacé par le numéro d'attribution du travail. Le fichier sera
être généré sur le premier nœud de l'allocation de travail. Autre que le script batch lui-même,
Slurm n'effectue aucun déplacement des fichiers utilisateurs.

Lorsque l'allocation de travail est finalement accordée pour le script batch, Slurm exécute une seule copie
du script batch sur le premier nœud de l'ensemble des nœuds alloués.

Le document suivant décrit l'influence des différentes options sur l'attribution des
cpus aux travaux et aux tâches.
http://slurm.schedmd.com/cpu_management.html

OPTIONS

-a, --déployer=<index>
Soumettre un tableau de tâches, plusieurs tâches à exécuter avec des paramètres identiques. Les
index La spécification identifie les valeurs d'index de tableau à utiliser. Plusieurs
les valeurs peuvent être spécifiées en utilisant une liste séparée par des virgules et/ou une plage de valeurs avec
un séparateur "-". Par exemple, "--array=0-15" ou "--array=0,6,16-32". Une étape
La fonction peut également être spécifiée avec un suffixe contenant deux points et un nombre. Pour
exemple, "--array=0-15:4" est équivalent à "--array=0,4,8,12". Un nombre maximum de
les tâches exécutées simultanément à partir du tableau de tâches peuvent être spécifiées à l'aide d'un "%"
séparateur. Par exemple "--array=0-15%4" limitera le nombre de
l'exécution des tâches de ce tableau de travaux à 4. La valeur d'index minimale est 0. la valeur maximale
la valeur est un de moins que le paramètre de configuration MaxArraySize.

-A, --Compte=<Compte>
Chargez les ressources utilisées par ce travail sur le compte spécifié. Les Compte est un
chaîne arbitraire. Le nom du compte peut être modifié après la soumission du travail en utilisant le
contrôle commander.

--acctg-freq
Définissez les intervalles d'échantillonnage pour la comptabilisation des travaux et le profilage. Cela peut être utilisé pour
remplacer le JobAcctRassemblerFréquence paramètre dans le fichier de configuration de Slurm,
slurm.conf. Le format pris en charge est le suivant :

--acctg-freq==
où = spécifie l'intervalle d'échantillonnage de la tâche pour
le plugin jobacct_gather ou un intervalle d'échantillonnage pour un type de profilage
par le plugin acct_gather_profile. Plusieurs, séparés par des virgules
= des intervalles peuvent être spécifiés. Types de données pris en charge
sont les suivants:

tâche=
où est l'intervalle d'échantillonnage de la tâche en secondes pour
les plugins jobacct_gather et pour le profilage des tâches par le
plug-in acct_gather_profile. REMARQUE : Cette fréquence est utilisée pour
surveiller l'utilisation de la mémoire. Si les limites de mémoire sont appliquées, la valeur la plus élevée
la fréquence qu'un utilisateur peut demander est ce qui est configuré dans le
fichier slurm.conf. Ils ne peuvent pas non plus l'éteindre (=0).

énergie=
où est l'intervalle d'échantillonnage en secondes pour l'énergie
profilage à l'aide du plugin acct_gather_energy

réseau=
où est l'intervalle d'échantillonnage en secondes pour
profilage infiniband à l'aide du plugin acct_gather_infiniband.

système de fichiers=
où est l'intervalle d'échantillonnage en secondes pour
profilage du système de fichiers à l'aide du plug-in acct_gather_filesystem.

La valeur par défaut de l'intervalle d'échantillonnage des tâches est de 30 secondes.
La valeur par défaut pour tous les autres intervalles est 0. Un intervalle de 0 désactive l'échantillonnage
du type spécifié. Si l'intervalle d'échantillonnage de la tâche est 0, les informations comptables
n'est collecté qu'à la fin du travail (ce qui réduit l'interférence de Slurm avec le travail).
Des valeurs plus petites (non nulles) ont un impact plus important sur la performance au travail, mais une valeur
de 30 secondes n'est pas susceptible d'être perceptible pour les applications ayant moins de
10,000 XNUMX tâches.

-B --extra-node-info=<sockets[:couleurs[:discussions]]>
Demander une allocation spécifique de ressources avec des précisions quant au nombre et au type
de ressources de calcul au sein d'un cluster : nombre de sockets (ou
processeurs) par nœud, cœurs par socket et threads par cœur. Le montant total de
ressources demandées est le produit de tous les termes. Chaque valeur spécifiée
est considéré comme un minimum. Un astérisque (*) peut être utilisé comme espace réservé indiquant
que toutes les ressources disponibles de ce type doivent être utilisées. Comme pour les nœuds, le
les niveaux individuels peuvent également être spécifiés dans des options séparées si vous le souhaitez :
--sockets-par-nœud=<sockets>
--cœurs par socket=<couleurs>
--threads-par-core=<discussions>
Si SelectType est configuré pour select/cons_res, il doit avoir un paramètre de
CR_Core, CR_Core_Memory, CR_Socket ou CR_Socket_Memory pour que cette option soit
honoré. Cette option n'est pas prise en charge sur les systèmes BlueGene (plugin select/bluegene
est configuré). S'il n'est pas spécifié, le travail d'affichage scontrol s'affichera
'ReqS:C:T=*:*:*'.

--bb=<spec>
Spécification du tampon de rafale. La forme de la spécification dépend du système.

- commencer=<Paisible>
Soumettez le script batch au contrôleur Slurm immédiatement, comme d'habitude, mais dites
au contrôleur de différer l'attribution de la tâche jusqu'à l'heure spécifiée.

Le temps peut être de la forme HH:MM:SS pour exécuter une tâche à une heure précise de la journée (secondes
sont facultatifs). (Si cette heure est déjà passée, le jour suivant est supposé.) Vous pouvez
préciser aussi minuit, midi, Else (3h) ou l'heure du thé (4hXNUMX) et vous pouvez avoir un
heure du jour suffixée par AM or PM pour courir le matin ou le soir. Tu
peut également dire quel jour le travail sera exécuté, en spécifiant une date du formulaire MMJJAA
or MM / JJ / AA AAAA-MM-JJ. Combinez la date et l'heure en utilisant le format suivant
AAAA-MM-JJ[THH:MM[:SS]]. Vous pouvez également donner des heures comme maintenant + compter unités de temps, Où
les unités de temps peuvent être secondes (Par défaut), minutes, heures, jours, ou semaines et vous pouvez
dites à Slurm d'exécuter le travail aujourd'hui avec le mot-clé aujourd'hui et pour exécuter le travail demain
avec le mot-clé demain. La valeur peut être modifiée après la soumission du travail à l'aide de la
contrôle commander. Par exemple:
--début=16:00
--begin=maintenant+1heure
--begin=now+60 (secondes par défaut)
--begin=2010-01-20T12:34:00

Remarques sur les spécifications de date/heure :
- Bien que le champ 'secondes' de la spécification de l'heure HH:MM:SS soit autorisé par
le code, notez que l'heure d'interrogation du planificateur Slurm n'est pas assez précise pour
garantir l'envoi du travail à la seconde exacte. L'emploi sera admissible à
démarrer au prochain sondage après l'heure spécifiée. L'intervalle de sondage exact
dépend du planificateur Slurm (par exemple, 60 secondes avec le sched/builtin par défaut).
- Si aucune heure (HH:MM:SS) n'est spécifiée, la valeur par défaut est (00:00:00).
- Si une date est spécifiée sans année (par exemple, MM/JJ) alors l'année en cours est
supposé, à moins que la combinaison de MM/DD et HH:MM:SS soit déjà passée pour cela
année, auquel cas l'année suivante est utilisée.

--point de contrôle=<Paisible>
Spécifie l'intervalle entre la création de points de contrôle de l'étape de tâche. Par défaut,
l'étape de travail n'aura aucun point de contrôle créé. Les formats d'heure acceptables incluent
"minutes", "minutes:secondes", "heures:minutes:secondes", "jours-heures",
"jours-heures:minutes" et "jours-heures:minutes:secondes".

--checkpoint-dir=<annuaire>
Spécifie le répertoire dans lequel le point de contrôle du travail ou de l'étape du travail doit être
écrit (utilisé par les plugins checkpoint/blcrm et checkpoint/xlch uniquement). Les
la valeur par défaut est le répertoire de travail actuel. Les fichiers de point de contrôle seront du
former " .ckpt" pour les emplois et " . .ckpt" pour les étapes du travail.

--commenter=<un magnifique>
Un commentaire arbitraire entre guillemets doubles si vous utilisez des espaces ou des
caractères.

-C, --contrainte=<liste>
Les nœuds peuvent avoir Caractéristiques qui leur est attribué par l'administrateur de Slurm. Les utilisateurs peuvent
préciser lequel de ces Caractéristiques sont requis par leur travail en utilisant la contrainte
option. Seuls les nœuds ayant des caractéristiques correspondant aux contraintes du travail seront utilisés pour
satisfaire la demande. Plusieurs contraintes peuvent être spécifiées avec AND, OR, correspondance
OU, nombre de ressources, etc. Les options de contrainte prises en charge incluent :

Single Nom
Seuls les nœuds qui ont la fonctionnalité spécifiée seront utilisés. Par exemple,
--constraint="intel"

Nœud que vous avez
Une requête peut spécifier le nombre de nœuds nécessaires avec une fonctionnalité en
ajouter un astérisque et compter après le nom de la fonction. Par exemple
"--nœuds=16 --contrainte=graphiques*4 ... " indique que le travail nécessite 16
nœuds et qu'au moins quatre de ces nœuds doivent avoir la caractéristique
"graphique."

ET Si seuls les nœuds avec toutes les fonctionnalités spécifiées seront utilisés. L'esperluette est
utilisé pour un opérateur AND. Par exemple, --constraint="intel&gpu"

OR Si seuls les nœuds avec au moins une des fonctionnalités spécifiées seront utilisés. Les
la barre verticale est utilisée pour un opérateur OU. Par exemple,
--constraint="intel|amd"

Adapter OR
Si une seule d'un ensemble d'options possibles doit être utilisée pour toutes les
nœuds, puis utilisez l'opérateur OU et placez les options dans un carré
supports. Par exemple: "--constraint=[rack1|rack2|rack3|rack4]" peut-être
utilisé pour spécifier que tous les nœuds doivent être alloués sur un seul rack du
cluster, mais n'importe lequel de ces quatre racks peut être utilisé.

Multiple comtes
Des décomptes spécifiques de plusieurs ressources peuvent être spécifiés en utilisant le AND
opérateur et en plaçant les options entre crochets. Par exemple:
"--constraint=[rack1*2&rack2*4]" peut être utilisé pour spécifier que deux nœuds
doivent être alloués à partir de nœuds avec la fonction "rack1" et quatre nœuds doivent
être alloué à partir des nœuds avec la fonctionnalité "rack2".

--contigu
S'il est défini, les nœuds alloués doivent former un ensemble contigu. Pas honoré de la
topologie/arbre or topologie/3d_torus plugins, qui peuvent tous deux modifier le nœud
commande.

--cœurs par socket=<couleurs>
Restreindre la sélection de nœuds aux nœuds avec au moins le nombre spécifié de cœurs par
prise. Voir les informations supplémentaires sous -B option ci-dessus lorsque le plugin tâche/affinité
est autorisé.

--cpu-freq =<p1[-p2[:p3]]>

Demander que les étapes de travail initiées par les commandes srun à l'intérieur de ce script sbatch soient exécutées
à une fréquence demandée si possible, sur les CPU sélectionnés pour l'étape sur le
nœud(s) de calcul.

p1 peut être [#### | bas | moyen | élevé | highm1] qui définira la fréquence
scaling_speed à la valeur correspondante et définissez la fréquence scaling_governor sur
Espace utilisateur. Voir ci-dessous pour la définition des valeurs.

p1 peut être [Conservateur | À la demande | Performances | PowerSave] qui définira le
scaling_governor à la valeur correspondante. Le gouverneur doit être dans la liste
par l'option slurm.conf CpuFreqGovernors.

Quand p2 est présent, p1 sera la fréquence de mise à l'échelle minimale et p2 sera la
fréquence de mise à l'échelle maximale.

p2 peut être [#### | moyen | élevé | highm1] p2 doit être supérieur à p1.

p3 peut être [Conservateur | À la demande | Performances | Économie d'énergie | UserSpace] qui
mettra le gouverneur à la valeur correspondante.

If p3 est UserSpace, la fréquence scaling_speed sera définie par une puissance ou une énergie
stratégie de planification consciente à une valeur entre p1 et p2 qui permet au travail de s'exécuter dans
l'objectif de puissance du site. Le travail peut être retardé si p1 est supérieur à une fréquence qui
permet au travail de s'exécuter dans l'objectif.

Si la fréquence actuelle est < min, elle sera réglée sur min. De même, si le courant
la fréquence est > max, elle sera réglée sur max.

Les valeurs acceptables à l'heure actuelle comprennent :

#### fréquence en kilohertz

Faible la fréquence la plus basse disponible

Haute la fréquence la plus élevée disponible

HauteM1 (élevé moins un) sélectionnera la prochaine fréquence disponible la plus élevée

Moyenne tente de régler une fréquence au milieu de la plage disponible

Conservateur tentatives d'utilisation du gouverneur CPU conservateur

À la demande tente d'utiliser le gouverneur de CPU OnDemand (la valeur par défaut)

Arts de la scène tente d'utiliser le gouverneur Performance CPU

Économie d'énergie tente d'utiliser le gouverneur de processeur PowerSave

Espace utilisateur tente d'utiliser le gouverneur de CPU UserSpace

La variable d'environnement d'information suivante est définie dans le travail
étape quand --cpu-freq option est demandée.
SLURM_CPU_FREQ_REQ

Cette variable d'environnement peut également être utilisée pour fournir la valeur pour le CPU
demande de fréquence si elle est définie lors de l'émission de la commande 'srun'. Les --cpu-freq
sur la ligne de commande remplacera la valeur de la variable d'environnement. Le formulaire sur le
La variable d'environnement est la même que la ligne de commande. Voir le ENVIRONNEMENT
VARIABLES section pour une description de la variable SLURM_CPU_FREQ_REQ.

REMARQUE: ce paramètre est traité comme une demande et non comme une exigence. Si l'étape du travail est
le nœud ne prend pas en charge le réglage de la fréquence du processeur, ou la valeur demandée est en dehors
les limites des fréquences légales, une erreur est enregistrée, mais l'étape du travail est
autorisé à continuer.

REMARQUE: Le réglage de la fréquence uniquement pour les CPU de l'étape de tâche implique que le
les tâches sont confinées à ces CPU. Si le confinement des tâches (c'est-à-dire,
TaskPlugin=task/affinity ou TaskPlugin=task/cgroup avec les "ConstrainCores"
option) n'est pas configuré, ce paramètre est ignoré.

REMARQUE: Lorsque l'étape est terminée, la fréquence et le gouverneur de chaque CPU sélectionné sont
réinitialiser à la configuration CpuFreqDef valeur avec une valeur par défaut du processeur OnDemand
gouverneur.

REMARQUE: lors de la soumission de travaux avec le --cpu-freq option avec linuxproc comme
ProctrackType peut entraîner l'exécution trop rapide des tâches avant que la comptabilité ne puisse interroger
pour des informations sur l'emploi. Par conséquent, toutes les informations comptables ne seront pas présentes.

-c, --cpus-par-tâche=<ncpu>
Informez le contrôleur Slurm que les étapes de travail suivantes nécessiteront ncpu nombre de
processeurs par tâche. Sans cette option, le contrôleur essaiera simplement d'allouer
un processeur par tâche.

Par exemple, considérons une application qui a 4 tâches, chacune nécessitant 3
processeurs. Si notre cluster est composé de nœuds à quatre processeurs et que nous demandons simplement
pour 12 processeurs, le contrôleur pourrait ne nous donner que 3 nœuds. Cependant, en utilisant
les options --cpus-per-task=3, le contrôleur sait que chaque tâche nécessite 3
processeurs sur le même nœud, et le contrôleur accordera une allocation de 4
nœuds, un pour chacune des 4 tâches.

-d, --dépendance=<liste_de_dépendance>
Différer le début de ce travail jusqu'à ce que les dépendances spécifiées soient satisfaites
complété.liste_de_dépendance> est de la forme
<type:job_id[:job_id][,type:job_id[:job_id]]> ou
<type:job_id[:job_id][?type:job_id[:job_id]]>. Toutes les dépendances doivent être satisfaites
si le séparateur "," est utilisé. Toute dépendance peut être satisfaite si le "?" séparateur
est utilisé. De nombreux emplois peuvent partager la même dépendance et ces emplois peuvent même appartenir à
différents utilisateurs. La valeur peut être modifiée après la soumission du travail à l'aide du scontrol
commander. Lorsqu'une dépendance de tâche échoue en raison de l'état d'arrêt d'un précédent
travail, le travail dépendant ne sera jamais exécuté, même si le travail précédent est remis en file d'attente et
a un état de terminaison différent dans une exécution ultérieure.

après:job_id[:jobid...]
Ce travail peut commencer l'exécution une fois que les travaux spécifiés ont commencé à s'exécuter.

après tout:job_id[:jobid...]
Ce travail peut commencer l'exécution après la fin des travaux spécifiés.

aprèsnotok:job_id[:jobid...]
Ce travail peut commencer l'exécution une fois que les travaux spécifiés se sont terminés dans
certains états d'échec (code de sortie différent de zéro, échec de nœud, expiration du délai, etc.).

afterok:job_id[:jobid...]
Ce travail peut commencer l'exécution une fois que les travaux spécifiés ont réussi
exécuté (exécuté jusqu'à la fin avec un code de sortie de zéro).

développer:id_travail
Les ressources allouées à ce travail doivent être utilisées pour développer le travail spécifié.
Le travail à développer doit partager la même QOS (Quality of Service) et
cloison. La planification de groupe des ressources dans la partition n'est pas non plus
prise en charge.

singleton
Ce travail peut commencer l'exécution après tout travail précédemment lancé partageant le
le même nom de travail et le même utilisateur ont pris fin.

-D, --répertoire de travail=<annuaire>
Définissez le répertoire de travail du script batch sur annuaire avant qu'il ne soit exécuté.
Le chemin peut être spécifié comme chemin complet ou chemin relatif vers le répertoire où le
la commande est exécutée.

-e, --Erreur=<nom de fichier modèle>
Demandez à Slurm de connecter l'erreur standard du script batch directement au fichier
nom spécifié dans le "nom de fichier modèle". Par défaut, la sortie standard et
erreur standard sont dirigés vers le même fichier. Pour les tableaux de tâches, le fichier par défaut
le nom est "slurm-%A_%a.out", "%A" est remplacé par l'ID du travail et "%a" par le tableau
indice. Pour les autres travaux, le nom de fichier par défaut est "slurm-%j.out", où le "%j" est
remplacé par l'ID du travail. Voir le --saisir option pour les options de spécification de nom de fichier.

--exclusive[=utilisateur]
L'allocation de tâches ne peut pas partager de nœuds avec d'autres tâches en cours d'exécution (ou simplement d'autres utilisateurs
avec l'option "=utilisateur"). Le comportement partagé/exclusif par défaut dépend du système
configuration et la partition Owned l'option a préséance sur l'emploi
option.

--exportation=<convivial les variables | TOUTES | NONE>
Identifiez les variables d'environnement qui sont propagées au travail par lots. Plusieurs
les noms des variables d'environnement doivent être séparés par des virgules. Noms des variables d'environnement
peut être spécifié pour propager la valeur actuelle de ces variables (par exemple
"--export=EDITOR") ou des valeurs spécifiques pour les variables peuvent être exportées (par ex.
"--export=EDITOR=/bin/vi") en plus des variables d'environnement qui
sinon être réglé. Cette option est particulièrement importante pour les travaux soumis
sur un cluster et exécuter sur un cluster différent (par exemple avec des chemins différents). Par
par défaut, toutes les variables d'environnement sont propagées. Si l'argument est NONE or
noms de variables d'environnement spécifiques, puis le --get-user-env l'option sera implicitement
être configuré pour charger d'autres variables d'environnement en fonction de la configuration de l'utilisateur sur
le cluster qui exécute le travail.

--export-fichier=<nom de fichier | fd>
Si un nombre compris entre 3 et OPEN_MAX est spécifié comme argument de cette option, un
un descripteur de fichier lisible sera supposé (STDIN et STDOUT ne sont pas pris en charge car
arguments valables). Sinon, un nom de fichier est utilisé. Exporter les variables d'environnement
défini dansnom de fichier> ou lire depuisfd> à l'environnement d'exécution du travail. Les
le contenu est une ou plusieurs définitions de variable d'environnement de la forme NOM=valeur,
chacun séparé par un caractère nul. Cela permet l'utilisation de caractères spéciaux dans
définitions de l'environnement.

-F, --nodefile=<nœud filet>
Un peu comme --nodelist, mais la liste est contenue dans un fichier de nom nœud filetL’
les noms de nœud de la liste peuvent également s'étendre sur plusieurs lignes dans le fichier. Nœud en double
les noms dans le fichier seront ignorés. L'ordre des noms de nœuds dans la liste n'est pas
important; les noms de nœuds seront triés par Slurm.

--get-user-env[=temps mort][mode]
Cette option indiquera à sbatch de récupérer les variables d'environnement de connexion pour le
l'utilisateur spécifié dans le --uid option. Les variables d'environnement sont récupérées par
exécuter quelque chose de ce genre "su - -c / usr / bin / env" et en analysant le
sortir. Sachez que toutes les variables d'environnement déjà définies dans sbatch
l'environnement aura la priorité sur toutes les variables d'environnement dans la connexion de l'utilisateur
environnement. Effacez toutes les variables d'environnement avant d'appeler sbatch que vous ne
voulez propagé au programme engendré. L'optionnel temps mort la valeur est en secondes.
La valeur par défaut est de 8 secondes. L'optionnel mode valeur contrôle les options "su".
Avec son mode valeur de "S", "su" est exécuté sans l'option "-". Avec un mode
la valeur de "L", "su" est exécutée avec l'option "-", répliquant le login
environnement. Si mode non spécifié, le mode établi au moment de la construction de Slurm est
utilisé. Exemple d'utilisation : "--get-user-env", "--get-user-env=10"
"--get-user-env=10L" et "--get-user-env=S". Cette option a été créée à l'origine
à l'usage de Moab.

--gid=<groupe>
If lot est exécuté en tant que root, et le --gid est utilisée, soumettez le travail avec groupe's
autorisations d'accès au groupe. groupe peut être le nom du groupe ou l'ID numérique du groupe.

--gres=<liste>
Spécifie une liste délimitée par des virgules de ressources consommables génériques. Le format de
chaque entrée de la liste est "name[[:type]:count]". Le nom est celui du
ressource consommable. Le nombre est le nombre de ces ressources avec une valeur par défaut
valeur de 1. Les ressources spécifiées seront allouées au travail sur chaque nœud.
Les ressources consommables génériques disponibles sont configurables par le système
administrateur. Une liste des ressources consommables génériques disponibles sera imprimée
et la commande se terminera si l'argument de l'option est "help". Exemples d'utilisation
inclure "--gres=gpu:2,mic=1", "--gres=gpu:kepler:2" et "--gres=help".

-H, --prise
Spécifiez que le travail doit être soumis dans un état suspendu (priorité de zéro). Un travail tenu
peut maintenant être libéré en utilisant scontrol pour réinitialiser sa priorité (par exemple "contrôle libérer
").

-h, --Aidez-moi
Affichez les informations d'aide et quittez.

--indice=<type>
Liez les tâches en fonction des astuces d'application.

calcul_lié
Sélectionnez les paramètres pour les applications liées au calcul : utilisez tous les cœurs dans chaque
socket, un thread par cœur.

lié à la mémoire
Sélectionnez les paramètres pour les applications liées à la mémoire : utilisez un seul cœur dans chaque
socket, un thread par cœur.

[non] multithread
[ne pas] utiliser des threads supplémentaires avec le multi-threading intégré qui peut bénéficier
applications intensives en communication. Uniquement pris en charge avec la tâche/l'affinité
plugin.

vous aider afficher ce message d'aide

-I, --immédiat
Le script batch ne sera soumis au contrôleur que si les ressources
nécessaires pour octroyer son attribution de poste sont immédiatement disponibles. Si le travail
l'allocation devra attendre dans une file d'attente de travaux en attente, le script batch ne
être soumis. REMARQUE : la prise en charge de cette option est limitée avec les travaux par lots.

--ignore-pbs
Ignorez toutes les options "#PBS" spécifiées dans le script batch.

-i, --saisir=<nom de fichier modèle>
Demandez à Slurm de connecter l'entrée standard du script batch directement au fichier
nom spécifié dans le "nom de fichier modèle".

Par défaut, "/dev/null" est ouvert sur l'entrée standard du script batch et les deux
la sortie standard et l'erreur standard sont dirigées vers un fichier du nom
"slurm-%j.out", où le "%j" est remplacé par le numéro d'attribution du travail, comme
décrit ci-dessous.

Le modèle de nom de fichier peut contenir un ou plusieurs symboles de remplacement, qui sont un
signe de pourcentage "%" suivi d'une lettre (par exemple %j).

Les symboles de remplacement pris en charge sont :

%A Numéro d'allocation de travail maître du tableau de travaux.

%a Numéro d'identification (index) du tableau de travaux.

%j Numéro d'attribution d'emploi.

%N Nom du nœud. Un seul fichier est créé, donc %N sera remplacé par le nom de
le premier nœud du travail, qui est celui qui exécute le script.

%u Nom d'utilisateur.

-J, --nom du travail=<nom du travail>
Spécifiez un nom pour l'affectation des tâches. Le nom spécifié apparaîtra avec
le numéro d'identification du travail lors de l'interrogation des travaux en cours sur le système. La valeur par défaut est le nom
du script batch, ou simplement "sbatch" si le script est lu sur la norme de sbatch
contribution.

--jobid=<id de travail>
Allouez des ressources en tant qu'ID de tâche spécifié. REMARQUE : Valable uniquement pour l'utilisateur root.

-k, --no-kill
Ne pas terminer automatiquement une tâche si l'un des nœuds lui a été alloué
échoue. L'utilisateur assumera les responsabilités de tolérance aux pannes si un nœud
échouer. En cas de défaillance d'un nœud, toutes les étapes de travail actives (généralement des travaux MPI) sur
ce nœud subira presque certainement une erreur fatale, mais avec --no-kill, le travail
l'allocation ne sera pas révoquée afin que l'utilisateur puisse lancer de nouvelles étapes de travail sur le
nœuds restants dans leur allocation.

Par défaut, Slurm met fin à l'intégralité de l'allocation de travail si un nœud échoue dans son
plage de nœuds alloués.

--kill-on-invalid-dep=<oui|non>
Si un travail a une dépendance invalide et qu'il ne peut jamais s'exécuter, ce paramètre indique à Slurm
d'y mettre fin ou non. Un état de travail terminé sera JOB_CANCELLED. Si ce
L'option n'est pas spécifiée, le comportement à l'échelle du système s'applique. Par défaut, le travail reste
en attente avec raison DependencyNeverSatisfied ou si kill_invalid_depend est
spécifié dans slurm.conf, le travail est terminé.

-L, --licences=<Licence>
Spécification des licences (ou autres ressources disponibles sur tous les nœuds du
cluster) qui doit être alloué à ce travail. Les noms de licence peuvent être suivis d'un
deux-points et nombre (le nombre par défaut est un). Les noms de licence multiples doivent être des virgules
séparés (par exemple "--licenses=foo:4,bar"). Pour soumettre des travaux à l'aide de licences distantes,
ceux servis par le slurmdbd, précisez le nom du serveur fournissant le
licences. Par exemple "--license=nastran@slurmdb:12".

-M, --groupes=<un magnifique>
Clusters auxquels émettre des commandes. Plusieurs noms de cluster peuvent être séparés par des virgules. Les
le travail sera soumis au seul cluster fournissant le premier travail attendu
temps d'initiation. La valeur par défaut est le cluster actuel. Une valeur de 'tous' volonté
requête à exécuter sur tous les clusters. Noter la --exportation option pour contrôler l'environnement
variables exportées entre les clusters.

-m, --Distribution=
arbitraire|<bloc|cyclique|avion =[:bloc|cyclique|fcyclique]>

Spécifiez d'autres méthodes de distribution pour les processus distants. En sbatch, cela seulement
définit les variables d'environnement qui seront utilisées par les requêtes srun suivantes. Cette
L'option contrôle l'affectation des tâches aux nœuds sur lesquels les ressources ont été
allouées et la distribution de ces ressources aux tâches de liaison (tâche
affinité). La première méthode de distribution (avant le ":") contrôle la distribution
de ressources entre les nœuds. La deuxième méthode de distribution facultative (après le ":")
contrôle la distribution des ressources entre les sockets au sein d'un nœud. Noter que
avec select/cons_res, le nombre de processeurs alloués sur chaque socket et nœud peut être
différent. Faire référence à http://slurm.schedmd.com/mc_support.html pour plus d'informations
sur l'allocation des ressources, l'affectation des tâches aux nœuds et la liaison des tâches aux CPU.

Première méthode de distribution :

bloc La méthode de distribution par blocs distribuera les tâches à un nœud de telle sorte que
les tâches consécutives partagent un nœud. Par exemple, considérons une allocation de trois
nœuds chacun avec deux processeurs. Une demande de distribution de blocs de quatre tâches
distribuer ces tâches aux nœuds avec les tâches un et deux sur le premier
nœud, la tâche trois sur le deuxième nœud et la tâche quatre sur le troisième nœud. Bloquer
distribution est le comportement par défaut si le nombre de tâches dépasse le
nombre de nœuds alloués.

cyclique La méthode de distribution cyclique distribuera les tâches à un nœud de telle sorte que
les tâches consécutives sont réparties sur des nœuds consécutifs (dans un round-robin
mode). Par exemple, considérons une allocation de trois nœuds chacun avec deux
processeur. Une demande de distribution cyclique de quatre tâches distribuera ces tâches à
les nœuds avec les tâches un et quatre sur le premier nœud, la tâche deux sur le second
nœud et la tâche trois sur le troisième nœud. Notez que lorsque SelectType est
select/cons_res, le même nombre de CPU peut ne pas être alloué sur chaque nœud.
La distribution des tâches se fera à tour de rôle parmi tous les nœuds avec des processeurs encore à
être affecté à des tâches. La distribution cyclique est le comportement par défaut si le
le nombre de tâches n'est pas supérieur au nombre de nœuds alloués.

avion Les tâches sont réparties en blocs d'une taille spécifiée. Les options
inclure un nombre représentant la taille du bloc de tâches. Ceci est suivi
par une spécification facultative du schéma de répartition des tâches au sein d'un bloc
de tâches et entre les blocs de tâches. Le nombre de tâches réparties
à chaque nœud est le même que pour la distribution cyclique, mais les taskids
affecté à chaque nœud dépendent de la taille du plan. Pour plus de détails (y compris
exemples et schémas), veuillez consulter
http://slurm.schedmd.com/mc_support.html
et
http://slurm.schedmd.com/dist_plane.html

arbitraire
La méthode arbitraire de distribution allouera les processus dans l'ordre comme
répertorié dans le fichier désigné par la variable d'environnement SLURM_HOSTFILE. Si
cette variable est répertoriée, elle remplacera toute autre méthode spécifiée. Si non
définir la méthode par défaut pour bloquer. À l'intérieur du fichier hôte doit contenir au
minimum le nombre d'hôtes demandés et être un par ligne ou virgule
séparé. Si vous spécifiez un nombre de tâches (-n, --ntâches=<nombre>), vos tâches
seront disposés sur les nœuds dans l'ordre du fichier.
NOTE: L'option de distribution arbitraire sur une allocation de travail ne contrôle que
les nœuds à allouer au job et non l'allocation des CPU sur ceux-ci
nœuds. Cette option est principalement destinée à contrôler la disposition des tâches d'une étape de travail dans
une allocation de travail existante pour la commande srun.

Deuxième méthode de distribution :

bloc La méthode de distribution par blocs distribuera les tâches aux sockets de telle sorte que
les tâches consécutives partagent un socket.

cyclique La méthode de distribution cyclique distribuera les tâches aux sockets de telle sorte que
les tâches consécutives sont réparties sur des sockets consécutifs (dans un round-robin
mode). Les tâches nécessitant plus d'un processeur auront tous ces processeurs
alloué sur une seule socket si possible.

fcyclique
La méthode de distribution fcyclique distribuera les tâches aux sockets de telle sorte que
les tâches consécutives sont réparties sur des sockets consécutifs (dans un round-robin
mode). Les tâches nécessitant plus d'un processeur auront chaque processeur alloué
de manière cyclique à travers les sockets.

--type-mail=<type>
Avertissez l'utilisateur par e-mail lorsque certains types d'événements se produisent. Valide type les valeurs sont AUCUNE,
BEGIN, END, FAIL, REQUEUE, ALL (équivalent à BEGIN, END, FAIL, REQUEUE et
STAGE_OUT), STAGE_OUT (sortie du tampon de rafale terminée), TIME_LIMIT, TIME_LIMIT_90
(atteint 90 % de la limite de temps), TIME_LIMIT_80 (a atteint 80 % du temps
limite) et TIME_LIMIT_50 (atteint 50 % de la limite de temps). Plusieurs type valeurs
peut être spécifié dans une liste séparée par des virgules. L'utilisateur à notifier est indiqué
avec --mail-utilisateur. Les notifications par courrier sur le travail BEGIN, END et FAIL s'appliquent à un travail
tableau dans son ensemble plutôt que de générer des messages électroniques individuels pour chaque tâche dans
le tableau des tâches.

--mail-utilisateur=<utilisateur>
L'utilisateur doit recevoir une notification par e-mail des changements d'état tels que définis par --type-mailL’
la valeur par défaut est l'utilisateur soumettant.

--mem=<MB>
Spécifiez la mémoire réelle requise par nœud en mégaoctets. La valeur par défaut est
DefMemPerNode et la valeur maximale est MaxMemPerNode. Si configuré, les deux
les paramètres peuvent être consultés à l'aide de la contrôle montrer config commander. Ce paramètre
serait généralement utilisé si des nœuds entiers sont alloués à des tâches
(SelectType=sélection/linéaire). Regarde aussi --mem-par-cpu. --mem et --mem-par-cpu sommes-nous
mutuellement exclusifs. REMARQUE : une spécification de taille de mémoire est considérée comme un cas particulier
et accorde au travail l'accès à toute la mémoire sur chaque nœud. REMARQUE : l'application des
les limites de mémoire dépendent actuellement du plugin task/cgroup ou de l'activation de
comptabilité, qui échantillonne l'utilisation de la mémoire sur une base périodique (les données n'ont pas besoin d'être stockées,
juste récupéré). Dans les deux cas, l'utilisation de la mémoire est basée sur la taille de l'ensemble résident du travail
(RSS). Une tâche peut dépasser la limite de mémoire jusqu'à la prochaine comptabilité périodique
échantillon.

--mem-par-cpu=<MB>
Mémoire minimale requise par CPU alloué en mégaoctets. La valeur par défaut est
DefMemParCPU et la valeur maximale est MaxMemParCPU (voir exception ci-dessous). Si
configuré, les deux paramètres peuvent être consultés à l'aide de la contrôle montrer config commander.
Notez que si le travail est --mem-par-cpu la valeur dépasse la valeur configurée MaxMemParCPU,
alors la limite de l'utilisateur sera traitée comme une limite de mémoire par tâche ; --mem-par-cpu
sera réduit à une valeur non supérieure à MaxMemParCPU; --cpus-par-tâche sera fixé
et la valeur de --cpus-par-tâche multiplié par le nouveau --mem-par-cpu la valeur sera
égal à l'original --mem-par-cpu valeur spécifiée par l'utilisateur. Ce paramètre serait
généralement être utilisé si des processeurs individuels sont affectés à des travaux
(SelectType=select/cons_res). Si les ressources sont allouées par le cœur, le socket ou
nœuds entiers ; le nombre de CPU alloués à une tâche peut être supérieur à la tâche
compte et la valeur de --mem-par-cpu doit être ajusté en conséquence. Regarde aussi
--mem. --mem et --mem-par-cpu sont mutuellement exclusifs.

--mem_bind=[{calme, bavard},]type
Liez les tâches à la mémoire. Utilisé uniquement lorsque le plug-in de tâche/affinité est activé et que le
Les fonctions de mémoire NUMA sont disponibles. Note qui le RAPIDE of Processeur et Mémoire
propriétés de liant Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. différer on quelques architectures. Par exemple, la liaison CPU peut être effectuée
au niveau des cœurs au sein d'un processeur tandis que la liaison mémoire sera effectuée
au niveau des nœuds, où la définition des « nœuds » peut différer d'un système à
système. Le manuel de formation utilisé of tout type d’autres que "aucun" or "local" is pas recommandé. If
vous voulez un plus grand contrôle, essayez d'exécuter un code de test simple avec les options
"--mem_bind=verbose,none" pour déterminer la configuration spécifique.

REMARQUE : Pour que Slurm signale toujours la liaison de mémoire sélectionnée pour toutes les commandes
exécuté dans un shell, vous pouvez activer le mode verbeux en définissant le SLURM_MEM_BIND
valeur de la variable d'environnement à "verbose".

Les variables d'environnement d'information suivantes sont définies lorsque --mem_bind est en
utilisation:

SLURM_MEM_BIND_VERBOSE
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_LIST

Voir le ENVIRONNEMENT VARIABLES section pour une description plus détaillée de la
variables individuelles SLURM_MEM_BIND*.

Les options prises en charge incluent :

calmer]
lier tranquillement avant l'exécution de la tâche (par défaut)

verbeux]
signaler de manière détaillée la liaison avant l'exécution de la tâche

rien] ne pas lier les tâches à la mémoire (par défaut)

classer lier par rang de tâche (non recommandé)

locales Utiliser la mémoire locale au processeur utilisé

map_mem :
lier en mappant la mémoire d'un nœud aux tâches comme spécifié où est
, ,... . Les ID de CPU sont interprétés comme des valeurs décimales
sauf s'ils sont précédés de « 0x », auquel cas ils sont interprétés comme
valeurs hexadécimales (non recommandées)

mask_mem :
lier en définissant des masques de mémoire sur les tâches comme spécifié où est
, ,... . les masques de mémoire sont toujours interprété comme
valeurs hexadécimales. Notez que les masques doivent être précédés d'un « 0x » s'ils
ne commencent pas par [0-9], ils sont donc considérés comme des valeurs numériques par srun.

vous aider afficher ce message d'aide

--mincpus=<n>
Spécifiez un nombre minimum d'UC/processeurs logiques par nœud.

-N, --nœuds=<nœuds[-nœuds max]>
Demander qu'un minimum de nœuds nœuds soient alloués à ce travail. Un nœud maximum
le nombre peut également être spécifié avec nœuds max. Si un seul numéro est spécifié, ce
est utilisé à la fois comme nombre de nœuds minimum et maximum. Les limites de nœuds de la partition
remplacent ceux du travail. Si les limites de nœud d'une tâche sont en dehors de la plage
autorisé pour sa partition associée, le travail restera dans un état PENDING.
Cela permet une exécution possible à une date ultérieure, lorsque la limite de partition est
modifié. Si une limite de nœuds de tâche dépasse le nombre de nœuds configurés dans le
partition, le travail sera rejeté. Notez que la variable d'environnement
SLURM_NNODES sera défini sur le nombre de nœuds réellement alloués au travail. Voir
le ENVIRONNEMENT VARIABLES rubrique pour plus d'informations. Si -N n'est pas spécifié,
le comportement par défaut est d'allouer suffisamment de nœuds pour satisfaire les exigences du
-n et -c option. Le travail sera alloué autant de nœuds que possible dans le
plage spécifiée et sans retarder le lancement de la tâche. Le nombre de nœuds
spécification peut inclure une valeur numérique suivie d'un suffixe de "k" (multiplie
valeur numérique par 1,024 1,048,576) ou "m" (multiplie la valeur numérique par XNUMX XNUMX XNUMX).

-n, --ntâches=<nombre>
sbatch ne lance pas de tâches, il demande une allocation de ressources et soumet un
script de commandes. Cette option informe le contrôleur Slurm que les étapes du travail s'exécutent dans
l'attribution lancera un maximum de nombre tâches et de prévoir suffisamment
Ressources. La valeur par défaut est une tâche par nœud, mais notez que le --cpus-par-tâche
L'option changera cette valeur par défaut.

--réseau=<type>
Spécifiez les informations relatives au commutateur ou au réseau. L'interprétation de
type dépend du système. Cette option est prise en charge lors de l'exécution de Slurm sur un Cray
nativement. Il est utilisé pour demander à l'aide des compteurs de performances réseau. Une seule valeur
par demande est valide. Toutes les options sont sensibles à la casse. Dans cette configuration
les valeurs prises en charge incluent :

Système
Utilisez les compteurs de performances réseau à l'échelle du système. Seuls les nœuds demandés seront
être marqué en cours d'utilisation pour l'attribution des tâches. Si le travail ne remplit pas le
tout le système, le reste des nœuds ne peut pas être utilisé par d'autres travaux
en utilisant NPC, s'il est inactif, son état apparaîtra comme PerfCnts. Ces nœuds sont
toujours disponible pour d'autres emplois n'utilisant pas NPC.

lame Utilisez les compteurs de performances du réseau lame. Seuls les nœuds demandés seront
marqué en cours d'utilisation pour l'attribution des tâches. Si le travail ne remplit pas tout le
lame(s) affectée(s) au travail, ces lames ne peuvent pas être utilisées par d'autres
travaux utilisant NPC, s'ils sont inactifs, leur état apparaîtra sous la forme PerfCnts. Ces nœuds sont
toujours disponible pour d'autres emplois n'utilisant pas NPC.

Dans tous les cas, la demande d'attribution de poste doit spécifier le
--option exclusive. Dans le cas contraire, la demande sera refusée.

De plus, avec l'une de ces options, les étapes ne sont pas autorisées à partager des lames, donc les ressources
resterait inactif à l'intérieur d'une allocation si l'étape s'exécutant sur une lame ne prend pas
tous les nœuds de la lame.

Le manuel de formation réseau L'option est également prise en charge sur les systèmes avec l'environnement parallèle d'IBM
(PE). Voir la documentation du mot-clé de commande de travail LoadLeveler d'IBM sur le mot-clé
"réseau" pour plus d'informations. Plusieurs valeurs peuvent être spécifiées dans une virgule
liste séparée. Toutes les options sont sensibles à la casse. Les valeurs prises en charge incluent :

VRAC_XFER[=numériques>]
Activez le transfert de données en masse à l'aide de l'accès direct à la mémoire à distance (RDMA).
Le facultatif numériques spécification est une valeur numérique qui peut avoir
un suffixe de "k", "K", "m", "M", "g" ou "G" pour les kilo-octets, les méga-octets ou
gigaoctets. Noter la numériques la spécification n'est pas prise en charge par le
infrastructure IBM sous-jacente à partir de Parallel Environment version 2.2
et aucune valeur ne doit être spécifiée pour le moment.

CAU=<compter> Nombre d'Unités d'Accélération Collective (CAU) requises. S'applique uniquement
aux processeurs IBM Power7-IH. La valeur par défaut est zéro. CAU indépendant
seront alloués pour chaque interface de programmation (MPI, LAPI, etc.)

NOM DEV=<prénom>
Spécifiez le nom de l'appareil à utiliser pour les communications (par exemple "eth0" ou
"mlx4_0").

TYPE DEV=<type>
Spécifiez le type de périphérique à utiliser pour les communications. Le supporté
valeurs de type sont : « IB » (InfiniBand), « HFI » (P7 Host Fabric
Interface), "IPONLY" (interfaces IP uniquement), "HPCE" (HPC Ethernet) et
"KMUX" (émulation noyau de HPCE). Les appareils affectés à une tâche doivent
être tous du même type. La valeur par défaut dépend de dépend de
quel matériel est disponible et dans l'ordre des préférences est IPONLY (qui
n'est pas pris en compte en mode Espace utilisateur), HFI, IB, HPCE et KMUX.

IMMÉDIATEMENT =<compter>
Nombre de slots d'envoi immédiat par fenêtre requis. S'applique uniquement à
Processeurs IBM Power7-IH. La valeur par défaut est zéro.

LES INSTANCES =<compter>
Spécifiez le nombre de connexions réseau pour chaque tâche sur chaque réseau
lien. Le nombre d'instances par défaut est 1.

IPV4 Utilisez les communications IP (Internet Protocol) version 4 (par défaut).

IPV6 Utilisez les communications IP (Internet Protocol) version 6.

LAPI Utilisez l'interface de programmation LAPI.

Propriétés Mitelman Utilisez l'interface de programmation MPI. MPI est l'interface par défaut.

PAMI Utilisez l'interface de programmation PAMI.

SHMEM Utilisez l'interface de programmation OpenSHMEM.

SN_TOUS Utiliser tous les réseaux de commutation disponibles (par défaut).

SN_SINGLE Utilisez un réseau de commutation disponible.

UPC Utilisez l'interface de programmation UPC.

US Utiliser les communications de l'espace utilisateur.

Quelques exemples de spécifications de réseau :

Instances=2,US,MPI,SN_ALL
Créez deux connexions d'espace utilisateur pour les communications MPI sur chaque
changer de réseau pour chaque tâche.

États-Unis, MPI, Instances = 3, Type de développement = IB
Créez trois connexions d'espace utilisateur pour les communications MPI sur chaque
Réseau InfiniBand pour chaque tâche.

IPV4, LAPI, SN_Single
Créez une connexion IP version 4 pour les communications LAPI sur un commutateur
réseau pour chaque tâche.

Instances=2,US,LAPI,MPI
Créer deux connexions d'espace utilisateur chacune pour les communications LAPI et MPI
sur chaque réseau de commutation pour chaque tâche. Notez que SN_ALL est la valeur par défaut
option afin que chaque réseau de commutation soit utilisé. Notez également que Instances=2
précise que deux connexions sont établies pour chaque protocole (LAPI
et MPI) et chaque tâche. S'il y a deux réseaux et quatre tâches sur
le nœud alors un total de 32 connexions sont établies (2 instances x
2 protocoles x 2 réseaux x 4 tâches).

--joli[=le réglage]
Exécutez le travail avec une priorité de planification ajustée dans Slurm. Sans réglage
valeur la priorité de programmation est diminuée de 100. La plage de réglage est de
-10000 (priorité la plus élevée) à 10000 (priorité la plus basse). Seuls les utilisateurs privilégiés peuvent
spécifier un ajustement négatif. REMARQUE : Cette option est actuellement ignorée si
SchedulerType=horaire/wiki or SchedulerType=sched/wiki2.

--pas de nouvelle file d'attente
Indique que le travail par lots ne doit en aucun cas être remis en file d'attente.
La définition de cette option empêchera les administrateurs système de redémarrer
le travail (par exemple, après un temps d'arrêt programmé), récupérer après une panne de nœud, ou
être remis en file d'attente lors de la préemption par un travail de priorité plus élevée. Lorsqu'un travail est remis en file d'attente, le
le script batch est lancé depuis son début. Voir aussi le --requeue option. La
JobRequeue Le paramètre de configuration contrôle le comportement par défaut sur le cluster.

--ntasks-par-cœur=<tâches>
Demander le maximum tâches être invoqué sur chaque cœur. Destiné à être utilisé avec le
--ntâches option. Relatif à --ntasks-par-nœud sauf au niveau de base au lieu de
le niveau du nœud. REMARQUE : Cette option n'est pas prise en charge à moins que
SelectTypeParameters=CR_Core or SelectTypeParameters=CR_Core_Memory est configuré.

--ntasks-par-socket=<tâches>
Demander le maximum tâches être invoqué sur chaque socket. Destiné à être utilisé avec le
--ntâches option. Relatif à --ntasks-par-nœud sauf au niveau du socket à la place
du niveau du nœud. REMARQUE : Cette option n'est pas prise en charge à moins que
SelectTypeParameters=CR_Socket or SelectTypeParameters=CR_Socket_Memory is
configuré.

--ntasks-par-nœud=<tâches>
Demander ça tâches être invoqué sur chaque nœud. S'il est utilisé avec le --ntâches option, la
--ntâches l'option prévaudra et la --ntasks-par-nœud sera traité comme un
maximales nombre de tâches par nœud. Destiné à être utilisé avec le --nœuds option. Ce
est liée à --cpus-par-tâche=ncpu, mais ne nécessite pas la connaissance de la réalité
nombre de processeurs sur chaque nœud. Dans certains cas, il est plus pratique de pouvoir
demander de ne pas appeler plus d'un nombre spécifique de tâches sur chaque nœud.
Les exemples incluent la soumission d'une application hybride MPI/OpenMP où un seul MPI
"task/rank" doit être attribué à chaque nœud tout en permettant à la partie OpenMP de
utiliser tout le parallélisme présent dans le nœud, ou soumettre un seul
tâche de configuration/nettoyage/surveillance à chaque nœud d'une allocation préexistante en une seule étape
dans un script de travail plus volumineux.

-O, --surengager
Surcharger les ressources. Lorsqu'il est appliqué à l'allocation de tâches, un seul processeur est alloué à
le travail par nœud et les options utilisées pour spécifier le nombre de tâches par nœud, socket,
core, etc. sont ignorés. Lorsqu'il est appliqué aux allocations d'étapes de travail (le courir commander
lorsqu'il est exécuté dans une allocation de travail existante), cette option peut être utilisée pour lancer
plus d'une tâche par CPU. Normalement, courir n'allouera pas plus d'un processus
par processeur. En précisant --surengager vous autorisez explicitement plus d'un
processus par CPU. Cependant pas plus de MAX_TASKS_PER_NODE les tâches sont autorisées à
exécuter par nœud. REMARQUE: MAX_TASKS_PER_NODE est défini dans le fichier slurm.h Les modèles sont aussi
pas une variable, elle est définie au moment de la construction de Slurm.

-o, --output=<nom de fichier modèle>
Demandez à Slurm de connecter la sortie standard du script batch directement au fichier
nom spécifié dans le "nom de fichier modèle". Par défaut, la sortie standard et
erreur standard sont dirigés vers le même fichier. Pour les tableaux de tâches, le fichier par défaut
le nom est "slurm-%A_%a.out", "%A" est remplacé par l'ID du travail et "%a" par le tableau
indice. Pour les autres travaux, le nom de fichier par défaut est "slurm-%j.out", où le "%j" est
remplacé par l'ID du travail. Voir le --saisir option pour les options de spécification de nom de fichier.

--mode ouvert=ajouter|tronquer
Ouvrez les fichiers de sortie et d'erreur en utilisant le mode d'ajout ou de troncature comme spécifié. Les
la valeur par défaut est spécifiée par le paramètre de configuration du système JobFichierAjouter.

--analysable
Affiche uniquement le numéro d'identification du travail et le nom du cluster s'il est présent. Les valeurs sont
séparés par un point-virgule. Les erreurs seront toujours affichées.

-p, --cloison=<noms_partition>
Demander une partition spécifique pour l'allocation des ressources. S'il n'est pas spécifié, le
le comportement par défaut est de permettre au contrôleur de slurm de sélectionner la partition par défaut
tel que désigné par l'administrateur système. Si le travail peut utiliser plus d'un
partition, spécifiez leurs noms dans une liste séparée par des virgules et celui offrant
la première initiation sera utilisée sans tenir compte du nom de la partition
l'ordre (bien que les partitions de priorité plus élevée soient considérées en premier). Quand le
le travail est lancé, le nom de la partition utilisée sera placé en premier dans le travail
enregistrer la chaîne de partition.

--Puissance=<drapeaux>
Liste séparée par des virgules des options de plug-in de gestion de l'alimentation. Drapeaux actuellement disponibles
inclure : niveau (tous les nœuds alloués à la tâche doivent avoir des plafonds de puissance identiques,
peut être désactivé par l'option de configuration Slurm PowerParameters=job_no_level).

--priorité=
Demander une priorité de travail spécifique. Peut être sujet à une configuration spécifique
contraintes. Seuls les opérateurs et administrateurs Slurm peuvent définir la priorité d'un
d'emplois.

--profil=
permet la collecte de données détaillées par le plugin acct_gather_profile. Données détaillées
sont généralement des séries temporelles stockées dans un fichier HDF5 pour le travail.

Tous Tous les types de données sont collectés. (Ne peut pas être combiné avec d'autres valeurs.)

Aucun Aucun type de données n'est collecté. C'est la valeur par défaut.
(Ne peut pas être combiné avec d'autres valeurs.)

Énergie Les données énergétiques sont collectées.

Tâche Les données de tâche (E/S, mémoire, ...) sont collectées.

Suspension Les données de lustre sont collectées.

Réseau Les données du réseau (InfiniBand) sont collectées.

--propager[=rlimitfR]
Permet aux utilisateurs de spécifier les limites de ressources modifiables (soft) à propager
aux nœuds de calcul et postuler à leurs emplois. Si limites n'est pas spécifié, alors
toutes les limites de ressources seront propagées. Les noms rlimit suivants sont pris en charge
par Slurm (bien que certaines options puissent ne pas être prises en charge sur certains systèmes) :

TOUTES Toutes les limites énumérées ci-dessous

AS L'espace d'adressage maximal pour un processus

CORE La taille maximale du fichier core

Processeur La quantité maximale de temps CPU

DONNEES La taille maximale du segment de données d'un processus

TAILLE FS La taille maximale des fichiers créés. Notez que si l'utilisateur définit FSIZE sur
inférieure à la taille actuelle du slurmd.log, les lancements de tâches échoueront avec
une erreur 'Taille limite de fichier dépassée'.

MEMLOCK La taille maximale pouvant être verrouillée en mémoire

PAS DE FICHIER Le nombre maximum de fichiers ouverts

NPROC Le nombre maximum de processus disponibles

RSS La taille maximale de l'ensemble résident

STACK La taille maximale de la pile

-Q, --silencieux
Supprimer les messages d'information de sbatch. Les erreurs seront toujours affichées.

--qos=<qos>
Demander une qualité de service pour le travail. Les valeurs QOS peuvent être définies pour chaque
association utilisateur/cluster/compte dans la base de données Slurm. Les utilisateurs seront limités à
l'ensemble défini de qos de leur association lorsque le paramètre de configuration Slurm,
AccountingStorageEnforce, inclut "qos" dans sa définition.

--redémarrer
Forcez les nœuds alloués à redémarrer avant de démarrer la tâche. C'est seulement
pris en charge avec certaines configurations système et sera sinon ignoré en silence.

--requeue
Spécifie que le travail par lots doit pouvoir être remis en file d'attente. Le travail peut être
remis en file d'attente explicitement par un administrateur système, après une panne de nœud, ou lors
préemption par un travail de priorité plus élevée. Lorsqu'un travail est remis en file d'attente, le script batch est
initié dès son origine. Voir aussi le --pas de nouvelle file d'attente option. La JobRequeue
Le paramètre de configuration contrôle le comportement par défaut sur le cluster.

--réservation=<prénom>
Allouez des ressources pour le travail à partir de la réservation nommée.

-s, --partager
L'allocation de tâches peut partager des ressources avec d'autres tâches en cours d'exécution. Les ressources à
être partagés peuvent être des nœuds, des sockets, des cœurs ou des hyperthreads en fonction de
configuration. Le comportement partagé par défaut dépend de la configuration du système et de la
des partitions Owned L'option a préséance sur l'option du travail. Cette option peut
entraîner l'attribution plus tôt que si l'option --share n'était pas
définir et permettre une utilisation plus élevée du système, mais les performances de l'application seront probablement
souffrent en raison de la concurrence pour les ressources. Voir aussi l'option --exclusive.

-S, --core-spec=<num>
Nombre de cœurs spécialisés par nœud réservés par le travail pour les opérations du système et
pas utilisé par l'application. L'application n'utilisera pas ces cœurs, mais sera
facturés pour leur attribution. La valeur par défaut dépend du nœud
valeur CoreSpecCount configurée. Si une valeur de zéro est désignée et le Slurm
l'option de configuration AllowSpecResourcesUsage est activée, le travail sera autorisé à
remplacer CoreSpecCount et utiliser les ressources spécialisées sur les nœuds qui lui sont alloués.
Cette option ne peut pas être utilisée avec le --thread-spec option.

--sicp Identifiez un travail comme celui dont les travaux soumis à d'autres clusters peuvent dépendre.

--signal=[B:]num_sign>[@sig_time>]
Lorsqu'un travail est à l'intérieur sig_time secondes de son heure de fin, envoyez-lui le signal num_sign.
En raison de la résolution de la gestion des événements par Slurm, le signal peut être envoyé jusqu'à 60
secondes plus tôt que spécifié. num_sign peut être soit un numéro de signal, soit un nom
(par exemple « 10 » ou « USR1 »). sig_time doit avoir une valeur entière comprise entre 0 et 65535.
Par défaut, aucun signal n'est envoyé avant l'heure de fin du travail. Si un num_sign est spécifié
sans sig_time, la durée par défaut sera de 60 secondes. Utilisez l'option « B : » pour
signalez uniquement le shell du lot, aucun des autres processus ne sera signalé. Par
par défaut, toutes les étapes du travail seront signalées, mais pas le shell batch lui-même.

--sockets-par-nœud=<sockets>
Restreindre la sélection de nœuds aux nœuds avec au moins le nombre spécifié de sockets.
Voir les informations supplémentaires sous -B option ci-dessus lorsque le plugin de tâche/affinité est
activée.

--commutateurs=<compter>[@temps max>]
Lorsqu'une topologie arborescente est utilisée, cela définit le nombre maximum de commutateurs souhaités
pour l'attribution des tâches et éventuellement le temps d'attente maximum pour ce nombre de
commutateurs. Si Slurm trouve une allocation contenant plus de commutateurs que le nombre
spécifié, le travail reste en attente jusqu'à ce qu'il trouve une allocation avec
nombre de commutations ou le délai expire. Il n'y a pas de limite de nombre de commutateurs, il
n'y a pas de retard dans le démarrage du travail. Les formats d'heure acceptables incluent les « minutes »,
"minutes:secondes", "heures:minutes:secondes", "jours-heures", "jours-heures:minutes" et
"jours-heures:minutes:secondes". La temporisation maximale du travail peut être limitée par le
administrateur système à l'aide du Paramètres du planificateur paramètre de configuration avec le
max_switch_wait option de paramètre. Le temps max par défaut est max_switch_wait
Paramètres du planificateur.

-t, --temps=<Paisible>
Définissez une limite sur le temps d'exécution total de l'allocation de travail. Si l'heure demandée
dépasse la limite de temps de la partition, le travail sera laissé dans un état PENDING
(éventuellement indéfiniment). La limite de temps par défaut est l'heure par défaut de la partition
limite. Lorsque la limite de temps est atteinte, chaque tâche de chaque étape du travail est envoyée SIGTERM
suivi de SIGKILL. L'intervalle entre les signaux est spécifié par le Slurm
paramètre de configuration TuerAttendezL’ Limite de temps supplémentaire paramètre de configuration peut
permettre au travail de s'exécuter plus longtemps que prévu. La résolution temporelle est d'une minute et
les secondes sont arrondies à la minute suivante.

Un délai de zéro demande qu'aucun délai ne soit imposé. Temps acceptable
les formats incluent "minutes", "minutes:secondes", "heures:minutes:secondes",
"jours-heures", "jours-heures:minutes" et "jours-heures:minutes:secondes".

--tâches-par-nœud=<n>
Spécifiez le nombre de tâches à lancer par nœud. Équivalent à
--ntasks-par-nœud.

--test-seulement
Valider le script batch et renvoyer une estimation du moment où un travail serait planifié
à exécuter en fonction de la file d'attente des travaux en cours et de tous les autres arguments spécifiant le travail
conditions. Aucun travail n'est réellement soumis.

--thread-spec=<num>
Nombre de threads spécialisés par nœud réservés par le travail pour les opérations système et
pas utilisé par l'application. L'application n'utilisera pas ces threads, mais
être facturés pour leur attribution. Cette option ne peut pas être utilisée avec le --core-spec
option.

--threads-par-core=<discussions>
Restreindre la sélection de nœuds aux nœuds avec au moins le nombre spécifié de threads par
coeur. REMARQUE : « Threads » fait référence au nombre d'unités de traitement sur chaque cœur plutôt
que le nombre de tâches applicatives à lancer par cœur. Voir plus
informations sous -B option ci-dessus lorsque le plug-in de tâche/affinité est activé.

--temps-min=<Paisible>
Fixez une limite de temps minimale pour l'attribution des tâches. Si spécifié, le travail peut avoir
c'est --temps limite abaissée à une valeur non inférieure à --temps-min si cela le permet
le travail pour commencer l'exécution plus tôt que possible. La limite de temps du travail
ne sera pas modifié une fois les ressources allouées au travail. Ceci est effectué par un
algorithme de planification de remplissage pour allouer des ressources autrement réservées à des
emplois prioritaires. Les formats d'heure acceptables incluent "minutes", "minutes:seconds",
"heures:minutes:secondes", "jours-heures", "jours-heures:minutes" et
"jours-heures:minutes:secondes".

--tmp=<MB>
Spécifiez une quantité minimale d'espace disque temporaire.

-u, --usage
Affichez un bref message d'aide et quittez.

--uid=<utilisateur>
Tenter de soumettre et/ou d'exécuter un travail en tant que utilisateur au lieu de l'ID utilisateur appelant. Les
l'invocation des informations d'identification de l'utilisateur sera utilisée pour vérifier les autorisations d'accès pour la cible
cloison. L'utilisateur root peut utiliser cette option pour exécuter des tâches en tant qu'utilisateur normal dans un RootOnly
partitionner par exemple. Si exécuté en tant que root, lot supprimera ses autorisations sur l'uid
spécifié une fois l'allocation de nœud réussie. utilisateur peut être le nom d'utilisateur ou
ID utilisateur numérique.

-V, --version
Affichez les informations de version et quittez.

-v, --verbeux
Augmentez la verbosité des messages d'information de sbatch. Plusieurs -vla volonté
augmenter encore la verbosité de sbatch. Par défaut, seules les erreurs seront affichées.

-w, --nodelist=<nœud prénom liste>
Demandez une liste spécifique d'hôtes. Le travail contiendra tous de ces hôtes et
éventuellement des hôtes supplémentaires selon les besoins pour satisfaire les besoins en ressources. La liste peut
être spécifié comme une liste d'hôtes séparés par des virgules, une plage d'hôtes (host[1-5,7,...]
par exemple) ou un nom de fichier. La liste d'hôtes sera considérée comme un nom de fichier si elle
contient un caractère "/". Si vous spécifiez un nombre minimum de nœuds ou de processeurs supérieur
que ne peut être satisfaite par la liste d'hôtes fournie, des ressources supplémentaires seront
alloués sur d'autres nœuds selon les besoins. Les noms de nœuds en double dans la liste seront
ignoré. L'ordre des noms de nœuds dans la liste n'est pas important ; les noms de nœuds
seront triés par Slurm.

--attendre-tous les nœuds=<Plus-value>
Contrôle quand l'exécution de la commande commence. Par défaut, le travail commencera
exécution dès que l'attribution est effectuée.

0 Commencer l'exécution dès que l'allocation peut être effectuée. N'attendez pas tous les nœuds
être prêt à l'emploi (c'est-à-dire démarré).

1 Ne commencez pas l'exécution tant que tous les nœuds ne sont pas prêts à être utilisés.

--wckey=<clé de toilette>
Spécifiez wckey à utiliser avec le travail. Si TrackWCKey=no (par défaut) dans le slurm.conf
cette valeur est ignorée.

--envelopper=<commander un magnifique>
Sbatch encapsulera la chaîne de commande spécifiée dans un simple script shell "sh", et
soumettre ce script au contrôleur slurm. Lorsque --wrap est utilisé, un nom de script et
les arguments ne peuvent pas être spécifiés sur la ligne de commande ; à la place le sbatch généré
le script wrapper est utilisé.

-x, --exclure=<nœud prénom liste>
Exclure explicitement certains nœuds des ressources accordées au travail.

Les options suivantes prennent en charge les systèmes Blue Gene, mais peuvent être applicables à d'autres systèmes comme
Hé bien.

--blrts-image=<chemin>
Chemin d'accès à l'image Blue GeneL Run Time Supervisor, ou blrts, pour le bloc bluegene. BGL
seul. Par défaut à partir de bluegene.conf s'il n'est pas défini.

--cnload-image=<chemin>
Chemin pour calculer l'image du nœud pour le bloc bluegene. BGP uniquement. Par défaut à partir de
bluegene.conf s'il n'est pas défini.

--conn-type=<type>
Exiger que le type de connexion de bloc soit d'un certain type. Sur Blue Gene le
acceptable de type sont MESH, TORUS et NAV. Si NAV, ou s'il n'est pas défini, alors Slurm
essayez d'adapter à ce que le DefaultConnType est défini dans le bluegene.conf si ce n'est pas le cas
définir la valeur par défaut est TORUS. Vous ne devez normalement pas définir cette option. Si en cours d'exécution sur
un système BGP et souhaitant fonctionner en mode HTC (uniquement pour 1 midplane et moins). Tu
peut utiliser HTC_S pour SMP, HTC_D pour Dual, HTC_V pour le mode nœud virtuel et HTC_L pour
Mode Linux. Pour les systèmes qui permettent un type de connexion différent par dimension, vous
peut fournir une liste de types de connexion séparés par des virgules peut être spécifié, un pour
chaque dimension (c'est-à-dire M,T,T,T vous donnera une connexion de tore est toutes les dimensions
attendre le premier).

-g, --géométrie=<XxYxZ> |AxXxYxZ>
Spécifiez les exigences de géométrie pour le travail. Sur les systèmes BlueGene/L et BlueGene/P
il y a trois nombres donnant des dimensions dans les directions X, Y et Z, tandis que sur
Systèmes BlueGene/Q il y a quatre nombres donnant les dimensions dans les A, X, Y et Z
directions et ne peut pas être utilisé pour allouer des sous-blocs. Par exemple
"--geometry=1x2x3x4", spécifie un bloc de nœuds ayant 1 x 2 x 3 x 4 = 24 nœuds
(en fait des midplanes sur BlueGene).

--ioload-image=<chemin>
Chemin d'accès à l'image io pour le bloc bluegene. BGP uniquement. Par défaut à partir de bluegene.conf si non
défini.

--linux-image=<chemin>
Chemin d'accès à l'image Linux pour le bloc bluegene. BGL uniquement. Par défaut à partir de bluegene.conf if
pas encore défini.

--mloader-image=<chemin>
Chemin d'accès à l'image mloader pour le bloc bluegene. Par défaut à partir de bluegene.conf s'il n'est pas défini.

-R, --pas de rotation
Désactive la rotation de la géométrie demandée du travail afin de s'adapter à un
bloquer. Par défaut, la géométrie spécifiée peut pivoter en trois dimensions.

--image-disqueram=<chemin>
Chemin d'accès à l'image du disque virtuel pour le bloc bluegene. BGL uniquement. Par défaut à partir de bluegene.conf if
pas encore défini.

CONTRIBUTION ENVIRONNEMENT VARIABLES

Au démarrage, sbatch lira et gérera les options définies dans l'environnement suivant
variables. Notez que les variables d'environnement remplaceront toutes les options définies dans un lot
les options de script et de ligne de commande remplaceront toutes les variables d'environnement.

SBATCH_ACCOUNT Pareil que -UNE, --Compte

SBATCH_ACCTG_FREQ Pareil que --acctg-freq

SBATCH_ARRAY_INX Pareil que -une, --déployer

SBATCH_BLRTS_IMAGE Pareil que --blrts-image

SBATCH_BURST_BUFFER Pareil que --bb

SBATCH_CHECKPOINT Pareil que --point de contrôle

SBATCH_CHECKPOINT_DIR Pareil que --checkpoint-dir

SBATCH_CLUSTERS or SLURM_CLUSTERS
Pareil que --groupes

SBATCH_CNLOAD_IMAGE Pareil que --cnload-image

SBATCH_CONN_TYPE Pareil que --conn-type

SBATCH_CORE_SPEC Pareil que --core-spec

SBATCH_DEBUG Pareil que -dans, --verbeux

SBATCH_DISTRIBUTION Pareil que -m, --Distribution

SBATCH_EXCLUSIVE Pareil que --exclusif

SBATCH_EXPORT Pareil que --exportation

SBATCH_GEOMETRY Pareil que -g, --géométrie

SBATCH_GET_USER_ENV Pareil que --get-user-env

SBATCH_HINT or SLURM_HINT
Pareil que --indice

SBATCH_IGNORE_PBS Pareil que --ignore-pbs

SBATCH_IMMEDIATE Pareil que -JE, --immédiat

SBATCH_IOLOAD_IMAGE Pareil que --ioload-image

SBATCH_JOBID Pareil que --jobid

SBATCH_JOB_NAME Pareil que -J, --nom du travail

SBATCH_LINUX_IMAGE Pareil que --linux-image

SBATCH_MEM_BIND Pareil que --mem_bind

SBATCH_MLOADER_IMAGE Pareil que --mloader-image

SBATCH_NETWORK Pareil que --réseau

SBATCH_NO_REQUEUE Pareil que --pas de nouvelle file d'attente

SBATCH_NO_ROTATE Pareil que -R, --pas de rotation

SBATCH_OPEN_MODE Pareil que --mode ouvert

SBATCH_OVERCOMMIT Pareil que -Ô, --surengager

SBATCH_PARTITION Pareil que -p, --cloison

SBATCH_POWER Pareil que --Puissance

SBATCH_PROFIL Pareil que --profil

SBATCH_QOS Pareil que --qos

SBATCH_RAMDISK_IMAGE Pareil que --image-disqueram

SBATCH_RESERVATION Pareil que --réservation

SBATCH_REQ_SWITCH Lorsqu'une topologie arborescente est utilisée, cela définit le nombre maximum de
commutateurs souhaités pour l'attribution des tâches et éventuellement le maximum
temps d'attente pour ce nombre de commutateurs. Voir --commutateurs

SBATCH_REQUEUE Pareil que --requeue

SBATCH_SICP Pareil que --sicp

SBATCH_SIGNAL Pareil que --signal

SBATCH_THREAD_SPEC Pareil que --thread-spec

SBATCH_TIMELIMIT Pareil que -t, --temps

SBATCH_WAIT_ALL_NODES Pareil que --attendre-tous les nœuds

SBATCH_WAIT4SWITCH Temps d'attente maximum pour les commutateurs demandés. Voir --commutateurs

SBATCH_WCKEY Pareil que --wckey

SLURM_CONF L'emplacement du fichier de configuration Slurm.

SLURM_EXIT_ERROR Spécifie le code de sortie généré lorsqu'une erreur Slurm se produit (par exemple
options invalides). Cela peut être utilisé par un script pour distinguer
codes de sortie d'application de diverses conditions d'erreur Slurm.

SLURM_STEP_KILLED_MSG_NODE_ID=Identifiant
S'il est défini, seul le nœud spécifié sera enregistré lorsque le travail ou l'étape sont
tué par un signal.

SORTIE ENVIRONNEMENT VARIABLES

Le contrôleur Slurm définira les variables suivantes dans l'environnement du lot
scripts.

BASIL_RESERVATION_ID
L'ID de réservation sur les systèmes Cray exécutant ALPS/BASIL uniquement.

MPIRUN_NOALLOCATE
N'allouez pas de bloc sur les systèmes Blue Gene L/P uniquement.

MPIRUN_NOFREE
Ne libérez pas un bloc sur les systèmes Blue Gene L/P uniquement.

MPIRUN_PARTITION
Le nom du bloc sur les systèmes Blue Gene uniquement.

SBATCH_CPU_BIND
Définissez la valeur de l'option --cpu_bind.

SBATCH_CPU_BIND_VERBOSE
Défini sur "verbose" si l'option --cpu_bind inclut l'option verbose. Mis à
"calme" sinon.

SBATCH_CPU_BIND_TYPE
Définissez le type de liaison CPU spécifié avec l'option --cpu_bind. Valeurs possibles
deux chaînes possibles séparées par des virgules. La première chaîne possible identifie le
entité à lier à : "threads", "cores", "sockets", "ldoms" et "boards". Les
la deuxième chaîne identifie la manière dont les tâches sont liées : "aucun", "rang",
"map_cpu", "mask_cpu", "rank_ldom", "map_ldom" ou "mask_ldom".

SBATCH_CPU_BIND_LIST
Définie sur le masque de bits utilisé pour la liaison CPU.

SBATCH_MEM_BIND
Définissez la valeur de l'option --mem_bind.

SBATCH_MEM_BIND_VERBOSE
Défini sur "verbose" si l'option --mem_bind inclut l'option verbose. Mis à
"calme" sinon.

SBATCH_MEM_BIND_TYPE
Définissez le type de liaison mémoire spécifié avec l'option --mem_bind. Possible
les valeurs sont "aucun", "rank", "map_map", "mask_mem" et "local".

SBATCH_MEM_BIND_LIST
Définie sur le masque de bits utilisé pour la liaison mémoire.

SLURM_ARRAY_TASK_ID
Numéro d'identification (index) du tableau de travaux.

SLURM_ARRAY_TASK_MAX
Numéro d'ID (index) maximal du tableau de travaux.

SLURM_ARRAY_TASK_MIN
Numéro d'identification (index) minimum du tableau de tâches.

SLURM_ARRAY_TASK_STEP
Taille du pas d'index du tableau de travaux.

SLURM_ARRAY_JOB_ID
Numéro d'identification du travail principal de la matrice de travaux.

SLURM_CHECKPOINT_IMAGE_DIR
Répertoire dans lequel les images de point de contrôle doivent être écrites s'il est spécifié sur le
exécuter la ligne.

SLURM_CLUSTER_NAME
Nom du cluster sur lequel le travail s'exécute.

SLURM_CPUS_ON_NODE
Nombre de CPU sur le nœud alloué.

SLURM_CPUS_PER_TASK
Nombre de processeurs demandés par tâche. Ne réglez que si le --cpus-par-tâche option est
spécifié.

SLURM_DISTRIBUTION
Pareil que -m, --Distribution

SLURM_GTIDS
ID de tâche globale en cours d'exécution sur ce nœud. Zéro origine et virgule séparés.

SLURM_JOB_ID (Et SLURM_JOBID pour la rétrocompatibilité)
L'ID de l'attribution du travail.

SLURM_JOB_CPUS_PER_NODE
Nombre de processeurs disponibles pour le travail sur ce nœud. Notez la sélection/linéaire
Le plugin alloue des nœuds entiers aux travaux, la valeur indique donc le nombre total de
CPU sur le nœud. Le plugin select/cons_res alloue des processeurs individuels à
travaux, donc ce nombre indique le nombre de processeurs sur ce nœud alloués à
le travail.

SLURM_JOB_DÉPENDANCE
Définissez la valeur de l'option --dependency.

SLURM_JOB_NAME
Nom du travail.

SLURM_JOB_NODELIST (Et SLURM_NODELIST pour la rétrocompatibilité)
Liste des nœuds alloués au travail.

SLURM_JOB_NUM_NODES (Et SLURM_NNODES pour la rétrocompatibilité)
Nombre total de nœuds dans l'allocation de ressources du travail.

SLURM_JOB_PARTITION
Nom de la partition dans laquelle le travail s'exécute.

SLURM_LOCALID
ID de tâche locale du nœud pour le processus dans un travail.

SLURM_NODE_ALIASES
Ensembles de nom de nœud, d'adresse de communication et de nom d'hôte pour les nœuds alloués au
travail depuis le cloud. Chaque élément de l'ensemble si deux points sont séparés et chaque ensemble est
séparées par des virgules. Par exemple : SLURM_NODE_ALIASES=ec0:1.2.3.4:foo,ec1:1.2.3.5:bar

SLURM_NODEID
ID des nœuds alloués.

SLURMD_NODENAME
Noms de tous les nœuds alloués.

SLURM_NTASKS (Et SLURM_NPROCS pour la rétrocompatibilité)
Pareil que -n, --ntâches

SLURM_NTASKS_PER_CORE
Nombre de tâches demandées par noyau. Ne réglez que si le --ntasks-par-cœur option est
spécifié.

SLURM_NTASKS_PER_NODE
Nombre de tâches demandées par nœud. Ne réglez que si le --ntasks-par-nœud option est
spécifié.

SLURM_NTASKS_PER_SOCKET
Nombre de tâches demandées par socket. Ne réglez que si le --ntasks-par-socket option
est spécifié.

SLURM_PRIO_PROCESS
La priorité de planification (valeur intéressante) au moment de la soumission du travail. Cette valeur est
propagé aux processus engendrés.

SLURM_PROCID
Le rang MPI (ou ID de processus relatif) du processus actuel

SLURM_PROFILE
Pareil que --profil

SLURM_RESTART_COUNT
Si le travail a été redémarré en raison d'une défaillance du système ou a été explicitement
remis en file d'attente, il sera envoyé au nombre de fois où le travail a été redémarré.

SLURM_SUBMIT_DIR
Le répertoire à partir duquel lot a été invoqué.

SLURM_SUBMIT_HOST
Le nom d'hôte de l'ordinateur à partir duquel lot a été invoqué.

SLURM_TASKS_PER_NODE
Nombre de tâches à lancer sur chaque nœud. Les valeurs sont séparées par des virgules et dans le
même ordre que SLURM_NODELIST. Si deux nœuds consécutifs ou plus doivent avoir le
même nombre de tâches, ce nombre est suivi de "(x#)" où "#" est la répétition
compter. Par exemple, "SLURM_TASKS_PER_NODE=2(x3),1" indique que les trois premiers
les nœuds exécuteront chacun trois tâches et le quatrième nœud exécutera une tâche.

SLURM_TASK_PID
L'ID de processus de la tâche en cours de démarrage.

SLURM_TOPOLOGY_ADDR
Ceci n'est défini que si le système a configuré le plug-in de topologie/arborescence. Les
valeur sera définie sur les noms des commutateurs réseau qui peuvent être impliqués dans le
les communications du travail depuis l'interrupteur de niveau supérieur du système jusqu'à l'interrupteur à lames
et se terminant par le nom du nœud. Un point est utilisé pour séparer chaque composant matériel
nom.

SLURM_TOPOLOGY_ADDR_PATTERN
Ceci n'est défini que si le système a configuré le plug-in de topologie/arborescence. Les
La valeur sera définie sur les types de composants répertoriés dans SLURM_TOPOLOGY_ADDR. Chaque
le composant sera identifié comme « commutateur » ou « nœud ». Une période est utilisée pour
séparez chaque type de composant matériel.

EXEMPLES

Spécifiez un script batch par nom de fichier sur la ligne de commande. Le script batch spécifie un 1
minute limite de temps pour le travail.

$ chat mon script
#!/ Bin / sh
#SBATCH --temps=1
srun nom d'hôte | trier

$ sbatch -N4 monscript
salloc: Attribution d'emploi accordée 65537

$ chat slurm-65537.out
host1
host2
host3
host4

Passez un script batch à sbatch sur l'entrée standard :

$ sbatch -N4 <
> #!/ Bin / sh
> srun nom d'hôte |sort
> EOF
sbatch : tâche par lots soumise 65541

$ chat slurm-65541.out
host1
host2
host3
host4

COPIER

Copyright (C) 2006-2007 Les régents de l'Université de Californie. Produit à Lawrence
Laboratoire national de Livermore (cf. AVIS DE NON-RESPONSABILITÉ).
Copyright (C) 2008-2010 Lawrence Livermore Sécurité nationale.
Copyright (C) 2010-2015 SchedMD LLC.

Ce fichier fait partie de Slurm, un programme de gestion des ressources. Pour plus de détails, voir
<http://slurm.schedmd.com/>.

Slurm est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier selon les termes des
Licence publique générale GNU telle que publiée par la Free Software Foundation ; soit la version 2
de la Licence, ou (à votre choix) toute version ultérieure.

Slurm est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE ; sans pour autant
même la garantie implicite de QUALITÉ MARCHANDE ou D'ADAPTATION À UN USAGE PARTICULIER. Voir le
Licence publique générale GNU pour plus de détails.

Utiliser sbatch en ligne à l'aide des services onworks.net