salloc - En ligne dans le Cloud

PROGRAMME:

Nom

salloc - Obtenez une allocation de travail Slurm (un ensemble de nœuds), exécutez une commande, puis
libérer l'allocation lorsque la commande est terminée.

SYNOPSIS

salloc [Options] [commander> [commander args]]

DESCRIPTION

salloc est utilisé pour allouer une allocation de travail Slurm, qui est un ensemble de ressources (nœuds),
éventuellement avec un ensemble de contraintes (par exemple nombre de processeurs par nœud). Quand salloc
obtient avec succès l'allocation demandée, il exécute ensuite la commande spécifiée par le
utilisateur. Enfin, lorsque la commande spécifiée par l'utilisateur est terminée, salloc abandonne le travail
allocation.

La commande peut être n'importe quel programme souhaité par l'utilisateur. Certaines commandes typiques sont xterm, un shell
script contenant les commandes srun et srun (voir la section EXEMPLES). Si aucune commande n'est
spécifié, alors la valeur de Commande par défaut Salloc dans slurm.conf est utilisé. Si
Commande par défaut Salloc n'est pas défini, alors salloc exécute le shell par défaut de l'utilisateur.

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

REMARQUE : La logique salloc inclut la prise en charge de l'enregistrement et de la restauration des paramètres de la ligne terminale et
est conçu pour être exécuté au premier plan. Si vous devez exécuter salloc dans le
background, définissez son entrée standard sur un fichier, par exemple : "salloc -n16 a.out

OPTIONS

-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 pour l'intervalle d'échantillonnage des tâches
est 30. La valeur par défaut pour tous les autres intervalles est 0. Un intervalle de 0 désactive
échantillonnage du type spécifié. Si l'intervalle d'échantillonnage de la tâche est 0, la comptabilisation
les informations ne sont collectées qu'à la fin du travail (réduction des interférences 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=<fois>
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.

--cloche Forcer salloc à sonner la cloche du terminal lorsque l'attribution du travail est accordée (et seulement
si stdout est un tty). Par défaut, salloc ne sonne que si l'allocation est
en attente pendant plus de dix secondes (et seulement si stdout est un tty). Voir aussi le
option --pas de cloche.

--commenter=<un magnifique>
Un commentaire arbitraire.

-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 :

Simple 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"

Des 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 cette allocation soient exécutées à
une certaine 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.

Lorsque 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)

Performance 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, --chdir=<chemin>
Changer de répertoire en chemin avant de commencer l'exécution. Le chemin peut être spécifié comme
chemin complet ou chemin relatif vers le répertoire où la commande est exécutée.

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

-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 chargera les variables d'environnement de connexion pour l'utilisateur spécifié dans le
--uid option. Les variables d'environnement sont récupérées en exécutant quelque chose de ce
trier "su - -c / usr / bin / env" et l'analyse de la sortie. Sachez que tout
les variables d'environnement déjà définies dans l'environnement de salloc prévaudront sur
toutes les variables d'environnement dans l'environnement de connexion de l'utilisateur. L'optionnel temps mort
la valeur est en secondes. La valeur par défaut est de 3 secondes. L'optionnel mode contrôle de la valeur
les options "su". Avec un mode la valeur de "S", "su" est exécutée sans le "-"
option. Avec un mode la valeur de "L", "su" est exécutée avec l'option "-",
réplication de l'environnement de connexion. Si mode non précisé, le mode établi à
Le temps de construction du slurm est utilisé. Exemple d'utilisation : "--get-user-env",
"--get-user-env=10" "--get-user-env=10L" et "--get-user-env=S". REMARQUE : ce
L'option ne fonctionne que si l'appelant a un uid effectif de "root". Cette option était
créé à l'origine pour être utilisé par Moab.

--gid=<groupe>
Soumettre le travail avec le spécifié groupeles autorisations d'accès au groupe de. groupe peut être
le nom du groupe ou l'ID numérique du groupe. Dans la configuration Slurm par défaut, ce
L'option n'est valide que lorsqu'elle est utilisée par l'utilisateur root.

--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[=secondes>]
quitter si les ressources ne sont pas disponibles dans le délai spécifié. Sinon
argument est donné, les ressources doivent être disponibles immédiatement pour que la demande
réussir. Par défaut, --immédiat est désactivé et la commande se bloquera jusqu'à ce que
les ressources deviennent disponibles. Étant donné que l'argument de cette option est facultatif, pour une bonne
l'analyse de l'option à une seule lettre doit être immédiatement suivie de la valeur et
ne pas inclure d'espace entre eux. Par exemple "-I60" et non "-I 60".

-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. Le nom du travail par défaut
est le nom de la "commande" spécifiée sur la ligne de commande.

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

-K, --kill-commande[=signal]
salloc exécute toujours une commande spécifiée par l'utilisateur une fois que l'allocation est accordée. salloc
attendra indéfiniment que cette commande se termine. Si vous spécifiez la --kill-command
L'option salloc enverra un signal à votre commande chaque fois que le contrôleur Slurm
informe salloc que son attribution de poste a été révoquée. La répartition des tâches peut être
révoqué pour plusieurs raisons : quelqu'un a utilisé scanceler de révoquer l'attribution, ou
l'attribution a atteint son échéance. Si vous ne spécifiez pas de nom de signal ou
nombre et Slurm est configuré pour signaler la commande engendrée à la fin du travail,
le signal par défaut est SIGHUP pour interactif et SIGTERM pour non interactif
séances. Étant donné que l'argument de cette option est facultatif, pour une analyse correcte du seul
L'option de lettre doit être suivie immédiatement de la valeur et ne pas inclure d'espace
entre eux. Par exemple "-K1" et non "-K 1".

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

-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").

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

Spécifiez d'autres méthodes de distribution pour les processus distants. En salloc, ce seul
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 votre
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
pas défini, la méthode sera par défaut bloquée. À l'intérieur du fichier hôte doit contenir
au minimum le nombre d'hôtes demandé 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.

--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 votre --mem-par-cpu are
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 votre --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. Notes qui le RAPIDE of Processeur et votre 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. Notre utilisé of tout type autre 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 votre -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>
salloc ne lance pas de tâches, il demande une allocation de ressources et exécuté
quelque commande. Cette option informe le contrôleur Slurm que les étapes du travail s'exécutent dans
cette allocation lancera un maximum de nombre des tâches et des ressources suffisantes sont
alloués pour y parvenir. 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.

Notre 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 à
Processeurs IBM Power7-IH. La valeur par défaut est zéro. La CAU indépendante
être alloué 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.

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

--pas de cloche
Silence l'utilisation de la cloche terminale par salloc. Voir aussi l'option --cloche.

--pas de shell
quitter immédiatement après avoir alloué des ressources, sans exécuter de commande. Cependant,
le travail Slurm sera toujours créé et restera actif et possédera le
ressources allouées tant qu'il est actif. Vous aurez un identifiant de travail Slurm sans
processus ou tâches associés. Vous pouvez soumettre courir commandes contre cette ressource
allocation, si vous spécifiez le --jobid= avec l'identifiant du travail de ce travail Slurm.
Ou, cela peut être utilisé pour réserver temporairement un ensemble de ressources afin que d'autres travaux
ne peut pas les utiliser pendant un certain temps. (Notez que le travail Slurm est soumis à
les contraintes normales sur les travaux, y compris les délais, de sorte qu'en fin de compte le travail
se terminera et les ressources seront libérées, ou vous pouvez terminer le travail
manuellement à l'aide du scanceler commander.)

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

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

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

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

-Q, --silencieux
Supprimer les messages d'information de salloc. 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.

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

--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=<fois>
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".

--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=<fois>
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. Cette option n'est valide que pour l'utilisateur root. Cette option peut être utilisée par l'utilisateur
root peut utiliser cette option pour exécuter des tâches en tant qu'utilisateur normal dans une partition RootOnly pour
Exemple. Si exécuté en tant que root, salloc 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 l'utilisateur numérique
ID.

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

-v, --verbeux
Augmentez la verbosité des messages d'information de salloc. Plusieurs -vla volonté
augmenter encore la verbosité de salloc. 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.

-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 blrts pour le bloc bluegene. BGL uniquement. Par défaut à partir de bluegene.conf if
pas encore 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, salloc lira et gérera les options définies dans l'environnement suivant
variables. Remarque : Les options de la ligne de commande remplacent toujours les paramètres des variables d'environnement.

SALLOC_ACCOUNT Pareil que -UNE, --Compte

SALLOC_ACCTG_FREQ Pareil que --acctg-freq

SALLOC_BELL Pareil que --cloche

SALLOC_BURST_BUFFER Pareil que --bb

SALLOC_CONN_TYPE Pareil que --conn-type

SALLOC_CORE_SPEC Pareil que --core-spec

SALLOC_DEBUG Pareil que -dans, --verbeux

SALLOC_EXCLUSIVE Pareil que --exclusif

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

SALLOC_HINT or SLURM_HINT
Pareil que --indice

SALLOC_IMMEDIATE Pareil que -JE, --immédiat

SALLOC_JOBID Pareil que --jobid

SALLOC_KILL_CMD Pareil que -K, --kill-commande

SALLOC_MEM_BIND Pareil que --mem_bind

SALLOC_NETWORK Pareil que --réseau

SALLOC_NO_BELL Pareil que --pas de cloche

SALLOC_NO_ROTATE Pareil que -R, --pas de rotation

SALLOC_OVERCOMMIT Pareil que -Ô, --surengager

SALLOC_PARTITION Pareil que -p, --cloison

SALLOC_POWER Pareil que --Puissance

SALLOC_PROFILE Pareil que --profil

SALLOC_QOS Pareil que --qos

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

SALLOC_RESERVATION Pareil que --réservation

SALLOC_SICP Pareil que --sicp

SALLOC_SIGNAL Pareil que --signal

SALLOC_THREAD_SPEC Pareil que --thread-spec

SALLOC_TIMELIMIT Pareil que -t, --temps

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

SALLOC_WCKEY Pareil que --wckey

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

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. Aussi
sur le lien SLURM_EXIT_IMMEDIATE.

SLURM_EXIT_IMMEDIATE Spécifie le code de sortie généré lorsque le --immédiat option est
utilisé et les ressources ne sont pas disponibles actuellement. Cela peut être utilisé par
un script pour distinguer les codes de sortie d'application de divers Slurm
conditions d'erreur. Regarde aussi SLURM_EXIT_ERROR.

SORTIE ENVIRONNEMENT VARIABLES

salloc définira les variables d'environnement suivantes dans l'environnement de l'exécution
programme:

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

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

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.

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_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 chaque nœud. Le plugin select/cons_res alloue des processeurs individuels à
travaux, ce nombre indique donc le nombre de processeurs sur chaque nœud alloués à
la répartition des tâches.

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 tâches.

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

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

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

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

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_NTASKS
Pareil que -n, --ntâches

SLURM_NTASKS_PER_NODE
Définissez la valeur de l'option --ntasks-per-node, si elle est spécifiée.

SLURM_PROFILE
Pareil que --profil

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.

SIGNAUX

Pendant que salloc attend une allocation de tâche EN ATTENTE, la plupart des signaux entraîneront salloc à
révoquer la demande d'allocation et quitter.

Cependant, si l'attribution a été accordée et que salloc a déjà commencé le
commande, alors salloc ignorera la plupart des signaux. salloc ne sortira pas ou ne libérera pas le
allocation jusqu'à ce que la commande se termine. Une exception notable est SIGHUP. Un signal SIGHUP
faire en sorte que salloc libère l'allocation et quitte sans attendre la fin de la commande.
Une autre exception est SIGTERM, qui sera transmise au processus généré.

EXEMPLES

Pour obtenir une allocation et ouvrir un nouveau xterm dans lequel les commandes srun peuvent être saisies
de manière interactive :

$ salloc -N16 xterme
salloc: Attribution d'emploi accordée 65537
(à ce stade, le xterm apparaît et salloc attend que xterm se termine)
salloc : Renonciation à l'attribution des emplois 65537

Pour saisir une allocation de nœuds et lancer une application parallèle sur une ligne de commande (Voir
le salloc page de manuel pour plus d'exemples):

salloc -N5 srun -n10 monprogramme

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.

Utilisez salloc en ligne en utilisant les services onworks.net