srun - Online nel cloud

PROGRAMMA:

NOME

srun - Esegui lavori paralleli

SINOSSI

svenuto [VERSIONI...] eseguibile [args...]

DESCRIZIONE

Esegui un lavoro parallelo sul cluster gestito da Slurm. Se necessario, srun creerà prima un
allocazione delle risorse in cui eseguire il lavoro parallelo.

Il seguente documento descrive l'influenza di varie opzioni sull'assegnazione di
CPU a lavori e attività.
http://slurm.schedmd.com/cpu_management.html

VERSIONI

--accel-bind=<Opzioni>
Controlla come le attività sono legate a risorse generiche di tipo gpu, mic e nic.
È possibile specificare più opzioni. Le opzioni supportate includono:

g Associa ogni attività alle GPU più vicine alle CPU allocate.

m Associa ogni attività ai MIC più vicini alle CPU allocate.

n Associa ogni attività alle NIC più vicine alle CPU allocate.

v Modalità dettagliata. Registra come le attività sono associate a GPU e dispositivi NIC.

-A, --account=<account>
Addebita le risorse utilizzate da questo lavoro sull'account specificato. Il account offre
stringa arbitraria. Il nome dell'account può essere modificato dopo l'invio del lavoro utilizzando il
controllare comando.

--acctg-freq
Definire gli intervalli di campionamento della contabilità lavori e della profilatura. Questo può essere usato per
sovrascrivere il JobAcctGatherFrequency parametro nel file di configurazione di Slurm,
slurm.conf. Il formato supportato è il seguente:

--acctg-freq==
where = specifica l'intervallo di campionamento dell'attività per
il plugin jobacct_gather o un intervallo di campionamento per un tipo di profilazione
dal plugin acct_gather_profile. Multipli, separati da virgole
= gli intervalli possono essere specificati. Tipi di dati supportati
sono come segue:

compito=
where è l'intervallo di campionamento dell'attività in secondi per
i plugin jobacct_gather e per la profilazione delle attività da parte del
plug-in acct_gather_profile. NOTA: questa frequenza viene utilizzata per
monitorare l'utilizzo della memoria. Se i limiti di memoria vengono applicati al massimo
la frequenza che un utente può richiedere è quella configurata nel
file slurm.conf. Non possono nemmeno disattivarlo (=0).

energia=
where è l'intervallo di campionamento in secondi per l'energia
profilazione utilizzando il plugin acct_gather_energy

rete=
where è l'intervallo di campionamento in secondi per
profilazione infiniband utilizzando il plugin acct_gather_infiniband.

filesystem=
where è l'intervallo di campionamento in secondi per
profilazione del filesystem utilizzando il plugin acct_gather_filesystem.

Il valore predefinito per l'intervallo di campionamento dell'attività
è 30. Il valore predefinito per tutti gli altri intervalli è 0. Un intervallo di 0 disabilita
campionamento del tipo specificato. Se l'intervallo di campionamento dell'attività è 0, contabilità
le informazioni vengono raccolte solo al termine del lavoro (riducendo l'interferenza di Slurm con
il lavoro).
Valori più piccoli (diversi da zero) hanno un impatto maggiore sulle prestazioni lavorative, ma un valore
di 30 secondi non è evidente per le applicazioni con meno di
10,000 compiti.

-B --extra-nodo-info=<Prese[:colori[:fili]]>
Richiedere un'assegnazione specifica delle risorse con dettagli su numero e tipo
di risorse computazionali all'interno di un cluster: numero di socket (o fisici
processori) per nodo, core per socket e thread per core. L'importo totale di
risorse richieste è il prodotto di tutti i termini. Ogni valore specificato
è considerato minimo. Un asterisco (*) può essere utilizzato come segnaposto per indicare
che tutte le risorse disponibili di quel tipo debbano essere utilizzate. Come con i nodi, il
i singoli livelli possono essere specificati anche in opzioni separate, se lo si desidera:
--prese-per-nodo=<Prese>
--core-per-socket=<colori>
--thread-per-core=<fili>
Se il plug-in task/affinity è abilitato, specificare un'allocazione in questo modo
imposta anche un valore predefinito --cpu_bind possibilità di fili se l' -B opzione specifica a
numero di thread, altrimenti un'opzione di colori se viene specificato un numero di core, altrimenti
un'opzione di Prese. Se SelectType è configurato per select/cons_res, deve avere
un parametro di CR_Core, CR_Core_Memory, CR_Socket o CR_Socket_Memory per questo
possibilità di essere onorato. Questa opzione non è supportata sui sistemi BlueGene
(il plugin select/bluegene è configurato). Se non specificato, lo show job di scontrol
visualizzerà 'ReqS:C:T=*:*:*'.

--bb=<spec>
Specifica del buffer di burst. La forma della specifica dipende dal sistema.
Vedi anche --bbf.

--bbf=<file_name>
Percorso del file contenente la specifica del buffer burst. La forma della specifica
è dipendente dal sistema. Vedi anche --bb.

--bcast[=percorso_destinazione>]
Copia il file eseguibile nei nodi di calcolo allocati. Se viene specificato un nome file, copia
l'eseguibile nel percorso del file di destinazione specificato. Se non viene specificato alcun percorso,
copia il file in un file chiamato "slurm_bcast_ . "nella corrente
Lavorando. Ad esempio, "srun --bcast=/tmp/mine -N3 a.out" copierà il file
"a.out" dalla directory corrente al file "/tmp/mine" su ciascuno dei tre
nodi di calcolo assegnati ed eseguire quel file.

--inizio=<tempo>
Rimanda l'inizio di questo lavoro fino all'ora specificata. Accetta gli orari del
modulo OO:MM:SS per eseguire un lavoro a un'ora specifica del giorno (i secondi sono facoltativi). (Se
quel tempo è già passato, si presume il giorno successivo.) Puoi anche specificare
mezzanotte, mezzogiorno, fika (3:XNUMX) o teatime (4:XNUMX) e puoi avere un'ora del giorno
con suffisso AM or PM per correre al mattino o alla sera. Puoi anche dire
in che giorno verrà eseguito il lavoro, specificando una data del modulo MMGGY or MM / DD / YY
AAAA-MM-DD. Combina data e ora utilizzando il seguente formato
AAAA-MM-GG[THH:MM[:SS]]. Puoi anche dare tempi come adesso + contare unità di tempoDurante la serata,
le unità di tempo possono essere secondo (Impostazione predefinita), verbale, ore, giorni, o settimana e si può
dì a Slurm di eseguire il lavoro oggi con la parola chiave oggi e per eseguire il lavoro domani
con la parola chiave domani. Il valore può essere modificato dopo l'invio del lavoro utilizzando il
controllare comando. Per esempio:
--inizio=16:00
--begin=ora+1ora
--begin=now+60 (secondi per impostazione predefinita)
--begin=2010-01-20T12:34:00

Note sulle specifiche di data/ora:
- Sebbene il campo 'secondi' della specifica del tempo HH:MM:SS sia consentito da
il codice, si noti che il tempo di polling dello scheduler Slurm non è abbastanza preciso da
garantire l'invio del lavoro nel secondo esatto. Il lavoro sarà idoneo a
iniziare al sondaggio successivo dopo l'ora specificata. L'esatto intervallo di polling
dipende dallo scheduler Slurm (es. 60 secondi con lo sched/integrato predefinito).
- Se non viene specificata alcuna ora (HH:MM:SS), il valore predefinito è (00:00:00).
- Se viene specificata una data senza anno (ad es. MM/GG), l'anno corrente è
presunto, a meno che la combinazione di MM/DD e HH:MM:SS sia già passata per questo
anno, nel qual caso viene utilizzato l'anno successivo.

--punto di controllo=<tempo>
Specifica l'intervallo tra la creazione dei checkpoint della fase di lavoro. Per impostazione predefinita,
la fase di lavoro non avrà checkpoint creati. I formati di ora accettabili includono
"minuti", "minuti:secondi", "ore:minuti:secondi", "giorni-ore",
"giorni-ore:minuti" e "giorni-ore:minuti:secondi".

--checkpoint-dir=<elenco>
Specifica la directory in cui dovrebbe essere il punto di controllo del lavoro o della fase di lavoro
scritto (usato solo dai plugin checkpoint/blcr e checkpoint/xlch). Il
il valore predefinito è la directory di lavoro corrente. I file di checkpoint saranno del
modulo " .ckpt" per i lavori e " . .ckpt" per le fasi del lavoro.

--commento=<stringa>
Un commento arbitrario.

-C, --vincolo=<stratagemma>
I nodi possono avere Caratteristiche assegnato loro dall'amministratore di Slurm. Gli utenti possono
specificare quale di questi Caratteristiche sono richiesti dal loro lavoro utilizzando il vincolo
opzione. Verranno utilizzati solo i nodi con caratteristiche corrispondenti ai vincoli del lavoro
soddisfare la richiesta. È possibile specificare più vincoli con AND, OR, matching
OPPURE, conteggio delle risorse, ecc. Le opzioni di vincolo supportate includono:

Singolo Nome
Verranno utilizzati solo i nodi che hanno la caratteristica specificata. Per esempio,
--constraint="intel"

Nodo Contare
Una richiesta può specificare il numero di nodi necessari con alcune funzionalità di
aggiungendo un asterisco e un conteggio dopo il nome della funzione. Per esempio
"--nodi=16 --vincolo=grafica*4 ... " indica che il lavoro richiede 16
nodi e che almeno quattro di questi nodi devono avere la caratteristica
"grafica."

E Se verranno utilizzati solo i nodi con tutte le caratteristiche specificate. La e commerciale è
utilizzato per un operatore AND. Per esempio, --constraint="intel&gpu"

OR Se verranno utilizzati solo nodi con almeno una delle caratteristiche specificate. Il
la barra verticale viene utilizzata per un operatore OR. Per esempio,
--constraint="intel|amd"

Abbinare OR
Se solo una di una serie di possibili opzioni dovesse essere utilizzata per tutte le allocazioni
nodi, quindi utilizzare l'operatore OR e racchiudere le opzioni all'interno del quadrato
parentesi. Per esempio: "--constraint=[rack1|rack2|rack3|rack4]" può essere
utilizzato per specificare che tutti i nodi devono essere allocati su un unico rack del
cluster, ma è possibile utilizzare uno qualsiasi di questi quattro rack.

multiplo Conti
È possibile specificare conteggi specifici di più risorse utilizzando AND
operatore e racchiudendo le opzioni tra parentesi quadre. Per esempio:
"--constraint=[rack1*2&rack2*4]" potrebbe essere usato per specificare che due nodi
deve essere allocato da nodi con la caratteristica di "rack1" e quattro nodi devono
essere allocato dai nodi con la caratteristica "rack2".

AVVERTIMENTO: Quando srun viene eseguito da salloc o sbatch,
il valore del vincolo può contenere solo un singolo nome di caratteristica. Nessuno degli altri
gli operatori sono attualmente supportati per le fasi di lavoro.

--contiguo
Se impostato, i nodi allocati devono formare un insieme contiguo. Non onorato con il
topologia/albero or topologia/3d_torus plugin, entrambi i quali possono modificare il nodo
ordinare. Non onorato per l'assegnazione di un passaggio di lavoro.

--core-per-socket=<colori>
Limita la selezione del nodo ai nodi con almeno il numero specificato di core per
presa. Vedi ulteriori informazioni sotto -B opzione sopra quando plugin task/affinity
è abilitato.

--cpu_bind=[{tranquillo, prolisso},]Digitare
Associa le attività alle CPU. Usato solo quando il plugin task/affinity o task/cgroup è
abilitato. Il parametro di configurazione TaskPluginParam può ignorare queste opzioni.
Per esempio, se TaskPluginParam è configurato per legarsi ai core, il tuo lavoro non lo farà
essere in grado di associare le attività ai socket. NOTA: Per fare in modo che Slurm riferisca sempre sul
associazione CPU selezionata per tutti i comandi eseguiti in una shell, puoi abilitare verbose
mode impostando il valore della variabile di ambiente SLURM_CPU_BIND su "verbose".

Le seguenti variabili di ambiente informative vengono impostate quando --cpu_bind è in
uso:
SLURM_CPU_BIND_VERBOSE
SLURM_CPU_BIND_TYPE
SLURM_CPU_BIND_LIST

Vedere la AMBIENTE VARIABILI sezione per una descrizione più dettagliata del
singole variabili SLURM_CPU_BIND. Queste variabili sono disponibili solo se il
il plugin task/affinity è configurato.

Quando si usa --cpus-per-attività per eseguire attività multithread, tieni presente che il binding della CPU è
ereditato dal genitore del processo. Ciò significa che l'attività multithread
dovrebbe specificare o cancellare l'associazione della CPU stessa per evitare di avere tutti i thread
dell'attività multithread usa la stessa maschera/CPU del genitore. In alternativa, grasso
le maschere (maschere che specificano più di una CPU consentita) potrebbero essere utilizzate per le attività
al fine di fornire più CPU per le attività multithread.

Per impostazione predefinita, una fase di lavoro ha accesso a ogni CPU assegnata al lavoro. Per garantire
che a ciascuna fase del lavoro siano allocate CPU distinte, utilizzare il --esclusivo opzione.

Si noti che a una fase di lavoro possono essere assegnati diversi numeri di CPU su ciascun nodo o essere
CPU allocate che non iniziano dalla posizione zero. Quindi una delle opzioni che
si consiglia di generare automaticamente l'associazione di attività. Maschere esplicitamente specificate
o le associazioni vengono onorate solo quando il passaggio del lavoro è stato assegnato ogni disponibile
CPU sul nodo.

Associare un'attività a un dominio di località NUMA significa associare l'attività all'insieme di CPU
che appartengono al dominio di località NUMA o "nodo NUMA". Se il dominio della località NUMA
le opzioni sono utilizzate su sistemi senza supporto NUMA, quindi ogni socket è considerato a
dominio di località.

Automatico Rilegatura
Si applica solo quando attività/affinità è abilitata. Se l'allocazione delle fasi di lavoro
include un'allocazione con un numero di socket, core o thread pari a
il numero di attività volte CPU-per-attività, quindi le attività saranno per impostazione predefinita
associato alle risorse appropriate (associazione automatica). Disattiva questa modalità di
operazione impostando esplicitamente "--cpu_bind=none". Uso
TaskPluginParam=autobind=[threads|cores|sockets] per impostare una cpu predefinita
associazione nel caso in cui "associazione automatica" non trovi una corrispondenza.

Le opzioni supportate includono:

calmatevi]
Associa silenziosamente prima dell'esecuzione dell'attività (impostazione predefinita)

v[erboso]
Segnalare in modo dettagliato l'associazione prima dell'esecuzione dell'attività

nessuno] Non associare attività alle CPU (impostazione predefinita a meno che non venga applicata l'associazione automatica)

classifica Associa automaticamente per grado di attività. Il compito con il numero più basso su ciascuno
il nodo è associato a zero socket (o core o thread), ecc. Non supportato
a meno che l'intero nodo non sia assegnato al lavoro.

mappa_cpu:
Associa mappando gli ID della CPU alle attività come specificato dove è
, ,... . La mappatura è specificata per un nodo
e la mappatura identica viene applicata alle attività su ogni nodo (cioè il
L'ID attività più basso su ciascun nodo è mappato al primo ID CPU specificato
nell'elenco, ecc.). Gli ID CPU vengono interpretati come valori decimali a meno che
sono preceduti da '0x' nel qual caso vengono interpretati come
valori esadecimali. Non supportato a meno che l'intero nodo non sia
assegnato al lavoro.

maschera_cpu:
Associa impostando le maschere della CPU sulle attività come specificato dove è
, ,... . La mappatura è specificata per un nodo e
la mappatura identica viene applicata alle attività su ogni nodo (cioè il
L'ID attività più basso su ciascun nodo è mappato alla prima maschera specificata in
l'elenco, ecc.). Le maschere della CPU sono sempre interpretato come esadecimale
valori ma può essere preceduto da un '0x' opzionale. Non supportato
a meno che l'intero nodo non sia assegnato al lavoro.

rango_ldom
Associa a un dominio di località NUMA in base al rango. Non supportato a meno che il
l'intero nodo è allocato al lavoro.

map_ldom:
Associa mappando gli ID di dominio della località NUMA alle attività come specificato dove
è , ,... . Gli ID del dominio della località sono
interpretati come valori decimali a meno che non siano preceduti da '0x' in
nel qual caso vengono interpretati come valori esadecimali. Non supportato
a meno che l'intero nodo non sia assegnato al lavoro.

mask_ldom:
Associa impostando le maschere di dominio di località NUMA sulle attività come specificato
dove è , ,... . Dominio località NUMA
le maschere sono sempre interpretati come valori esadecimali ma possono essere
preceduto da un '0x' opzionale. Non supportato a meno che l'intero nodo
è assegnato al lavoro.

Prese
Genera automaticamente maschere che associano attività ai socket. Solo le CPU
sul socket che è stato assegnato al lavoro verrà utilizzato. Se
il numero di task differisce dal numero di socket allocati questo
può comportare un legame non ottimale.

colori Genera automaticamente maschere che vincolano le attività ai core. Se il numero
di compiti differisce dal numero di core allocati che ne può derivare
nel legame subottimale.

fili
Genera automaticamente maschere che associano attività ai thread. Se il numero
di attività differisce dal numero di thread allocati che ciò può comportare
nel legame subottimale.

ldom Genera automaticamente le attività di associazione delle maschere ai domini di località NUMA.
Se il numero di compiti è diverso dal numero di località assegnate
domini questo può comportare un legame non ottimale.

schede Genera automaticamente maschere che associano attività alle schede. Se il numero
di compiti differisce dal numero di schede assegnate che ciò può comportare
nel legame subottimale. Questa opzione è supportata dal task/cgroup
solo plug-in.

Aiuto Mostra messaggio di aiuto per cpu_bind

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

Richiedi che il passaggio del lavoro avviato da questo comando srun venga eseguito in qualche momento richiesto
frequenza, se possibile, sulle CPU selezionate per il passaggio sui nodi di calcolo.

p1 può essere [#### | basso | medio | alto | highm1] che imposterà la frequenza
scaling_speed al valore corrispondente e impostare la frequenza scaling_governor su
Spazio utente. Vedi sotto per la definizione dei valori.

p1 può essere [Conservativo | OnDemand | Prestazioni | PowerSave] che imposterà il
scaling_governor al valore corrispondente. Il governatore deve essere nell'elenco impostato
dall'opzione slurm.conf CpuFreqGovernors.

Quando p2 è presente, p1 sarà la frequenza di scala minima e p2 sarà la
frequenza di scalatura massima.

p2 può essere [#### | medio | alto | highm1] p2 deve essere maggiore di p1.

p3 può essere [Conservativo | OnDemand | Prestazioni | Risparmio energetico | UserSpace] che
imposterà il governatore al valore corrispondente.

If p3 è UserSpace, la frequenza scaling_speed sarà impostata da una potenza o energia
strategia di pianificazione consapevole a un valore compreso tra p1 e p2 che consente l'esecuzione del lavoro entro
l'obiettivo di potenza del sito. Il lavoro può essere ritardato se p1 è maggiore di una frequenza che
consente al lavoro di funzionare all'interno dell'obiettivo.

Se la frequenza corrente è < min, sarà impostata su min. Allo stesso modo, se la corrente
frequenza è > max, sarà impostata su max.

I valori accettabili attualmente includono:

#### frequenza in kilohertz

Basso la frequenza più bassa disponibile

Alta la frequenza più alta disponibile

AltoM1 (alto meno uno) selezionerà la successiva frequenza più alta disponibile

Medio tenta di impostare una frequenza nel mezzo della gamma disponibile

Prudente tenta di utilizzare il governor CPU conservatore

Su richiesta tenta di utilizzare il governor della CPU OnDemand (il valore predefinito)

Cookie di prestazione tenta di utilizzare il regolatore della CPU delle prestazioni

Risparmio energetico tenta di utilizzare il governor della CPU PowerSave

Spazio utente tenta di utilizzare il governatore della CPU UserSpace

La seguente variabile di ambiente informativa è impostata nel lavoro
passo quando --freq-cpu l'opzione è richiesta.
SLURM_CPU_FREQ_REQ

Questa variabile d'ambiente può essere utilizzata anche per fornire il valore per la CPU
richiesta di frequenza se impostata al momento dell'emissione del comando 'srun'. Il --freq-cpu
sulla riga di comando sovrascriverà il valore della variabile di ambiente. Il modulo sul
la variabile di ambiente è la stessa della riga di comando. Vedi il AMBIENTE
VARIABILI sezione per una descrizione della variabile SLURM_CPU_FREQ_REQ.

NOTA: questo parametro viene considerato come una richiesta, non come un requisito. Se il passaggio del lavoro è
il nodo non supporta l'impostazione della frequenza della CPU o il valore richiesto è esterno
i limiti delle frequenze legali, viene registrato un errore, ma il passaggio del lavoro è
permesso di continuare.

NOTA: L'impostazione della frequenza per le sole CPU della fase di lavoro implica che il
le attività sono limitate a quelle CPU. Se il confinamento del compito (es.
TaskPlugin=task/affinity o TaskPlugin=task/cgroup con "ConstrainCores"
opzione) non è configurato, questo parametro viene ignorato.

NOTA: Al termine del passaggio, la frequenza e il regolatore di ciascuna CPU selezionata è
ripristinare il configurato CPUFreqDef valore con un valore predefinito della CPU OnDemand
governatore.

NOTA: Quando si inviano lavori con il --freq-cpu opzione con linuxproc come
ProctrackType può causare l'esecuzione troppo rapida dei lavori prima che Contabilità sia in grado di eseguire il polling
per informazioni sul lavoro. Di conseguenza non tutte le informazioni contabili saranno presenti.

-c, --cpus-per-attività=<ncpus>
Richiedilo ncpus essere assegnato per processi. Questo può essere utile se il lavoro è
multithread e richiede più di una CPU per attività per prestazioni ottimali. Il
l'impostazione predefinita è una CPU per processo. Se -c è specificato senza -n, quante attività lo faranno
essere allocato per nodo il più possibile soddisfacendo il -c restrizione. Ad esempio
su un cluster con 8 CPU per nodo, una richiesta di lavoro per 4 nodi e 3 CPU per task
possono essere allocate 3 o 6 CPU per nodo (1 o 2 task per nodo) a seconda di
consumo di risorse da parte di altri lavori. Tale lavoro potrebbe non essere in grado di eseguire più di a
totale di 4 compiti. Questa opzione può essere utile anche per generare attività senza assegnare
risorse alla fase di lavoro dall'allocazione del lavoro durante l'esecuzione di più fasi di lavoro
con la --esclusivo opzione.

AVVERTIMENTO: Esistono configurazioni e opzioni interpretate in modo diverso a seconda del lavoro e
richieste di fasi di lavoro che possono causare incongruenze per questa opzione. Per esempio
svenuto -c2 --thread-per-core=1 prog può allocare due core per il lavoro, ma se ciascuno
di questi core contiene due thread, l'allocazione del lavoro includerà quattro CPU. Il
L'allocazione dei passaggi di lavoro avvierà quindi due thread per CPU per un totale di due attività.

AVVERTIMENTO: Quando srun viene eseguito da salloc o sbatch, ci sono
configurazioni e opzioni che possono risultare in allocazioni incoerenti quando -c ha
un valore maggiore di -c su salloc o sbatch.

-d, --dipendenza=<lista_dipendenze>
Rimanda l'inizio di questo lavoro fino a quando le dipendenze specificate non sono state soddisfatte
completato. Questa opzione non si applica alle fasi del lavoro (esecuzioni di srun all'interno di un
salloc esistente o allocazione di lotti) solo alle allocazioni di posti di lavoro.lista_dipendenze>
è della formatipo:job_id[:job_id][,tipo:job_id[:job_id]]> o
<digita:job_id[:job_id][?tipo:job_id[:job_id]]>. Tutte le dipendenze devono essere soddisfatte
se viene utilizzato il separatore ",". Qualsiasi dipendenza può essere soddisfatta se il "?" separatore
viene utilizzato. Molti lavori possono condividere la stessa dipendenza e questi lavori possono anche appartenere a
utenti diversi. Il valore può essere modificato dopo l'invio del lavoro utilizzando scontrol
comando. Una volta che una dipendenza del lavoro fallisce a causa dello stato di terminazione di un precedente
lavoro, il lavoro dipendente non verrà mai eseguito, anche se il lavoro precedente viene rimesso in coda e
ha uno stato di terminazione diverso in un'esecuzione successiva.

dopo:id_lavoro[:id_lavoro...]
Questo lavoro può iniziare l'esecuzione dopo che i lavori specificati hanno iniziato l'esecuzione.

afterany:id_lavoro[:idlavoro...]
Questo lavoro può iniziare l'esecuzione dopo che i lavori specificati sono terminati.

afternotok:id_lavoro[:idlavoro...]
Questo lavoro può iniziare l'esecuzione dopo che i lavori specificati sono terminati in
qualche stato non riuscito (codice di uscita diverso da zero, errore del nodo, timeout, ecc.).

afterok:id_lavoro[:idlavoro...]
Questo lavoro può iniziare l'esecuzione dopo che i lavori specificati sono stati eseguiti correttamente
eseguito (ha eseguito fino al completamento con un codice di uscita pari a zero).

espandi:job_id
Le risorse allocate a questo lavoro devono essere utilizzate per espandere il lavoro specificato.
Il lavoro da espandere deve condividere lo stesso QOS (Quality of Service) e
partizione. Anche la pianificazione di gruppo delle risorse nella partizione non lo è
supportato.

singleton
Questo lavoro può iniziare l'esecuzione dopo che tutti i lavori avviati in precedenza condividono il
stesso nome lavoro e utente sono stati terminati.

-D, --chdir=<sentiero>
Chiedi ai processi remoti di eseguire una chdir per sentiero prima di iniziare l'esecuzione. Il
l'impostazione predefinita è chdir nella directory di lavoro corrente del svenuto processi. Il sentiero
può essere specificato come percorso completo o percorso relativo alla directory in cui si trova il comando
viene eseguito.

-e, --errore=<modo>
Specifica come stderr deve essere reindirizzato. Per impostazione predefinita, in modalità interattiva, svenuto
reindirizza stderr allo stesso file di stdout, se ne viene specificato uno. Il --errore
viene fornita un'opzione per consentire a stdout e stderr di essere reindirizzati a diversi
posizioni. Vedere IO Reindirizzamento di seguito per ulteriori opzioni. Se il file specificato
esiste già, verrà sovrascritto.

-E, --preserve-env
Passa i valori correnti delle variabili di ambiente SLURM_NNODES e SLURM_NTASKS
attraverso il eseguibile, invece di calcolarli dai parametri della riga di comando.

--epilogo=<eseguibile>
svenuto correrà eseguibile subito dopo il completamento della fase di lavoro. La riga di comando
argomenti per eseguibile sarà il comando e gli argomenti del passaggio del lavoro. Se
eseguibile è "none", quindi non verrà eseguito alcun epilogo srun. Questo parametro ha la precedenza su
Parametro SrunEpilog in slurm.conf. Questo parametro è completamente indipendente da
il parametro Epilog in slurm.conf.

--exclusive[=utente]
Questa opzione ha due significati leggermente diversi per le allocazioni del lavoro e delle fasi di lavoro.
Quando viene utilizzato per avviare un lavoro, l'allocazione del lavoro non può condividere nodi con altri
lavori in esecuzione (o solo altri utenti con l'opzione "=user"). Il predefinito
il comportamento condiviso/esclusivo dipende dalla configurazione del sistema e dalla partizione
diviso l'opzione ha la precedenza sull'opzione del lavoro.

Questa opzione può essere utilizzata anche quando si avviano più fasi di lavoro all'interno di un
allocazione delle risorse esistenti, a cui si desidera dedicare processori separati
ogni fase del lavoro. Se non sono disponibili processori sufficienti per avviare la fase di lavoro,
sarà differito. Questo può essere pensato come fornire un meccanismo per le risorse
gestione al lavoro all'interno della sua allocazione.

L'assegnazione esclusiva delle CPU si applica solo alle fasi di lavoro richiamate esplicitamente con
, il --esclusivo opzione. Ad esempio, a un lavoro potrebbe essere assegnato un nodo con quattro
CPU e una shell remota invocate sul nodo allocato. Se quella shell non viene invocata
con la --esclusivo opzione, quindi può creare una fase di lavoro con quattro attività utilizzando
, il --esclusivo opzione e non è in conflitto con la risorsa della shell remota
allocazione. Utilizzare il --esclusivo opzione per richiamare ogni fase del lavoro per assicurare distinti
risorse per ogni passaggio.

Notare che tutte le CPU assegnate a un lavoro sono disponibili per ogni fase del lavoro a meno che il
--esclusivo viene utilizzata l'opzione e viene configurata l'affinità dell'attività. Dal momento che la risorsa
la gestione è fornita dal processore, il --tasks l'opzione deve essere specificata, ma il
le seguenti opzioni NON devono essere specificate --parente, --distribuzione=arbitrario.
See ESEMPIO qua sotto.

--esportare=<Industria XNUMX variabili | NONE>
Identificare quali variabili di ambiente vengono propagate all'applicazione avviata.
I nomi di più variabili di ambiente devono essere separati da virgole. Ambiente
i nomi delle variabili possono essere specificati per propagare il valore corrente di quelle variabili
(es. "--export=EDITOR") o possono essere esportati valori specifici per le variabili
(es. "--export=EDITOR=/bin/vi") oltre alle variabili d'ambiente che
sarebbe altrimenti impostato. Per impostazione predefinita, vengono propagate tutte le variabili di ambiente.

--ddio=<gruppo>
If svenuto viene eseguito come root e il --ddio viene utilizzata l'opzione, invia il lavoro con gruppo's
permessi di accesso di gruppo. gruppo può essere il nome del gruppo o l'ID numerico del gruppo.

--gres=<stratagemma>
Specifica un elenco delimitato da virgole di risorse consumabili generiche. Il formato di
ogni voce dell'elenco è "name[[:type]:count]". Il nome è quello di
risorsa consumabile. Il conteggio è il numero di quelle risorse con un valore predefinito
valore di 1. Le risorse specificate verranno allocate al lavoro su ciascun nodo.
Le risorse consumabili generiche disponibili sono configurabili dal sistema
amministratore. Verrà stampato un elenco delle risorse consumabili generiche disponibili
e il comando uscirà se l'argomento dell'opzione è "help". Esempi di utilizzo
includi "--gres=gpu:2,mic=1", "--gres=gpu:kepler:2" e "--gres=help". NOTA: da
impostazione predefinita, a una fase di lavoro vengono allocate tutte le risorse generiche che sono state allocate
al lavoro. Per modificare il comportamento in modo che a ogni fase del lavoro non venga assegnato un generico
risorse, imposta esplicitamente il valore di --gres per specificare zero conteggi per ciascuno
risorsa generica OPPURE imposta "--gres=none" OPPURE imposta l'ambiente SLURM_STEP_GRES
variabile su "nessuno".

-H, --presa
Specificare che il lavoro deve essere inviato in stato di attesa (priorità zero). Un lavoro tenuto
ora può essere rilasciato usando scontrol per reimpostare la sua priorità (es "controllare rilasciare
").

-h, --Aiuto
Visualizza le informazioni della guida ed esci.

--suggerimento=<Digitare>
Associa le attività in base ai suggerimenti dell'applicazione.

compute_bound
Seleziona le impostazioni per le applicazioni legate al calcolo: usa tutti i core in ciascuna
socket, un thread per core.

legato alla memoria
Seleziona le impostazioni per le applicazioni legate alla memoria: usa solo un core in ciascuna
socket, un thread per core.

[nessun]multithread
[non] utilizzare thread extra con il multi-threading in-core che può trarne vantaggio
applicazioni ad alta intensità di comunicazione. Supportato solo con l'attività/affinità
.

Aiuto mostra questo messaggio di aiuto

-I, --immediato[=secondo>]
esci se le risorse non sono disponibili entro il periodo di tempo specificato. se no
argomento è dato, le risorse devono essere immediatamente disponibili per la richiesta a
avere successo. Per impostazione predefinita, --immediato è spento e il comando si bloccherà fino a quando
risorse diventano disponibili. Poiché l'argomento di questa opzione è facoltativo, per corretto
l'analisi dell'opzione a lettera singola deve essere seguita immediatamente dal valore e
non includere uno spazio tra di loro. Ad esempio "-I60" e non "-I 60".

-i, --ingresso=<modo>
Specifica come stdin deve essere reindirizzato. Per impostazione predefinita, svenuto reindirizza lo stdin dal
terminale tutte le attività. Vedere IO Reindirizzamento di seguito per ulteriori opzioni. Per OS X, il
La funzione poll() non supporta stdin, quindi l'input da un terminale non è possibile.

-J, --nome del lavoro=<nome del lavoro>
Specificare un nome per il lavoro. Il nome specificato apparirà insieme all'id del lavoro
numero quando si interrogano i lavori in esecuzione sul sistema. L'impostazione predefinita è quella fornita
eseguibile nome del programma. NOTA: Queste informazioni possono essere scritte sul
file slurm_jobacct.log. Questo file è delimitato da spazi quindi se viene utilizzato uno spazio nel
nome del lavoro nome causerà problemi nella corretta visualizzazione del contenuto del
slurm_jobacct.log file quando il sacco viene utilizzato il comando.

--jobid=<ID lavoro>
Avviare una fase di lavoro in un lavoro già assegnato con ID lavoro id. Usando questo
l'opzione causerà svenuto comportarsi esattamente come se l'ambiente SLURM_JOB_ID
variabile è stata impostata.

-K, --kill-on-bad-exit[=0|1]
Controlla se terminare o meno un lavoro se un'attività termina con un'uscita diversa da zero
codice. Se questa opzione non è specificata, l'azione predefinita sarà basata su
Parametro di configurazione slurm di KillOnBadEsci. Se questa opzione è specificata, è
avrà la precedenza su KillOnBadEsci. Un argomento di opzione pari a zero non lo farà
terminare il lavoro. Un argomento diverso da zero o nessun argomento terminerà il lavoro.
Nota: questa opzione ha la precedenza su -W, --aspettare possibilità di terminare il lavoro
immediatamente se un'attività termina con un codice di uscita diverso da zero. Poiché questa opzione è
l'argomento è facoltativo, per un'analisi corretta deve essere seguita l'opzione a lettera singola
immediatamente con il valore e non includere uno spazio tra di loro. Ad esempio "-K1"
e non "-K 1".

-k, --non uccidere
Non terminare automaticamente un lavoro se uno dei nodi a cui è stato assegnato
non riesce. Questa opzione è riconosciuta solo su un'assegnazione di lavoro, non per la presentazione
delle singole fasi lavorative. Il lavoro si assumerà tutte le responsabilità per
tolleranza ai guasti. Le attività avviate utilizzando questa opzione non saranno considerate terminate
(per esempio -K, --kill-on-bad-exit e -W, --aspettare le opzioni non avranno alcun effetto sul
fase lavorativa). Il passaggio del lavoro attivo (lavoro MPI) probabilmente subirà un errore fatale, ma
Se viene specificata questa opzione, è possibile eseguire i passaggi successivi del lavoro. L'azione predefinita è
per terminare il lavoro in caso di errore del nodo.

--launch-cmd
Stampa il comando di avvio esterno invece di eseguire normalmente il lavoro tramite Slurm. Questo
l'opzione è valida solo se si utilizza qualcosa di diverso da lancio/slurm .

--launcher-opzioni=<Opzioni>
Opzioni per il launcher esterno se si utilizza qualcosa di diverso da lancio/slurm
.

-l, --etichetta
Anteponi il numero dell'attività alle righe di stdout/err. Il --etichetta l'opzione antepone le righe
di output con l'id dell'attività remota.

-L, --licenze=<licenza>
Specifica delle licenze (o altre risorse disponibili su tutti i nodi del
cluster) che deve essere assegnato a questo lavoro. I nomi delle licenze possono essere seguiti da a
due punti e conteggio (il conteggio predefinito è uno). I nomi di più licenze devono essere virgole
separati (es. "--licenses=foo:4,bar").

-m, --distribuzione=
*|bloccare|ciclico|arbitrario|piano= [:*|bloccare|ciclico|fciclico[:*|bloccare|
ciclico|fciclico]] [,PACK|Nessun pacchetto]

Specificare metodi di distribuzione alternativi per i processi remoti. Questa opzione controlla
la distribuzione dei compiti ai nodi su cui sono state allocate le risorse, e
la distribuzione di tali risorse alle attività per l'associazione (affinità di attività). Il primo
metodo di distribuzione (prima del primo ":") controlla la distribuzione dei compiti a
nodi. Il secondo metodo di distribuzione (dopo il primo ":") controlla il
distribuzione delle CPU allocate tra i socket per l'associazione alle attività. Il terzo
metodo di distribuzione (dopo il secondo ":") controlla la distribuzione degli allocati
CPU tra i core per l'associazione alle attività. Si applicano la seconda e la terza distribuzione
solo se l'affinità attività è abilitata. La terza distribuzione è supportata solo se il
il plugin task/cgroup è configurato. Il valore predefinito per ogni tipo di distribuzione è
specificato da *.

Nota che con select/cons_res, il numero di CPU allocate su ciascun socket e
il nodo potrebbe essere diverso. Fare riferimento a http://slurm.schedmd.com/mc_support.html per maggiori
informazioni sull'allocazione delle risorse, la distribuzione dei compiti ai nodi e l'associazione di
compiti alle CPU.
Primo metodo di distribuzione (distribuzione delle attività tra i nodi):

* Utilizzare il metodo predefinito per distribuire le attività ai nodi (blocco).

bloccare Il metodo di distribuzione dei blocchi distribuirà le attività a un nodo in modo tale che
attività consecutive condividono un nodo. Ad esempio, si consideri un'allocazione di tre
nodi ciascuno con due CPU. Una richiesta di distribuzione del blocco di quattro attività sarà
distribuire quei compiti ai nodi con i compiti uno e due sul primo
nodo, attività tre sul secondo nodo e attività quattro sul terzo nodo. Bloccare
distribuzione è il comportamento predefinito se il numero di attività supera il
numero di nodi allocati.

ciclico Il metodo di distribuzione ciclica distribuirà le attività a un nodo in modo tale che
le attività consecutive sono distribuite su nodi consecutivi (in un round-robin
moda). Ad esempio, si consideri un'allocazione di tre nodi ciascuno con due
cpu. Una richiesta di distribuzione ciclica di quattro attività distribuirà tali attività a
i nodi con compiti uno e quattro sul primo nodo, compito due sul secondo
nodo e l'attività tre sul terzo nodo. Nota che quando SelectType è
select/cons_res, lo stesso numero di CPU potrebbe non essere allocato su ciascun nodo.
La distribuzione delle attività sarà round-robin tra tutti i nodi con CPU ancora da
essere assegnato ai compiti. La distribuzione ciclica è il comportamento predefinito se il
il numero di attività non è maggiore del numero di nodi allocati.

piano Le attività sono distribuite in blocchi di una dimensione specificata. Le opzioni
includere un numero che rappresenta la dimensione del blocco attività. Questo è seguito
da una specifica facoltativa dello schema di distribuzione dei compiti all'interno di un blocco
di compiti e tra i blocchi di compiti. Il numero di compiti distribuiti
a ciascun nodo è lo stesso della distribuzione ciclica, ma i taskid
assegnati a ciascun nodo dipendono dalla dimensione del piano. Per maggiori dettagli (incluso
esempi e diagrammi), vedere
http://slurm.schedmd.com/mc_support.html
e
http://slurm.schedmd.com/dist_plane.html

arbitrario
Il metodo arbitrario di distribuzione allocherà i processi in ordine come
elencato nel file designato dalla variabile d'ambiente SLURM_HOSTFILE. Se
questa variabile è elencata sovrascriverà qualsiasi altro metodo specificato. Se
non impostato, il metodo verrà bloccato per impostazione predefinita. All'interno del file host deve contenere
almeno il numero di host richiesti ed essere uno per riga o virgola
separato. Se si specifica un conteggio attività (-n, --tasks=<numero>), i tuoi compiti
sarà disposto sui nodi nell'ordine del file.
NOTA: L'opzione di distribuzione arbitraria su un'assegnazione di lavoro controlla solo
i nodi da allocare al lavoro e non l'allocazione delle CPU su quelli
nodi. Questa opzione ha lo scopo principale di controllare il layout dell'attività di una fase di lavoro in
un'allocazione di lavoro esistente per il comando srun.

Secondo metodo di distribuzione (distribuzione delle CPU tra i socket per il binding):

* Utilizzare il metodo predefinito per la distribuzione delle CPU tra i socket (ciclico).

bloccare Il metodo di distribuzione a blocchi distribuirà le CPU allocate consecutivamente
dallo stesso socket per il binding ai task, prima di utilizzare il successivo consecutivo
zoccolo.

ciclico Il metodo di distribuzione ciclica distribuirà le CPU allocate per l'associazione a
un dato compito consecutivamente dallo stesso socket, e dal successivo
presa consecutiva per l'attività successiva, in modo round-robin attraverso
prese.

fciclico
Il metodo di distribuzione fciclico distribuirà le CPU allocate per il binding
alle attività da socket consecutivi in ​​modo round-robin attraverso il
prese.

Terzo metodo di distribuzione (distribuzione delle CPU tra i core per l'associazione):

* Usa il metodo predefinito per distribuire le CPU tra i core (ereditato da
secondo metodo di distribuzione).

bloccare Il metodo di distribuzione a blocchi distribuirà le CPU allocate consecutivamente
dallo stesso core per il binding alle attività, prima di utilizzare il successivo consecutivo
nucleo.

ciclico Il metodo di distribuzione ciclica distribuirà le CPU allocate per l'associazione a
un dato compito consecutivamente dallo stesso core, e dal successivo consecutivo
core per l'attività successiva, in modo round robin tra i core.

fciclico
Il metodo di distribuzione fciclico distribuirà le CPU allocate per il binding
alle attività da core consecutivi in ​​modo round robin tra i core.

Controllo opzionale per la distribuzione delle attività sui nodi:

PACK Invece di distribuire uniformemente le attività di una fase di lavoro in modo uniforme, è
nodi assegnati, impacchettarli il più strettamente possibile sui nodi.

Nessun pacchetto Piuttosto che impacchettare le attività di una fase di lavoro il più strettamente possibile sui nodi,
distribuirli uniformemente. Questa opzione utente sostituirà la
Parametro di configurazione SelectTypeParameters CR_Pack_Nodes.

--tipo-mail=<Digitare>
Avvisa l'utente tramite e-mail quando si verificano determinati tipi di eventi. Valido Digitare i valori sono NESSUNO,
BEGIN, END, FAIL, REQUEUE, ALL (equivalente a BEGIN, END, FAIL, REQUEUE e
STAGE_OUT), STAGE_OUT (uscita buffer burst completata), TIME_LIMIT, TIME_LIMIT_90
(ha raggiunto il 90% del limite di tempo), TIME_LIMIT_80 (ha raggiunto l'80% del tempo
limite) e TIME_LIMIT_50 (ha raggiunto il 50% del limite di tempo). multiplo Digitare valori
può essere specificato in un elenco separato da virgole. Viene indicato l'utente da avvisare
con --mail-utente.

--mail-utente=<Utente>
L'utente riceverà la notifica via e-mail dei cambiamenti di stato come definito da --tipo-mail.
il valore predefinito è l'utente che effettua l'invio.

--meme=<MB>
Specificare la memoria reale richiesta per nodo in MegaByte. Il valore predefinito è
DefMemPerNodo e il valore massimo è MaxMemPerNodo. Se configurato, entrambi di
i parametri possono essere visualizzati utilizzando il controllare mostrare attraverso le sue creazioni config comando. Questo parametro
verrebbe generalmente utilizzato se interi nodi sono assegnati ai lavori
(SelectType=seleziona/lineare). Specificare un limite di memoria pari a zero per una fase di lavoro sarà
limitare la fase del lavoro alla quantità di memoria assegnata al lavoro, ma non rimuoverla
qualsiasi allocazione di memoria del lavoro sia disponibile per altre fasi del lavoro. Anche
vedere --mem-per-cpu. --meme e --mem-per-cpu si escludono a vicenda. NOTA: Un ricordo
la specifica della taglia è trattata come un caso speciale e garantisce l'accesso al lavoro a tutti
la memoria su ogni nodo. NOTA: l'applicazione dei limiti di memoria attualmente si basa su
il plugin task/cgroup o l'abilitazione dell'accounting, che campiona l'utilizzo della memoria su a
base periodica (i dati non devono essere conservati, solo raccolti). In entrambi i casi uso della memoria
si basa sulla dimensione del set residente (RSS) del lavoro. Un'attività può superare il limite di memoria
fino al successivo campione contabile periodico.

--mem-per-cpu=<MB>
Memoria minima richiesta per CPU allocata in MegaByte. Il valore predefinito è
DefMemPerCPU e il valore massimo è MaxMemPerCPU (vedi eccezione sotto). Se
configurato, entrambi i parametri possono essere visualizzati utilizzando il controllare mostrare attraverso le sue creazioni config comando.
Nota che se il lavoro è --mem-per-cpu il valore supera il configurato MaxMemPerCPU,
quindi il limite dell'utente verrà trattato come un limite di memoria per attività; --mem-per-cpu
sarà ridotto a un valore non maggiore di MaxMemPerCPU; --cpus-per-attività sarà impostato
e il valore di --cpus-per-attività moltiplicato per il nuovo --mem-per-cpu il valore sarà
uguale all'originale --mem-per-cpu valore specificato dall'utente. Questo parametro sarebbe
generalmente essere utilizzato se i singoli processori sono assegnati ai lavori
(SelectType=seleziona/ris_cons). Se le risorse sono allocate dal core, socket o
interi nodi; il numero di CPU allocate a un lavoro può essere maggiore del compito
conteggio e il valore di --mem-per-cpu dovrebbe essere regolato di conseguenza. Specificando a
limite di memoria pari a zero per un passaggio di lavoro limiterà il passaggio di lavoro alla quantità di
memoria allocata al lavoro, ma non rimuovere alcuna allocazione di memoria del lavoro da
disponibilità ad altre fasi del lavoro. Vedi anche --meme. --meme e --mem-per-cpu sono
si escludono a vicenda.

--mem_bind=[{tranquillo, prolisso},]Digitare
Associa le attività alla memoria. Utilizzato solo quando il plugin task/affinity è abilitato e il
Sono disponibili funzioni di memoria NUMA. Note: che , il risoluzione of CPU e memoria
rilegatura può differire on alcuni architetture. Ad esempio, è possibile eseguire il binding della CPU
a livello dei core all'interno di un processore mentre verrà eseguito il binding della memoria
a livello di nodi, dove la definizione di "nodi" può differire da sistema a
. uso of in qualsiasi Digitare Altro di "nessuna" or "Locale" is non è un raccomandato. If
vuoi un maggiore controllo, prova a eseguire un semplice codice di prova con le opzioni
"--cpu_bind=verbose,none --mem_bind=verbose,none" per determinare lo specifico
configurazione.

NOTA: Per fare in modo che Slurm riporti sempre l'associazione di memoria selezionata per tutti i comandi
eseguito in una shell, puoi abilitare la modalità dettagliata impostando SLURM_MEM_BIND
valore della variabile d'ambiente su "verbose".

Le seguenti variabili di ambiente informative vengono impostate quando --mem_bind è in
uso:

SLURM_MEM_BIND_VERBOSE
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_LIST

Vedere la AMBIENTE VARIABILI sezione per una descrizione più dettagliata del
variabili SLURM_MEM_BIND* individuali.

Le opzioni supportate includono:

calmatevi]
associazione silenziosa prima dell'esecuzione dell'attività (impostazione predefinita)

v[erboso]
segnalare in modo dettagliato l'associazione prima dell'esecuzione dell'attività

nessuno] non associare le attività alla memoria (impostazione predefinita)

classifica associazione per grado di attività (non consigliato)

locale Usa memoria locale per il processore in uso

map_mem:
associare mappando la memoria di un nodo alle attività come specificato dove è
, ,... . Gli ID CPU sono interpretati come valori decimali
a meno che non siano preceduti da '0x', nel qual caso sono interpretati come
valori esadecimali (non consigliato)

maschera_mem:
associare impostando maschere di memoria sulle attività come specificato dove è
, ,... . le maschere di memoria sono sempre interpretato come
valori esadecimali. Nota che le maschere devono essere precedute da uno '0x' se lo fanno
non iniziano con [0-9] in modo che vengano visti come valori numerici da srun.

Aiuto mostra questo messaggio di aiuto

--mincpus=<n>
Specificare un numero minimo di CPU/processori logici per nodo.

--msg-timeout=<secondo>
Modificare il timeout del messaggio di avvio del lavoro. Il valore predefinito è Timeout messaggio nel
File di configurazione di Slurm slurm.conf. Le modifiche a questo in genere non lo sono
consigliato, ma potrebbe essere utile per diagnosticare problemi.

--mpi=<tipo_mpi>
Identificare il tipo di MPI da utilizzare. Può comportare procedure di avvio uniche.

stratagemma Elenca i tipi di mpi disponibili tra cui scegliere.

lam Avvia un processo 'lamd' per nodo e stabilisce l'ambiente necessario
variabili per LAM/MPI.

mpich1_shmem
Avvia un processo per nodo e stabilisce l'ambiente necessario
variabili per il modello di memoria condivisa mpich1. Funziona anche per mvapich built
per la memoria condivisa

mpichgm
Da utilizzare con Myrinet.

mvapich
Da utilizzare con Infiniband.

openmpi
Da utilizzare con OpenMPI.

pmi2 Per abilitare il supporto PMI2. Il supporto PMI2 in Slurm funziona solo se MPI
l'implementazione lo supporta, in altre parole se MPI ha l'interfaccia PMI2
implementato. Il --mpi=pmi2 caricherà la libreria lib/slurm/mpi_pmi2.so
che fornisce la funzionalità lato server ma il lato client deve
implementare PMI2_Init() e le altre chiamate di interfaccia.

nessuna Nessuna elaborazione MPI speciale. Questa è l'impostazione predefinita e funziona con molti altri
versioni di MPI.

--multi-programma
Esegui un lavoro con programmi diversi e argomenti diversi per ogni attività. In questo
caso, il programma eseguibile specificato è in realtà un file di configurazione che specifica
l'eseguibile e gli argomenti per ogni attività. Vedere MULTIPLA PROGRAMMA CONFIGURAZIONE
di seguito per i dettagli sul contenuto del file di configurazione.

-N, --nodi=<minnodi[-maxnodi]>
Richiedi che un minimo di minnodi i nodi da assegnare a questo lavoro. Un nodo massimo
il conteggio può anche essere specificato con maxnodi. Se viene specificato un solo numero, questo
viene utilizzato sia come numero di nodi minimo che massimo. I limiti del nodo della partizione
sostituiscono quelli del lavoro. Se i limiti del nodo di un lavoro sono al di fuori dell'intervallo
consentito per la sua partizione associata, il lavoro verrà lasciato in uno stato PENDING.
Ciò consente la possibile esecuzione in un secondo momento, quando il limite della partizione è
cambiato. Se il limite di un nodo di lavoro supera il numero di nodi configurati nel
partizione, il lavoro verrà rifiutato. Nota che la variabile d'ambiente
SLURM_JOB_NUM_NODES (E SLURM_NNODES per compatibilità con le versioni precedenti) sarà impostato su
il conteggio dei nodi effettivamente allocati al lavoro. Vedi il AMBIENTE VARIABILI
sezione per maggiori informazioni. Se -N non è specificato, il comportamento predefinito è di
allocare abbastanza nodi per soddisfare i requisiti del -n e -c opzioni. Il
lavoro verrà assegnato il maggior numero di nodi possibile all'interno dell'intervallo specificato e
senza ritardare l'inizio del lavoro. La specifica del conteggio dei nodi può
include un valore numerico seguito da un suffisso di "k" (moltiplica il valore numerico per
1,024) o "m" (moltiplica il valore numerico per 1,048,576).

-n, --tasks=<numero>
Specificare il numero di attività da eseguire. Richiedilo svenuto allocare risorse per compiti
compiti. L'impostazione predefinita è un'attività per nodo, ma tieni presente che --cpus-per-attività opzione
cambierà questa impostazione predefinita.

--Rete=<Digitare>
Specificare le informazioni relative allo switch o alla rete. L'interpretazione di
Digitare è dipendente dal sistema. Questa opzione è supportata quando si esegue Slurm su un Cray
nativamente. Viene utilizzato per richiedere tramite contatori di prestazioni di rete. Un solo valore
per richiesta è valido. Tutte le opzioni fanno distinzione tra maiuscole e minuscole. In questa configurazione
i valori supportati includono:

sistema
Utilizzare i contatori delle prestazioni di rete a livello di sistema. Solo i nodi richiesti lo faranno
essere contrassegnato come in uso per l'assegnazione del lavoro. Se il lavoro non riempie il
intero sistema il resto dei nodi non può essere utilizzato da altri lavori
usando NPC, se inattivo il loro stato apparirà come PerfCnts. Questi nodi sono
ancora disponibile per altri lavori che non utilizzano NPC.

lama Utilizzare i contatori delle prestazioni della rete blade. Saranno solo i nodi richiesti
contrassegnato in uso per l'assegnazione del lavoro. Se il lavoro non riempie l'intero
lama(e) assegnata(e) al lavoro quella(e) lama(e) non può(e) essere usata(e) da altri
lavori che utilizzano NPC, se inattivo il loro stato apparirà come PerfCnts. Questi nodi sono
ancora disponibile per altri lavori che non utilizzano NPC.

In tutti i casi la richiesta di assegnazione del lavoro o del passaggio devono obbligatoriamente: specificare , il
--opzione esclusiva. In caso contrario la richiesta sarà respinta.

Inoltre con nessuna di queste opzioni i passaggi non sono consentiti per condividere i blade, quindi le risorse
rimarrebbe inattivo all'interno di un'allocazione se il passo in esecuzione su una lama non prende
su tutti i nodi sulla lama.

Rete l'opzione è supportata anche su sistemi con Parallel Environment di IBM
(PE). Vedere la documentazione sulla parola chiave del comando di lavoro LoadLeveler di IBM sulla parola chiave
"rete" per ulteriori informazioni. È possibile specificare più valori in una virgola
elenco separato. Tutte le opzioni fanno distinzione tra maiuscole e minuscole. I valori supportati includono:

BULK_XFER[=risorse>]
Abilita il trasferimento di massa di dati utilizzando l'accesso remoto alla memoria diretta (RDMA).
Facoltativo risorse specifica è un valore numerico che può avere
un suffisso di "k", "K", "m", "M", "g" o "G" per kilobyte, megabyte o
gigabyte. Notare la risorse specifica non è supportata da
infrastruttura IBM sottostante a partire da Parallel Environment versione 2.2
e nessun valore deve essere specificato in questo momento. I dispositivi allocati
a un lavoro devono essere tutti dello stesso tipo. Il valore predefinito dipende da
dipende da quale hardware è disponibile e in ordine di preferenze è
IPONLY (che non è considerato in modalità Spazio utente), HFI, IB, HPCE e
KMUX.

CAU=<contare> Numero di Unità Collettive di Accelerazione (CAU) richieste. Si applica solo
ai processori IBM Power7-IH. Il valore predefinito è zero. CAU . indipendente
verranno allocate per ogni interfaccia di programmazione (MPI, LAPI, ecc.)

DEVNOME=<Nome>
Specificare il nome del dispositivo da utilizzare per le comunicazioni (es. "eth0" o
"mlx4_0").

TIPO DI SVILUPPO=<Digitare>
Specificare il tipo di dispositivo da utilizzare per le comunicazioni. Il supportato
valori di Digitare sono: "IB" (InfiniBand), "HFI" (P7 Host Fabric
interfaccia), "IPONLY" (interfacce solo IP), "HPCE" (HPC Ethernet) e
"KMUX" (emulazione del kernel di HPCE). I dispositivi assegnati a un lavoro devono
essere tutti dello stesso tipo. Il valore predefinito dipende da dipende da
quale hardware è disponibile e in ordine di preferenze è IPONLY (che
non è considerato in modalità Spazio utente), HFI, IB, HPCE e KMUX.

IMMERSO =<contare>
Numero di slot di invio immediato per finestra richiesti. Si applica solo a
Processori IBM Power7-IH. Il valore predefinito è zero.

ISTANZE =<contare>
Specificare il numero di connessioni di rete per ogni attività su ciascuna rete
connessione. Il conteggio delle istanze predefinito è 1.

IPV4 Utilizza le comunicazioni IP (Internet Protocol) versione 4 (impostazione predefinita).

IPV6 Utilizzare le comunicazioni IP (Internet Protocol) versione 6.

LAPI Utilizzare l'interfaccia di programmazione LAPI.

MPI Utilizzare l'interfaccia di programmazione MPI. MPI è l'interfaccia predefinita.

PAMI Utilizzare l'interfaccia di programmazione PAMI.

SHMEM Utilizzare l'interfaccia di programmazione OpenSHMEM.

SN_TUTTI Utilizza tutte le reti switch disponibili (impostazione predefinita).

SN_SINGOLO Utilizzare una rete switch disponibile.

UPC Utilizzare l'interfaccia di programmazione UPC.

US Utilizzare le comunicazioni dello spazio utente.

Alcuni esempi di specifiche di rete:

Istanze=2,US,MPI,SN_ALL
Crea due connessioni nello spazio utente per le comunicazioni MPI su ogni
cambia rete per ogni attività.

US,MPI,Istanze=3,Tipo Dev=IB
Crea tre connessioni nello spazio utente per le comunicazioni MPI su ogni
Rete InfiniBand per ogni attività.

IPV4,LAPI,SN_singolo
Crea una connessione IP versione 4 per le comunicazioni LAPI su uno switch
rete per ogni compito.

Istanze=2,US,LAPI,MPI
Crea due connessioni di spazio utente ciascuna per comunicazioni LAPI e MPI
su ogni rete di switch per ogni attività. Nota che SN_ALL è l'impostazione predefinita
opzione in modo che venga utilizzata ogni rete di switch. Nota anche che Istanze=2
specifica che vengono stabilite due connessioni per ogni protocollo (LAPI
e MPI) e ogni compito. Se ci sono due reti e quattro attività attive
il nodo quindi vengono stabilite un totale di 32 connessioni (2 istanze x
2 protocolli x 2 reti x 4 task).

--simpatico[=trendelenburg]
Esegui il lavoro con una priorità di pianificazione modificata all'interno di Slurm. Senza regolazione
valore la priorità di programmazione è diminuita di 100. Il campo di regolazione è da
Da -10000 (priorità massima) a 10000 (priorità minima). Solo gli utenti privilegiati possono
specificare una rettifica negativa. NOTA: questa opzione è attualmente ignorata se
Tipo di pianificazione=programmato/wiki or Tipo di pianificazione=programmato/wiki2.

--tasks-per-core=<compiti>
Richiedi il massimo compiti essere invocato su ogni core. Questa opzione si applica al lavoro
allocazione, ma non per step allocazioni. Pensato per essere utilizzato con il --tasks
opzione. Relativo a --tasks-per-node tranne che a livello centrale invece del nodo
livello. Le maschere verranno generate automaticamente per associare le attività a un nucleo specifico
salvo che --cpu_bind=nessuno è specificato. NOTA: questa opzione non è supportata a meno che
SelectTypeParameters=CR_Core or SelectTypeParameters=CR_Core_Memory è configurato.

--tasks-per-node=<compiti>
Richiedilo compiti essere invocato su ogni nodo. Se utilizzato con il --tasks opzione, il
--tasks l'opzione avrà la precedenza e il --tasks-per-node sarà trattato come un
massimo conteggio delle attività per nodo. Pensato per essere utilizzato con il --nodi opzione. Questo
è relazionato a --cpus-per-attività=ncpus, ma non richiede la conoscenza dell'effettivo
numero di CPU su ogni nodo. In alcuni casi, è più conveniente essere in grado di
richiedere che non venga richiamato più di un numero specifico di attività su ciascun nodo.
Esempi di ciò includono l'invio di un'app MPI/OpenMP ibrida in cui solo un MPI
"task/rank" dovrebbe essere assegnato a ciascun nodo pur consentendo alla parte OpenMP di
utilizzare tutto il parallelismo presente nel nodo, o sottomettendo un singolo
lavoro di configurazione/pulizia/monitoraggio a ciascun nodo di un'allocazione preesistente in un unico passaggio
in uno script di lavoro più ampio.

--tasks-per-socket=<compiti>
Richiedi il massimo compiti essere invocato su ogni socket. Questa opzione si applica al
allocazione del lavoro, ma non per ripartire le allocazioni. Pensato per essere utilizzato con il --tasks
opzione. Relativo a --tasks-per-node tranne che a livello di presa invece che
livello del nodo. Le maschere verranno generate automaticamente per associare le attività a specifiche
prese a meno che --cpu_bind=nessuno è specificato. NOTA: questa opzione non è supportata
salvo che SelectTypeParameters=CR_Socket or SelectTypeParameters=CR_Socket_Memory is
configurato.

-O, --impegno eccessivo
Impegnare troppo le risorse. Quando applicato all'allocazione del lavoro, viene allocata solo una CPU a
il lavoro per nodo e le opzioni utilizzate per specificare il numero di attività per nodo, socket,
core, ecc. vengono ignorati. Quando applicato alle allocazioni delle fasi di lavoro (il svenuto command
quando eseguito all'interno di un'allocazione di lavoro esistente), questa opzione può essere utilizzata per avviare
più di un task per CPU. Normalmente, svenuto non allocherà più di un processo
per CPU. Specificando --impegno eccessivo ne stai esplicitamente consentendo più di uno
processo per CPU. Tuttavia non più di MAX_TASKS_PER_NODE i compiti sono autorizzati a
eseguire per nodo. NOTA: MAX_TASKS_PER_NODE è definito nel file slurm.h ed è
non è una variabile, è impostata al momento della creazione di Slurm.

-o, --produzione=<modo>
Specificare la modalità per il reindirizzamento stdout. Per impostazione predefinita, in modalità interattiva, svenuto
raccoglie lo stdout da tutte le attività e invia questo output tramite TCP/IP all'allegato
terminale. Con --produzione stdout può essere reindirizzato a un file, a un file per attività,
o su /dev/null. Vedi sezione IO Reindirizzamento di seguito per le varie forme di modo.
Se il file specificato esiste già, verrà sovrascritto.

If --errore non è specificato anche sulla riga di comando, sia stdout che stderr lo faranno
diretto al file specificato da --produzione.

--modalità aperta=<accoda|troncato>
Aprire i file di output e di errore utilizzando la modalità di accodamento o troncamento come specificato. Il
il valore predefinito è specificato dal parametro di configurazione del sistema JobFileAppend.

-p, --partizione=<nomi_partizione>
Richiedere una partizione specifica per l'allocazione delle risorse. Se non specificato, il
il comportamento predefinito è consentire al controller slurm di selezionare la partizione predefinita
come indicato dall'amministratore di sistema. Se il lavoro può utilizzarne più di uno
partizione, specificare i loro nomi in un elenco separato da virgole e quello che offre
verrà utilizzata la prima iniziazione senza tenere conto del nome della partizione
ordinamento (sebbene le partizioni con priorità più alta verranno considerate per prime). Quando il
viene avviato il lavoro, il nome della partizione utilizzata verrà posizionato per primo nel lavoro
stringa di partizione del record.

--potenza=<bandiere>
Elenco separato da virgole delle opzioni del plug-in di gestione dell'alimentazione. Bandiere attualmente disponibili
includono: livello (tutti i nodi assegnati al lavoro dovrebbero avere limiti di potenza identici,
può essere disabilitato dall'opzione di configurazione Slurm PowerParameters=job_no_level).

--priorità=
Richiedi una priorità di lavoro specifica. Può essere soggetto a specifiche di configurazione
vincoli. Solo gli operatori e gli amministratori di Slurm possono impostare la priorità di a
lavoro.

--profilo=
consente la raccolta di dati dettagliati dal plug-in acct_gather_profile. Dati dettagliati
sono in genere serie temporali archiviate in un file HDF5 per il lavoro.

Tutto Tutti i tipi di dati vengono raccolti. (Non può essere combinato con altri valori.)

Nona Non vengono raccolti tipi di dati. Questa è l'impostazione predefinita.
(Non può essere combinato con altri valori.)

Energia Vengono raccolti i dati energetici.

Task Vengono raccolti i dati dell'attività (I/O, memoria, ...).

filesystem
Vengono raccolti i dati del file system.

Network NetPoulSafe Vengono raccolti i dati di rete (InfiniBand).

--prologo=<eseguibile>
svenuto correrà eseguibile appena prima di avviare la fase di lavoro. La riga di comando
argomenti per eseguibile sarà il comando e gli argomenti del passaggio del lavoro. Se
eseguibile è "none", quindi non verrà eseguito alcun prologo srun. Questo parametro ha la precedenza su
Parametro SrunProlog in slurm.conf. Questo parametro è completamente indipendente da
il parametro Prolog in slurm.conf.

--propagare[=limiti]
Consente agli utenti di specificare quale dei limiti di risorse modificabili (soft) propagare
ai nodi di calcolo e applicare ai loro lavori. Se limiti non è specificato, allora
tutti i limiti delle risorse verranno propagati. Sono supportati i seguenti nomi limite
di Slurm (anche se alcune opzioni potrebbero non essere supportate su alcuni sistemi):

TUTTO Tutti i limiti elencati di seguito

AS Lo spazio di indirizzi massimo per un processo

NUCLEO La dimensione massima del file core

CPU La quantità massima di tempo CPU

DATA La dimensione massima del segmento di dati di un processo

TAGLIA La dimensione massima dei file creati. Nota che se l'utente imposta FSIZE su
inferiore alla dimensione attuale di slurmd.log, l'avvio dei lavori fallirà con
un errore "Limite dimensione file superato".

MEMLOCK La dimensione massima che può essere bloccata in memoria

NESSUN FILE Il numero massimo di file aperti

NPROC Il numero massimo di processi disponibili

RSS La dimensione massima del set di residenti

PILA La dimensione massima dello stack

--pty Esegui l'attività zero in modalità pseudo terminale. Imposta implicitamente --senza buffer.
Imposta implicitamente --errore e --produzione a /dev/null per tutte le attività tranne l'attività zero,
che potrebbe causare l'uscita immediata di tali attività (ad es. le shell in genere terminano
immediatamente in quella situazione). Attualmente non supportato su piattaforme AIX.

-Q, --silenzioso
Elimina i messaggi informativi da srun. Gli errori verranno comunque visualizzati.

-q, --esci all'interruzione
Esci immediatamente su SIGINT singolo (Ctrl-C). L'uso di questa opzione disabilita lo stato
funzione normalmente disponibile quando svenuto riceve un singolo Ctrl-C e provoca svenuto a
terminare invece immediatamente il lavoro in esecuzione.

--qos=<QoS>
Richiedi un servizio di qualità per il lavoro. I valori QOS possono essere definiti per ciascuno
associazione utente/cluster/account nel database Slurm. Gli utenti saranno limitati a
il set di qos definito dalla loro associazione quando il parametro di configurazione Slurm,
AccountingStorageEnforce, include "qos" nella sua definizione.

-r, --parente=<n>
Esegui un passaggio di lavoro relativo al nodo n dell'attuale stanziamento. Questa opzione potrebbe essere
utilizzato per distribuire diverse fasi del lavoro tra i nodi del lavoro corrente. Se -r is
utilizzato, il passaggio del lavoro corrente inizierà al nodo n della nodelist allocata, dove
il primo nodo è considerato nodo 0. Il -r l'opzione non è consentita con -w or -x
opzione e si tradurrà in un errore fatale quando non è in esecuzione all'interno di un'allocazione precedente
(cioè quando SLURM_JOB_ID non è impostato). L'impostazione predefinita per n è 0. Se il valore di
--nodi supera il numero di nodi identificati con il --parente opzione, a
messaggio di avviso verrà stampato e il --parente l'opzione avrà la precedenza.

--riavviare
Forza il riavvio dei nodi allocati prima di avviare il lavoro. Questo è solo
supportato con alcune configurazioni di sistema e altrimenti verrà ignorato in silenzio.

--resv-porte
Prenota le porte di comunicazione per questo lavoro. Gli utenti possono specificare il numero di porta che
desidera prenotare. Il parametro MpiParams=ports=12000-12999 deve essere specificato in
slurm.conf. Se non specificato il numero di porte di riserva predefinito pari al
numero di compiti. Se il numero di porte riservate è zero, nessuna porta è riservata.
Utilizzato per OpenMPI.

--prenotazione=<Nome>
Allocare risorse per il lavoro dalla prenotazione denominata.

--restart-dir=<elenco>
Specifica la directory da cui deve essere letto il lavoro o il punto di controllo della fase di lavoro
(usato solo dai plugin checkpoint/blcrm e checkpoint/xlch).

-s, --Condividere
L'allocazione del lavoro può condividere le risorse con altri lavori in esecuzione. Le risorse per
essere condivisi possono essere nodi, socket, core o hyperthread a seconda di
configurazione. Il comportamento condiviso predefinito dipende dalla configurazione del sistema e dal
partizione diviso l'opzione ha la precedenza sull'opzione del lavoro. Questa opzione potrebbe
comportare la concessione dell'assegnazione prima che se l'opzione --share non lo fosse
impostare e consentire un maggiore utilizzo del sistema, ma è probabile che le prestazioni dell'applicazione
soffrono a causa della competizione per le risorse. Vedi anche l'opzione --exclusive.

-S, --spec.core=<num>
Conteggio dei core specializzati per nodo riservati dal lavoro per le operazioni di sistema e
non utilizzato dall'applicazione. L'applicazione non utilizzerà questi core, ma sarà
addebitato per la loro assegnazione. Il valore predefinito dipende dal nodo
valore CoreSpecCount configurato. Se viene designato un valore pari a zero e Slurm
l'opzione di configurazione AllowSpecResourcesUsage è abilitata, il lavoro sarà autorizzato a
sovrascrivere CoreSpecCount e utilizzare le risorse specializzate sui nodi a cui è allocato.
Questa opzione non può essere utilizzata con il --specifiche del thread opzione.

--sic Identificare un lavoro come uno da cui possono dipendere i lavori inviati ad altri cluster.

--segnale=<segno_num>[@sig_tempo>]
Quando un lavoro è dentro sig_tempo secondi della sua ora di fine, inviagli il segnale segno_num.
A causa della risoluzione della gestione degli eventi da parte di Slurm, il segnale può essere inviato fino a 60
secondi prima di quanto specificato. segno_num può essere un numero di segnale o un nome
(es. "10" o "USR1"). sig_tempo deve avere un valore intero compreso tra 0 e 65535.
Per impostazione predefinita, non viene inviato alcun segnale prima dell'ora di fine del lavoro. Se un segno_num è specificato
senza sig_tempo, il tempo predefinito sarà di 60 secondi.

--slurmd-debug=< livello>
Specifica un livello di debug per farfugliare(8). Il livello può essere specificato sia un numero intero
valore compreso tra 0 [silenzioso, vengono visualizzati solo gli errori] e 4 [operazione dettagliata] o il
SlurmdDebug tag.

silenzioso Registra niente

fatale Registra solo errori fatali

errore Registra solo errori

Maggiori informazioni. Registra errori e messaggi informativi generali

verboso Registra errori e messaggi informativi dettagliati

Le informazioni di debug di slurmd vengono copiate nello stderr di
il lavoro. Per impostazione predefinita vengono visualizzati solo gli errori.

--prese-per-nodo=<Prese>
Limita la selezione del nodo ai nodi con almeno il numero di socket specificato.
Vedi ulteriori informazioni sotto -B opzione sopra quando il plugin task/affinity è
abilitato.

--interruttori=<contare>[@tempo massimo>]
Quando viene utilizzata una topologia ad albero, questa definisce il numero massimo di switch desiderati
per l'assegnazione del lavoro e facoltativamente il tempo massimo di attesa per quel numero di
interruttori. Se Slurm trova un'allocazione contenente più switch del conteggio
specificato, il lavoro rimane in sospeso finché non trova un'allocazione con desiderato
numero di cambi o scade il limite di tempo. Non c'è un limite di conteggio degli switch, lì
non è un ritardo nell'iniziare il lavoro. I formati di tempo accettabili includono "minuti",
"minuti:secondi", "ore:minuti:secondi", "giorni-ore", "giorni-ore:minuti" e
"giorni-ore:minuti:secondi". Il ritardo massimo del lavoro può essere limitato dal
amministratore di sistema utilizzando il Parametri dello scheduler parametro di configurazione con il
max_switch_wait opzione parametro. Il tempo massimo predefinito è max_switch_wait
Parametri di pianificazione.

-T, --thread=<nthread>
Consente di limitare il numero di thread simultanei utilizzati per inviare la richiesta di lavoro da
il processo srun ai processi slurmd sui nodi allocati. L'impostazione predefinita è utilizzare
un thread per nodo allocato fino a un massimo di 60 thread simultanei. Specificando
questa opzione limita il numero di thread simultanei a nthread (minore o uguale
a 60). Questo dovrebbe essere usato solo per impostare un numero di thread basso per il test su very
computer di piccola memoria.

-t, --tempo=<tempo>
Imposta un limite al tempo di esecuzione totale dell'allocazione del lavoro. Se il tempo richiesto
limite supera il limite di tempo della partizione, il lavoro verrà lasciato in uno stato PENDING
(possibilmente a tempo indeterminato). Il limite di tempo predefinito è il tempo predefinito della partizione
limite. Quando viene raggiunto il limite di tempo, ogni attività in ogni fase di lavoro viene inviata SIGTERM
seguito da SIGKILL. L'intervallo tra i segnali è specificato dallo Slurm
parametro di configurazione Uccidi Aspetta. Limite di tempo eccessivo parametro di configurazione può
consentire al lavoro di essere eseguito più a lungo del previsto. La risoluzione temporale è di un minuto e
i secondi vengono arrotondati al minuto successivo.

Un limite di tempo pari a zero richiede che non venga imposto alcun limite di tempo. Tempo accettabile
i formati includono "minuti", "minuti:secondi", "ore:minuti:secondi",
"giorni-ore", "giorni-ore:minuti" e "giorni-ore:minuti:secondi".

--task-epilogo=<eseguibile>
sbuffò il demone verrà eseguito eseguibile subito dopo la fine di ogni attività. Questo
verrà eseguito prima che venga eseguito qualsiasi parametro TaskEpilog in slurm.conf. Questo è
pensato per essere un programma di breve durata. Se non riesce a terminare entro pochi
secondi, verrà ucciso insieme a tutti i processi discendenti.

--task-prologo=<eseguibile>
sbuffò il demone verrà eseguito eseguibile appena prima di avviare ogni attività. Questo
verrà eseguito dopo l'esecuzione di qualsiasi parametro TaskProlog in slurm.conf. inoltre
le normali variabili di ambiente, questo ha SLURM_TASK_PID disponibile per identificare il
ID processo dell'attività avviata. Uscita standard da questo programma del
il modulo "export NAME=value" verrà utilizzato per impostare le variabili di ambiente per l'attività
essere generato.

--solo-test
Restituisce una stima di quando un lavoro sarebbe pianificato per l'esecuzione dato il lavoro corrente
coda e tutto il resto svenuto argomenti che specificano il lavoro. questo limite srun's
comportamento per restituire solo informazioni; nessun lavoro viene effettivamente inviato. ECCEZIONE: On
I sistemi Bluegene/Q sono accesi quando sono in esecuzione all'interno di un'allocazione di lavoro esistente, questo disabilita
l'uso di "runjob" per avviare le attività. Il programma verrà eseguito direttamente dal
demone slurmd.

--specifiche del thread=<num>
Conteggio di thread specializzati per nodo riservati dal lavoro per le operazioni di sistema e
non utilizzato dall'applicazione. L'applicazione non utilizzerà questi thread, ma lo farà
essere addebitato per la loro assegnazione. Questa opzione non può essere utilizzata con il --spec.core
opzione.

--thread-per-core=<fili>
Limita la selezione del nodo ai nodi con almeno il numero specificato di thread per
nucleo. NOTA: "Fili" si riferisce al numero di unità di elaborazione su ciascun core piuttosto
rispetto al numero di attività applicative da avviare per core. Vedi altro
informazioni sotto -B opzione sopra quando il plugin task/affinity è abilitato.

--tempo-min=<tempo>
Imposta un limite di tempo minimo per l'assegnazione del lavoro. Se specificato, il lavoro potrebbe avere
suo --tempo limite abbassato ad un valore non inferiore a --tempo-min se farlo lo consente
il lavoro per iniziare l'esecuzione prima di quanto altrimenti possibile. Il limite di tempo del lavoro
non verrà modificato dopo l'assegnazione delle risorse al lavoro. Questo viene eseguito da a
algoritmo di pianificazione del riempimento per allocare risorse altrimenti riservate a un livello superiore
lavori prioritari. I formati di tempo accettabili includono "minuti", "minuti:secondi",
"ore:minuti:secondi", "giorni-ore", "giorni-ore:minuti" e
"giorni-ore:minuti:secondi".

--tmp=<MB>
Specificare una quantità minima di spazio su disco temporaneo.

-u, --senza buffer
Per impostazione predefinita, la connessione tra slurmstepd e l'applicazione avviata dall'utente è
sopra un tubo. L'output stdio scritto dall'applicazione è bufferizzato da glibc
fino a quando non viene scaricato o l'uscita non viene impostata come non bufferizzata. Vedere setbuff(3). Se questo
è specificata l'opzione le attività vengono eseguite con uno pseudo terminale in modo che
l'output dell'applicazione non è bufferizzato.

--uso
Visualizza un breve messaggio di aiuto ed esci.

--uido=<Utente>
Tentativo di inviare e/o eseguire un lavoro come Utente invece dell'ID utente invocante. Il
il richiamo delle credenziali dell'utente verrà utilizzato per verificare i permessi di accesso per il target
partizione. L'utente root può usare questa opzione per eseguire lavori come un normale utente in un RootOnly
partizione per esempio. Se eseguito come root, svenuto rilascerà i suoi permessi all'uid
specificato dopo che l'allocazione del nodo ha esito positivo. Utente potrebbe essere il nome utente o
ID utente numerico.

-V, --versione
Visualizza le informazioni sulla versione ed esci.

-v, --verboso
Aumenta la verbosità dei messaggi informativi di srun. multiplo -vla volontà
aumentare ulteriormente la verbosità di srun. Per impostazione predefinita verranno visualizzati solo gli errori.

-W, --aspettare=<secondo>
Specifica quanto tempo attendere dopo il termine della prima attività prima di terminare tutto
compiti rimanenti. Un valore 0 indica un'attesa illimitata (verrà emesso un avviso
dopo 60 secondi). Il valore predefinito è impostato dal parametro WaitTime nello slurm
file di configurazione (vedi slurm.conf(5)). Questa opzione può essere utile per assicurare che a
il lavoro viene terminato in modo tempestivo nel caso in cui uno o più compiti cessino
prematuramente. Notare la -K, --kill-on-bad-exit l'opzione ha la precedenza su -W,
--aspettare per terminare immediatamente il lavoro se un'attività termina con un codice di uscita diverso da zero.

-w, --elenco nodi=<ospite1, ospite2,... or Nome del file>
Richiedi un elenco specifico di host. Il lavoro conterrà contro tutti i di questi host e
eventualmente host aggiuntivi necessari per soddisfare i requisiti delle risorse. L'elenco potrebbe
essere specificato come un elenco di host separati da virgole, un intervallo di host (host[1-5,7,...]
per esempio) o un nome di file. Si presumerà che l'elenco degli host sia un nome di file se
contiene un carattere "/". Se si specifica un numero minimo di nodi o processori maggiore
di quanto possa essere soddisfatto dall'elenco di host fornito, risorse aggiuntive saranno
allocato su altri nodi secondo necessità. Piuttosto che ripetere un nome host multiplo
volte, un asterisco e un conteggio delle ripetizioni possono essere aggiunti a un nome host. Per
esempio "host1,host1" e "host1*2" sono equivalenti.

--cavolo=<cavolo>
Specificare wckey da utilizzare con il lavoro. Se TrackWCKey=no (predefinito) in slurm.conf
questo valore viene ignorato.

-X, --disabilita-stato
Disabilita la visualizzazione dello stato dell'attività quando srun riceve un singolo SIGINT (Ctrl-C).
Inoltra invece immediatamente SIGINT al lavoro in esecuzione. Senza questa opzione a
è necessario il secondo Ctrl-C in un secondo per terminare forzatamente il lavoro e svenuto andrete a
uscire immediatamente. Può anche essere impostato tramite la variabile d'ambiente
SLURM_DISABLE_STATUS.

-x, --escludere=<ospite1, ospite2,... or Nome del file>
Richiedere che un elenco specifico di host non sia incluso nelle risorse assegnate a
questo lavoro. Si presumeràche l'elenco degli host sia un nome di file se contiene a
"/"carattere.

-Z, --no-allocare
Esegui le attività specificate su un insieme di nodi senza creare un "lavoro" Slurm nel
Struttura della coda slurm, ignorando la normale fase di allocazione delle risorse. L'elenco di
i nodi devono essere specificati con il -w, --elenco nodi opzione. Questo è un privilegiato
opzione disponibile solo per gli utenti "SlurmUser" e "root".

Le seguenti opzioni supportano i sistemi Blue Gene, ma possono essere applicabili ad altri sistemi come
bene.

--blrts-immagine=<sentiero>
Percorso dell'immagine blrts per il blocco bluegene. Solo BGL. Predefinito da blugene.conf if
non impostato.

--cncarica-immagine=<sentiero>
Percorso per calcolare l'immagine del nodo per il blocco bluegene. Solo BGP. Predefinito da
blugene.conf se non impostato.

--tipo-conn=<Digitare>
Richiedi che il tipo di connessione del blocco sia di un certo tipo. Su Blue Gene il
accettabile di Digitare sono MESH, TORUS e NAV. Se NAV, o se non è impostato, Slurm lo farà
prova ad adattare a cosa è impostato DefaultConnType nel bluegene.conf se non lo è
l'impostazione predefinita è TORUS. Normalmente non dovresti impostare questa opzione. Se in esecuzione su
un sistema BGP e volendo funzionare in modalità HTC (solo per 1 midplane e inferiori). Voi
può utilizzare HTC_S per SMP, HTC_D per Dual, HTC_V per la modalità nodo virtuale e HTC_L per
Modalità Linux. Per sistemi che consentono un diverso tipo di connessione per dimensione si
può fornire un elenco separato da virgole di tipi di connessione può essere specificato, uno per
ogni dimensione (cioè M,T,T,T ti darà una connessione toroidale è tutte le dimensioni
aspetta il primo).

-g, --geometria=<XxYxZ> |AxXxYxZ>
Specificare i requisiti di geometria per il lavoro. Sui sistemi BlueGene/L e BlueGene/P
ci sono tre numeri che danno le dimensioni nelle direzioni X, Y e Z, mentre su
Sistemi BlueGene/Q ci sono quattro numeri che danno le dimensioni in A, X, Y e Z
direzioni e non può essere utilizzato per allocare sottoblocchi. Per esempio
"--geometry=1x2x3x4", specifica un blocco di nodi con 1 x 2 x 3 x 4 = 24 nodi
(in realtà piani intermedi su BlueGene).

--ioload-immagine=<sentiero>
Percorso all'immagine io per il blocco bluegene. Solo BGP. Predefinito da blugene.conf altrimenti
impostato.

--immagine-linux=<sentiero>
Percorso dell'immagine linux per il blocco bluegene. Solo BGL. Predefinito da blugene.conf if
non impostato.

--mloader-immagine=<sentiero>
Percorso dell'immagine mloader per il blocco bluegene. Predefinito da blugene.conf se non impostato.

-R, --no-ruotare
Disabilita la rotazione della geometria richiesta del lavoro per adattarsi a un'appropriata
bloccare. Per impostazione predefinita, la geometria specificata può ruotare in tre dimensioni.

--ramdisk-image=<sentiero>
Percorso all'immagine del ramdisk per il blocco bluegene. Solo BGL. Predefinito da blugene.conf if
non impostato.

svenuto invierà la richiesta di lavoro al controller del lavoro slurm, quindi avvierà tutti i processi
sui nodi remoti. Se la richiesta non può essere soddisfatta immediatamente, svenuto si bloccherà fino al
le risorse sono libere per eseguire il lavoro. Se la -I (--immediato) l'opzione è specificata svenuto andrete a
terminare se le risorse non sono immediatamente disponibili.

Quando si avviano processi remoti svenuto propagherà la directory di lavoro corrente, a meno che
--chdir=<sentiero> è specificato, nel qual caso sentiero diventerà la directory di lavoro per il
processi remoti.

-N, -c e -N le opzioni controllano come le CPU e i nodi verranno allocati al lavoro. quando
specificando solo il numero di processi con cui eseguire -n, un valore predefinito di una CPU per processo
è assegnato. Specificando il numero di CPU richieste per attività (-c), più di una CPU
possono essere assegnati per processo. Se il numero di nodi è specificato con -N, svenuto andrete a
tentare di allocare at meno il numero di nodi specificato.

Le combinazioni delle tre opzioni precedenti possono essere utilizzate per modificare il modo in cui i processi sono
distribuito su nodi e CPU. Ad esempio, specificando sia il numero di
processi e numero di nodi su cui eseguire, il numero di processi per nodo è
implicito. Tuttavia, se il numero di CPU per processo è più importante del numero di
processi (-n) e il numero di CPU per processo (-c) dovrebbe essere specificato.

svenuto rifiuterà di allocare più di un processo per CPU a meno che --impegno eccessivo (-O) è
anche specificato.

svenuto tenterà di soddisfare le specifiche di cui sopra "al minimo". Cioè, se 16 nodi
sono richiesti per 32 processi, e alcuni nodi non hanno 2 CPU, l'allocazione dei nodi
sarà aumentato per soddisfare la domanda di CPU. In altre parole, a ordine di 16
i nodi vengono richiesti. Tuttavia, se sono richiesti 16 nodi per 15 processi, svenuto andrete a
considera questo un errore, poiché 15 processi non possono essere eseguiti su 16 nodi.

IO Reindirizzamento

Per impostazione predefinita, stdout e stderr verranno reindirizzati da tutte le attività a stdout e stderr
of svenutoe stdin verrà reindirizzato dallo standard input di svenuto a tutte le attività remote.
Se stdin deve essere letto solo da un sottoinsieme delle attività generate, specificando un file da leggere
da anziché inoltrare lo stdin dal svenuto il comando può essere preferibile in quanto evita
spostare e archiviare dati che non verranno mai letti.

Per OS X, la funzione poll() non supporta stdin, quindi l'input da un terminale non lo è
possibile.

Per BGQ srun supporta solo l'attività stdin su 1 in esecuzione sul sistema. Di default è taskid
0 ma può essere modificato con -i come descritto di seguito, o
--launcher-opts="--stdinrank= ".

Questo comportamento può essere modificato con il --produzione, --errore e --ingresso (-o, -e, -i) opzioni.
Le specifiche di formato valide per queste opzioni sono

contro tutti i stdout stderr viene reindirizzato da tutte le attività a srun. stdin viene trasmesso a tutti
compiti a distanza. (Questo è il comportamento predefinito)

nessuna stdout e stderr non vengono ricevuti da nessuna attività. stdin non viene inviato ad alcuna attività
(stdin è chiuso).

ID task stdout e/o stderr vengono reindirizzati solo dal task con id relativo uguale a
ID task, dove 0 <= ID task <= compitiDurante la serata, compiti è il numero totale di attività
nella fase di lavoro corrente. stdin viene reindirizzato dallo stdin of svenuto a questo
stesso compito. Questo file verrà scritto sul nodo che esegue l'attività.

Nome del file svenuto reindirizzerà stdout e/o stderr al file denominato da tutte le attività. standard
verrà reindirizzato dal file denominato e trasmesso a tutte le attività nel lavoro.
Nome del file fa riferimento a un percorso sull'host che viene eseguito svenuto. Dipende da
layout del file system del cluster, questo potrebbe far apparire l'output in
posti diversi a seconda che il lavoro venga eseguito in modalità batch.

formato stringa
svenuto consente di utilizzare una stringa di formato per generare il file IO denominato
descritto sopra. Il seguente elenco di identificatori di formato può essere utilizzato nel
stringa di formato per generare un nome file che sarà univoco per un determinato jobid,
stepid, nodo o task. In ogni caso, viene aperto il numero appropriato di file
e associati ai relativi compiti. Nota che qualsiasi stringa di formato
contenente %t, %n e/o %N verrà scritto sul nodo che esegue l'attività
piuttosto che il nodo dove svenuto viene eseguito, questi identificatori di formato non lo sono
supportato su un sistema BGQ.

%A Numero di allocazione del lavoro principale dell'array di lavori.

%a Numero ID array lavoro (indice).

%J jobid.stepid del lavoro in esecuzione. (ad es. "128.0")

%j jobid del job in esecuzione.

%s stepid del lavoro in esecuzione.

%N nome host breve. Questo creerà un file IO separato per nodo.

%n Identificatore del nodo relativo al lavoro corrente (es "0"èil primo nodo di
il lavoro in esecuzione) Questo creerà un file IO separato per nodo.

%t identificatore dell'attività (grado) relativo al lavoro corrente. Questo creerà un
file IO separato per attività.

%u Nome utente.

È possibile utilizzare un numero posto tra il carattere percentuale e l'identificatore di formato
per azzerare il risultato nel nome del file IO. Questo numero viene ignorato se il formato
L'identificatore corrisponde a dati non numerici (ad esempio %N).

Alcuni esempi di come la stringa di formato può essere utilizzata per un passaggio di lavoro a 4 attività con a
Di seguito sono inclusi l'ID lavoro 128 e l'ID passaggio 0:

lavoro%J.out lavoro128.0.out

lavoro%4j.out lavoro0128.out

lavoro%j-%2t.out lavoro128-00.out, lavoro128-01.out, ...

INGRESSO AMBIENTE VARIABILI

Alcune opzioni srun possono essere impostate tramite variabili di ambiente. Queste variabili d'ambiente,
insieme alle opzioni corrispondenti, sono elencati di seguito. Nota: le opzioni della riga di comando lo faranno
sovrascrivere sempre queste impostazioni.

PMI_FANOUT Viene utilizzato esclusivamente con PMI (MPICH2 e MVAPICH2) e controlli
il fanout delle comunicazioni di dati. Il comando srun invia messaggi
ai programmi applicativi (tramite la libreria PMI) e quelle applicazioni
può essere chiamato a inoltrare tali dati fino a questo numero di
compiti aggiuntivi. Valori più alti scaricano il lavoro dal comando srun
alle applicazioni e probabilmente aumentare la vulnerabilità a
fallimenti. Il valore predefinito è 32.

PMI_FANOUT_OFF_HOST Viene utilizzato esclusivamente con PMI (MPICH2 e MVAPICH2) e controlli
il fanout delle comunicazioni di dati. Il comando srun invia messaggi
ai programmi applicativi (tramite la libreria PMI) e quelle applicazioni
può essere chiamato a inoltrare tali dati a compiti aggiuntivi. Di
predefinito, srun invia un messaggio per host e un'attività su quell'host
inoltra i dati ad altre attività su quell'host fino a PMI_FANOUT. Se
PMI_FANOUT_OFF_HOST è definito, l'attività dell'utente potrebbe essere richiesta per
inoltrare i dati ad attività su altri host. Collocamento
PMI_FANOUT_OFF_HOST può aumentare le prestazioni. Dal momento che più lavoro è
eseguita dalla libreria PMI caricata dall'applicazione utente,
anche i guasti possono essere più comuni e più difficili da diagnosticare.

PMI_ORA Viene utilizzato esclusivamente con PMI (MPICH2 e MVAPICH2) e controlli
quanto sono diffuse le comunicazioni dai task allo srun
fuori in tempo per evitare di sovraccaricare il comando srun con
opera. Il valore predefinito è 500 (microsecondi) per attività. Sopra
processori o sistemi relativamente lenti con processore molto grande
conteggi (e set di dati PMI di grandi dimensioni), potrebbero essere necessari valori più alti.

SLURM_CONF La posizione del file di configurazione di Slurm.

SLURM_ACCOUNT Uguale a -UN, --account

SLURM_ACCTG_FREQ Uguale a --acctg-freq

SLURM_BCAST Uguale a --bcast

SLURM_BLRTS_IMAGE Uguale a --blrts-immagine

SLURM_BURST_BUFFER Uguale a --bb

SLURM_CHECKPOINT Uguale a --punto di controllo

SLURM_CHECKPOINT_DIR Uguale a --checkpoint-dir

SLURM_CNLOAD_IMAGE Uguale a --cncarica-immagine

SLURM_CONN_TYPE Uguale a --tipo-conn

SLURM_CORE_SPEC Uguale a --spec.core

SLURM_CPU_BIND Uguale a --cpu_bind

SLURM_CPU_FREQ_REQ Uguale a --freq-cpu.

SLURM_CPUS_PER_TASK Uguale a -C, --cpus-per-attività

SLURM_DEBUG Uguale a -in, --verboso

SlurmD_DEBUG Uguale a -D, --slurmd-debug

SLURM_DEPENDENZA -P, --dipendenza=<ID lavoro>

SLURM_DISABLE_STATUS Uguale a -X, --disabilita-stato

SLURM_DIST_PLANESIZE Uguale a -m piano

DISTRIBUZIONE_SLURM Uguale a -M, --distribuzione

SLURM_EPILOG Uguale a --epilogo

SLURM_ESCLUSIVA Uguale a --esclusivo

SLURM_EXIT_ERRORE Specifica il codice di uscita generato quando si verifica un errore Slurm (es
opzioni non valide). Questo può essere usato da uno script per distinguere
codici di uscita dell'applicazione da varie condizioni di errore Slurm. Anche
vedere SLURM_EXIT_IMMEDIATO.

SLURM_EXIT_IMMEDIATO Specifica il codice di uscita generato quando il --immediato opzione è
utilizzati e le risorse non sono attualmente disponibili. Questo può essere usato da
uno script per distinguere i codici di uscita delle applicazioni da vari Slurm
condizioni di errore. Vedi anche SLURM_EXIT_ERRORE.

SLURM_GEOMETRIA Uguale a -G, --geometria

SLURM_SUGGERIMENTO Uguale a --suggerimento

SLURM_GRES Uguale a --gres. Vedi anche SLURM_STEP_GRES

SLURM_IMMEDIATO Uguale a -IO, --immediato

SLURM_IOLOAD_IMAGE Uguale a --ioload-immagine

SLURM_JOB_ID (E SLURM_JOBID per retrocompatibilità)
Uguale a --jobid

SLURM_JOB_NAME Uguale a -J, --nome del lavoro tranne che all'interno di un'allocazione esistente, in
nel qual caso viene ignorato per evitare di utilizzare il nome del lavoro batch come
nome di ogni fase di lavoro.

SLURM_JOB_NUM_NODES (E SLURM_NNODES per retrocompatibilità)
Numero totale di nodi nell'allocazione delle risorse del lavoro.

SLURM_KILL_BAD_EXIT Uguale a -K, --kill-on-bad-exit

SLURM_LABELIO Uguale a -l, --etichetta

SLURM_LINUX_IMAGE Uguale a --immagine-linux

SLURM_MEM_BIND Uguale a --mem_bind

SLURM_MEM_PER_CPU Uguale a --mem-per-cpu

SLURM_MEM_PER_NODE Uguale a --meme

SLURM_MLOADER_IMAGE Uguale a --mloader-immagine

SLURM_MPI_TYPE Uguale a --mpi

SLURM_RETE Uguale a --Rete

SLURM_NNODES Uguale a -N, --nodi

SLURM_NO_RUOTA Uguale a -R, --no-ruotare

SLURM_NTASKS (E SLURM_NPROCS per retrocompatibilità)
Uguale a -N, --tasks

SLURM_NTASKS_PER_CORE Uguale a --tasks-per-core

SLURM_NTASKS_PER_NODE Uguale a --tasks-per-node

SLURM_NTASKS_PER_SOCKET
Uguale a --tasks-per-socket

SLURM_OPEN_MODE Uguale a --modalità aperta

SLURM_OVERCOMMIT Uguale a -Oh, --impegno eccessivo

SLURM_PARTIZIONE Uguale a -P, --partizione

SLURM_PMI_KVS_NO_DUP_KEYS
Se impostato, le coppie di chiavi PMI non conterranno chiavi duplicate. MPI può
utilizzare questa variabile per informare la libreria PMI che non verrà utilizzata
chiavi duplicate in modo che PMI possa saltare il controllo delle chiavi duplicate. Questo
è il caso di MPICH2 e riduce il sovraccarico nei test per
duplicati per prestazioni migliori

SLURM_POWER Uguale a --potenza

SLURM_PROFILO Uguale a --profilo

SLURM_PROLOG Uguale a --prologo

SLURM_QOS Uguale a --qos

SLURM_RAMDISK_IMAGE Uguale a --ramdisk-image

SLURM_REMOTE_CWD Uguale a -D, --chdir=

SLURM_REQ_INTERRUTTORE Quando viene utilizzata una topologia ad albero, questa definisce il conteggio massimo di
interruttori desiderati per l'allocazione del lavoro e facoltativamente il massimo
tempo per aspettare quel numero di interruttori. Vedere --interruttori

SLURM_RESERVATION Uguale a --prenotazione

SLURM_RESTART_DIR Uguale a --restart-dir

SLURM_RESV_PORTS Uguale a --resv-porte

SLURM_SICP Uguale a --sic

SLURM_SIGNAL Uguale a --segnale

SLURM_STDERMODE Uguale a -e, --errore

SLURM_STDINMODE Uguale a -io, --ingresso

SLURM_SRUN_REDUCE_TASK_EXIT_MSG
se impostato e diverso da zero, successivi messaggi di uscita dall'attività con lo stesso
il codice di uscita verrà stampato una sola volta.

SLURM_STEP_GRES Uguale a --gres (si applica solo alle fasi di lavoro, non alle allocazioni di lavoro).
Vedi anche SLURM_GRES

SLURM_STEP_KILLED_MSG_NODE_ID=ID
Se impostato, solo il nodo specificato registrerà quando il lavoro o il passaggio sono
ucciso da un segnale.

SLURM_STDOUTMODE Uguale a -oh, --produzione

SLURM_TASK_EPILOG Uguale a --task-epilogo

SLURM_TASK_PROLOG Uguale a --task-prologo

SLURM_TEST_EXEC se definito, verifica l'esistenza del programma eseguibile sul
computer locale prima di tentare di avviarlo sui nodi di calcolo.

SLURM_THREAD_SPEC Uguale a --specifiche del thread

SLURM_THREADS Uguale a -T, --thread

SLURM_TIMELIMIT Uguale a -T, --tempo

SLURM_UNBUFFEREDIO Uguale a -tu, --senza buffer

SLURM_WAIT Uguale a -W, --aspettare

SLURM_WAIT4SWITCH Tempo massimo di attesa per gli switch richiesti. Vedere --interruttori

SLURM_WCKEY Uguale a -W, --cavolo

SLURM_DIR._LAVORO -D, --chdir

USCITA AMBIENTE VARIABILI

srun imposterà alcune variabili di ambiente nell'ambiente delle attività in esecuzione sul
nodi di calcolo remoti. Queste variabili di ambiente sono:

SLURM_CHECKPOINT_IMAGE_DIR
Directory in cui devono essere scritte le immagini del checkpoint se
specificato nella riga di esecuzione.

SLURM_CLUSTER_NAME Nome del cluster su cui è in esecuzione il lavoro.

SLURM_CPU_BIND_VERBOSE
--cpu_bind verbosità (silenzioso, dettagliato).

SLURM_CPU_BIND_TYPE --cpu_bind tipo (none,rank,map_cpu:,mask_cpu:).

SLURM_CPU_BIND_LIST --cpu_bind map o mask list (elenco di ID CPU Slurm o maschere per questo
nodo, CPU_ID = Board_ID x threads_per_board + Socket_ID x
thread_per_socket + Core_ID x thread_per_core + Thread_ID).

SLURM_CPU_FREQ_REQ Contiene il valore richiesto per la frequenza della CPU sul comando srun
come una frequenza numerica in kilohertz, o un valore codificato per a
richiesta di Basso, medie,alto1 or alto per la frequenza. Vedi il
descrizione del --freq-cpu opzione o il SLURM_CPU_FREQ_REQ ingresso
variabile d'ambiente.

SLURM_CPUS_ON_NODE Numero di processori disponibili per il lavoro su questo nodo. Notare la
Il plug-in select/linear alloca interi nodi ai lavori, quindi il valore
indica il conteggio totale delle CPU sul nodo. Per il
plug-in select/cons_res, questo numero indica il numero di core attivi
questo nodo allocato al lavoro.

SLURM_CPUS_PER_TASK Numero di CPU richieste per attività. Impostato solo se il --cpus-per-attività
l'opzione è specificata.

DISTRIBUZIONE_SLURM Tipo di distribuzione per i lavori allocati. Imposta la distribuzione con
-m, --distribuzione.

SLURM_GTIDS ID attività globali in esecuzione su questo nodo. Origine zero e virgola
separato.

SLURM_JOB_CPUS_PER_NODE
Numero di CPU per nodo.

SLURM_JOB_DEPENDENZA Imposta il valore dell'opzione --dependency.

SLURM_JOB_ID (E SLURM_JOBID per retrocompatibilità)
ID lavoro del lavoro in esecuzione.

SLURM_JOB_NAME Imposta il valore dell'opzione --job-name o il nome del comando quando
srun viene utilizzato per creare una nuova allocazione del lavoro. Non impostato quando srun è
utilizzato solo per creare una fase di lavoro (cioè all'interno di un lavoro esistente
allocazione).

SLURM_JOB_PARTITION Nome della partizione in cui è in esecuzione il lavoro.

SLURM_LAUNCH_NODE_IPADDR
Indirizzo IP del nodo da cui è stato avviato l'avvio dell'attività
(da dove è stato eseguito il comando srun).

SLURM_LOCALID ID attività locale del nodo per il processo all'interno di un lavoro.

SLURM_MEM_BIND_VERBOSE
--mem_bind verbosità (silenzioso, dettagliato).

SLURM_MEM_BIND_TYPE --mem_bind tipo (none,rank,map_mem:,mask_mem:).

SLURM_MEM_BIND_LIST --mem_bind mappa o lista di maschere ( ).

SLURM_NNODES Numero totale di nodi nell'allocazione delle risorse del lavoro.

SLURM_NODE_ALIASES Set di nome nodo, indirizzo di comunicazione e nome host per i nodi
assegnato al lavoro dal cloud. Ogni elemento dell'insieme se
separati da due punti e ogni set è separato da virgole. Per esempio:
SLURM_NODE_ALIASES=ec0:1.2.3.4:foo,ec1:1.2.3.5:bar

SLURM_NODEID L'ID nodo relativo del nodo corrente.

SLURM_NODELIST Elenco dei nodi allocati al lavoro.

SLURM_NTASKS (E SLURM_NPROCS per retrocompatibilità)
Numero totale di processi nel lavoro corrente.

SLURM_PRIO_PROCESSO La priorità di pianificazione (valore interessante) al momento dell'invio del lavoro.
Questo valore viene propagato ai processi generati.

SLURM_PROCID Il rango MPI (o l'ID processo relativo) del processo corrente.

SLURM_SRUN_COMM_HOST Indirizzo IP dell'host di comunicazione srun.

SLURM_SRUN_COMM_PORT srun porta di comunicazione.

SLURM_STEP_LAUNCHER_PORT
Porta di avvio dei passaggi.

SLURM_STEP_NODELIST Elenco dei nodi allocati al passaggio.

SLURM_STEP_NUM_NODES Numero di nodi allocati al passo.

SLURM_STEP_NUM_TASKS Numero di processi nel passaggio.

SLURM_STEP_TASKS_PER_NODE
Numero di processi per nodo all'interno del passaggio.

SLURM_STEP_ID (E SLURM_STEPID per retrocompatibilità)
L'ID del passaggio del lavoro corrente.

SLURM_SUBMIT_DIR La directory da cui svenuto è stato invocato.

SLURM_SUBMIT_HOST Il nome host del computer da cui saloc è stato invocato.

SLURM_TASK_PID L'ID processo dell'attività avviata.

SLURM_TASKS_PER_NODE Numero di attività da avviare su ciascun nodo. I valori sono virgola
separati e nello stesso ordine di SLURM_NODELIST. Se due o più
i nodi consecutivi devono avere lo stesso conteggio delle attività, quel conteggio è
seguito da "(x#)" dove "#" è il conteggio delle ripetizioni. Per esempio,
"SLURM_TASKS_PER_NODE=2(x3),1" indica che i primi tre nodi
ciascuno eseguirà tre attività e il quarto nodo ne eseguirà una
compito.

SLURM_TOPOLOGIA_ADDR Questo è impostato solo se il sistema ha il plugin topology/tree
configurato. Il valore sarà impostato sui nomi degli switch di rete
che possono essere coinvolti nelle comunicazioni del lavoro dal sistema
switch di livello superiore fino allo switch foglia e termina con il nome del nodo.
Un punto viene utilizzato per separare il nome di ogni componente hardware.

SLURM_TOPOLOGIA_ADDR_PATTERN
Questo è impostato solo se il sistema ha il plugin topology/tree
configurato. Il valore verrà impostato sui tipi di componenti elencati in
SLURM_TOPOLOGIA_ADDR. Ogni componente sarà identificato come
"interruttore" o "nodo". Viene utilizzato un punto per separare ciascun hardware
tipo di componente.

SRUN_DEBUG Imposta al livello di registrazione del svenuto comando. Il valore predefinito è 3
(livello informazioni). Il valore viene incrementato o decrementato in base a
le opzioni --verbose e --quiet.

MPIRUN_NOALLOCATE Non allocare un blocco solo sui sistemi Blue Gene.

MPIRUN_NOFREE Non liberare un blocco solo sui sistemi Blue Gene.

MPIRUN_PARTITION Il nome del blocco solo sui sistemi Blue Gene.

SEGNALI E ESCAPE SEQUENZE

Segnali inviati al svenuto comando vengono automaticamente inoltrati alle attività che è
controllo con poche eccezioni. La sequenza di fuga riferirà lo stato
di tutti i compiti associati al svenuto comando. Se viene inserito due volte in uno
in secondo luogo, il segnale SIGINT associato verrà inviato a tutte le attività e una terminazione
verrà inserita la sequenza inviando SIGCONT, SIGTERM e SIGKILL a tutte le attività generate. Se un
Terzo viene ricevuto, il programma srun verrà terminato senza attendere
attività remote per uscire o il loro I/O da completare.

La sequenza di fuga è attualmente ignorato. Il nostro intento è per questo mettere il svenuto
comando in una modalità in cui possono essere invocate varie azioni speciali.

MPI SUPPORTO

L'utilizzo di MPI dipende dal tipo di MPI utilizzato. Ce ne sono tre fondamentalmente diversi
modalità operative utilizzate da queste varie implementazioni MPI.

1. Slurm avvia direttamente le attività ed esegue l'inizializzazione delle comunicazioni
(Quadrics MPI, MPICH2, MPICH-GM, MVAPICH, MVAPICH2 e alcune modalità MPICH1). Per esempio:
"srun -n16 a.out".

2. Slurm crea un'allocazione di risorse per il lavoro e poi mpirun avvia le attività usando
L'infrastruttura di Slurm (OpenMPI, LAM/MPI, HP-MPI e alcune modalità MPICH1).

3. Slurm crea un'allocazione di risorse per il lavoro e poi mpirun avvia le attività usando
qualche meccanismo diverso da Slurm, come SSH o RSH (BlueGene MPI e alcune modalità MPICH1).
Questi compiti sono iniziati al di fuori del monitoraggio o del controllo di Slurm. L'epilogo di Slurm dovrebbe essere
configurato per eliminare queste attività quando si rinuncia all'assegnazione del lavoro.

See http://slurm.schedmd.com/mpi_guide.html per ulteriori informazioni sull'uso di questi vari
Implementazione MPI con Slurm.

MULTIPLA PROGRAMMA CONFIGURAZIONE

I commenti nel file di configurazione devono avere un "#" nella colonna uno. Il file di configurazione
contiene i seguenti campi separati da spazi bianchi:

grado di incarico
Uno o più livelli di attività per utilizzare questa configurazione. Più valori possono essere virgole
separato. Gli intervalli possono essere indicati con due numeri separati da un '-' con il
prima il numero più piccolo (es. "0-4" e non "4-0"). Per indicare tutte le attività non
altrimenti specificato, specifica un rango di '*' come ultima riga del file. Se uno
tentativo di avviare un'attività per la quale non è definito alcun programma eseguibile,
verrà prodotto il seguente messaggio di errore "Nessun programma eseguibile specificato per questo
compito".

eseguibile
Il nome del programma da eseguire. Se lo si desidera, può essere un nome di percorso completo.

argomenti
Argomenti del programma. L'espressione "%t" verrà sostituita con il numero dell'attività.
L'espressione "%o" saràsostituita con l'offset dell'attività all'interno di questo intervallo (es
un valore di classifica dell'attività configurato di "1-5" avrebbe valori di offset di "0-4"). Separare
le virgolette possono essere utilizzate per evitare di interpretare i valori racchiusi. Questo campo è
opzionale. Verranno aggiunti tutti gli argomenti per il programma immessi nella riga di comando
agli argomenti specificati nel file di configurazione.

Per esempio:
################################################ #################
# srun più file di configurazione del programma
#
# srun -n8 -l --multi-prog silly.conf
################################################ #################
4-6 nome host
1,7 compito eco:%t
0,2-3 offset eco:%o

> srun -n8 -l --multi-prog silly.conf
0: offset: 0
1: compito:1
2: offset: 1
3: offset: 2
4: linux15.llnl.gov
5: linux16.llnl.gov
6: linux17.llnl.gov
7: compito:7

ESEMPI

Questo semplice esempio dimostra l'esecuzione del comando hostname in otto compiti. A
almeno otto processori saranno assegnati al lavoro (lo stesso del conteggio delle attività) su
tuttavia sono necessari molti nodi per soddisfare la richiesta. L'output di ogni attività sarà
ha proceduto con il suo numero di compito. (La macchina "dev" nell'esempio seguente ha un totale di
due CPU per nodo)

> srun -n8 -l nome host
0: sviluppo 0
1: sviluppo 0
2: sviluppo 1
3: sviluppo 1
4: sviluppo 2
5: sviluppo 2
6: sviluppo 3
7: sviluppo 3

il srun -r l'opzione viene utilizzata all'interno di uno script di lavoro per eseguire due fasi di lavoro su nodi disgiunti in
il seguente esempio. Lo script viene eseguito utilizzando la modalità di allocazione anziché come lavoro batch in
questo caso.

> gatto test.sh
#!/bin/sh
eco $SLURM_NODELIST
srun -lN2 -r2 nome host
srun -lN2 nome host

> salloc -N4 test.sh
sviluppo[7-10]
0: sviluppo 9
1: sviluppo 10
0: sviluppo 7
1: sviluppo 8

Lo script seguente esegue due fasi del lavoro in parallelo all'interno di un insieme di nodi allocato.

> gatto test.sh
#!/ bin / bash
srun -lN2 -n4 -r 2 dormi 60 &
srun -lN2 -r 0 sleep 60 &
dormi 1
filare
coda -s
aspettare

> salloc -N4 test.sh
JOBID NOME PARTIZIONE UTENTE ST ORA NODI LISTA NODI
65641 batch test.sh grondo R 0:01 4 dev[7-10]

ELENCO NODE TEMPO UTENTE PARTIZIONE STEPID
65641.0 gruppo grondo 0:01 dev[7-8]
65641.1 gruppo grondo 0:01 dev[9-10]

Questo esempio mostra come si esegue un semplice lavoro MPICH. Noi usiamo svenuto costruire un
elenco di macchine (nodi) da utilizzare da mpirun nel formato richiesto. Un comando di esempio
seguono la riga e lo script da eseguire.

> gatto test.sh
#!/bin/sh
MACHINEFILE="nodi.$SLURM_JOB_ID"

# Genera Machinefile per mpich in modo che gli host siano gli stessi
# ordina come se eseguito tramite srun
#
correre -l /bin/nomehost | sort -n | awk '{print $2}' > $MACHINEFILE

# Esegui utilizzando il file macchina generato:
mpirun -np $SLURM_NTASKS -filemacchina $FILEMACCHINA mpi-app

rm $FILEMACCHINA

> salloc -N2 -n4 test.sh

Questo semplice esempio dimostra l'esecuzione di diversi lavori su diversi nodi nel
stesso srun. Puoi farlo per qualsiasi numero di nodi o qualsiasi numero di lavori. Il
gli eseguibili sono posizionati sui nodi situati da SLURM_NODEID env var. A partire da 0 e
andando al numero specificato nella riga di comando srun.

> gatto test.sh
caso $SLURM_NODEID in
0) echo "Sto correndo su "
Nome host ;;
1) nome host
echo "è dove sto correndo" ;;
che C

> srun -N2 test.sh
dev0
è dove sto correndo
Sto correndo
dev1

Questo esempio mostra l'uso di opzioni multi-core per controllare il layout delle attività. Noi
richiedere che quattro socket per nodo e due core per socket siano dedicati al lavoro.

> srun -N2 -B 4-4:2-2 a.out

Questo esempio mostra uno script in cui viene utilizzato Slurm per fornire la gestione delle risorse per a
lavoro eseguendo le varie fasi del lavoro man mano che i processori diventano disponibili per i loro dedicati
utilizzare.

> gatto mio.script
#!/ bin / bash
srun --exclusive -n4 prog1 &
srun --exclusive -n3 prog2 &
srun --exclusive -n1 prog3 &
srun --exclusive -n1 prog4 &
aspettare

COPIA

Copyright (C) 2006-2007 I reggenti dell'Università della California. Prodotto a Lawrence
Livermore National Laboratory (cfr. DISCLAIMER).
Copyright (C) 2008-2010 Lawrence Livermore Sicurezza nazionale.
Copyright (C) 2010-2015 SchedMD LLC.

Questo file fa parte di Slurm, un programma di gestione delle risorse. Per i dettagli, vedere
<http://slurm.schedmd.com/>.

Slurm è un software gratuito; puoi ridistribuirlo e/o modificarlo secondo i termini del
GNU General Public License come pubblicata dalla Free Software Foundation; entrambe le versioni 2
della Licenza o (a tua scelta) qualsiasi versione successiva.

Slurm viene distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA; privo di
anche la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedi il
Licenza GNU General Public per maggiori dettagli.

Utilizzare srun online utilizzando i servizi onworks.net