---- ENGLISH VERSION HERE ----
NUOVO SCHEDULER SLURM / NEW SLURM SCHEDULER
Concetti fondamentali
Il server 'blade' installato presso il nostro Dipartimento è configurato per soddisfare le richieste di risorse di calcolo da parte degli utenti in modalita' non interattiva o 'batch'.
E' possibile eseguire sul cluster qualsisasi applicazione a 32 o 64 bit che eseguireste abitualmente da uno dei PC Linux della rete DEI (ad esempio Matlab) o qualsiasi programma abbiate ricompilato da voi.
Le varie richieste vengono prese in carico dal programma di gestione del server, accodate in base ad un sistema di priorità ed eseguite dalla risorsa di calcolo più adeguata in quel momento.
I risultati della computazione che normalmente comparirebbero a video vengono salvati in un file di output.
Il programma di gestione adottato è Sun Grid Engine. Come altri sistemi di gestione simili il meccanismo di interazione principale consiste nel creare un file di testo (job file) contenente le richieste di risorse di calcolo ed il precorso (almeno) del programma da eseguire, del file da usare come input e di quello da scrivere come output. Una volta creato il job file un apposito comando (qsub) viene usato per accodare la richiesta.
Il cluster e' composto da 14 'lame' di calcolo variamente dimensionate. Alla data odierna (21 Settembre 2018) sono presenti:
Code, Job, Slot
Le richieste inoltrate dagli utenti (Job) vengono presi in carico dal sistema di gestione e messi in coda. Normalmente ogni Job occupa uno slot (idealmente pari ad una CPU) a meno che non ne vengano richiesti piu' di uno mediante l'utilizzo di un parallel environment (si veda il capitolo relativo al Sistema di Code)
Quindi, normalmente:
1 Job == 1 slot == 1 istanza della coda che consuma 1 CPU
Se si richiedono N processori attraverso il parallel environment invece
1 Job == N slot == 1 istanza della coda che consuma N CPU
Progetti
Il concetto di Progetto e' stato di fatto dismesso. Esiste un unico progetto Default: la richiesta esplicita di uno dei progetti configurati inizialmente (10_Bio, 10_Signet, 20_Telecom, 30_Ricerca o 40_Studenti) non generera' errori ma non avra' nessun effetto.
Limiti di utilizzo
Ogni utente puo' avere ul massimo 32 slot in esecuzione contemporaneamente. NON c'e' invece un limite ai job che possono essere accodati, cioe' in coda in attesa di essere eseguiti.
Questo significa che come utente potrei avere in esecuzione contemporaneamente:
Allo stato attuale sono state definite:
Code speciali
La coda gpu da' accesso al server di calcolo gpu1.dei.unipd.it che, oltre a 48 core di calcolo ed 1TB di RAM, e' equipaggiato con 7 GPU NVIDIA Titan 1080i. Per avere accesso a questa coda e' necessario:
#$ -q gpu
Parallel environment
Per poter utilizzare al meglio il cluster di calcolo con programmi che utilizzano piu' di una CPU (thread) e' necessario richiedere esplicitamente l'uso del parallel environment aggiungendo l'opzione -pe parallel N al comando qsub oppure aggiungendo al job file una riga del tipo
#$ -pe parallel N
dove N e' il numero di processori / thread che il programma utilizzera'.
Il parallel environment e' disponibile su tutti i nodi di calcolo ad eccezione di quelli con meno CPU (runner-04, runner-18 e runner-19).
La fonte principale di documentazione per tutto il sistema di gestione Sun Grid Engine sono le pagine di manuale accessibili dalla linea di comando (ad esempio: man qstat). Un veloce riassunto delle principali opzioni di ciascun comando si puo' ottenere usando lo switch '-help'.
qstat
mostra lo stato dei job e delle code
| parametro | funzione |
|---|---|
| <nessun parametro> | mostra i job in coda |
| -f | stato di tutte le code |
| -j [JOBID] | stato dettagliato [del job numero JOBID] |
Esempio:
$ qstat job-ID prior name user state submit/start at queue slots ja-task-ID ---------------------------------------------------------------------------------------------------------------- 1852431 0.00124 test mazzon r 09/17/2018 11:29:25 Q@runner-04.dei.unipd.it 1 1852432 0.00062 test mazzon r 09/17/2018 11:29:25 Q@runner-18.dei.unipd.it 1 1852433 0.00000 test mazzon qw 09/17/2018 11:29:25
Esempio 2:
$ qstat -j 1852439
==============================================================
job_number: 1852439
exec_file: job_scripts/1852439
submission_time: Mon Sep 17 11:33:58 2018
owner: mazzon
uid: 6912
group: sysadmin
gid: 444
sge_o_home: /home/mazzon
sge_o_log_name: mazzon
sge_o_path: ..../usr/sbin:/nfsd/local/common/bin:/nfsd/opt/mrtrix3/release/bin:/nfsd/opt/mrtrix3/scripts:/home/mazzon/bin
sge_o_shell: /bin/bash
sge_o_workdir: /home/mazzon/devel/jobs
sge_o_host: login
account: sge
cwd: /home/mazzon/devel/jobs
stderr_path_list: NONE:NONE:/dev/null
mail_list: mazzon@login.dei.unipd.it
notify: FALSE
job_name: parallel.job
stdout_path_list: NONE:NONE:/dev/null
jobshare: 0
env_list:
script_file: parallel.job
parallel environment: parallel range: 16
project: Default
scheduling info: (no project) does not have the correct project to run in cluster queue "am.q"
(no project) does not have the correct project to run in cluster queue "ax.q"
(no project) does not have the correct project to run in cluster queue "m-all.q"
(no project) does not have the correct project to run in cluster queue "m.q"
(no project) does not have the correct project to run in cluster queue "x-all.q"
(no project) does not have the correct project to run in cluster queue "x.q"
(no project) does not have the correct project to run in cluster queue "FULL"
(no project) does not have the correct project to run in cluster queue "MEDIUM"
(no project) does not have the correct project to run in cluster queue "HIGH"
cannot run in PE "parallel" because it only offers 0 slots
qhost
mostra lo stato degli host per l'esecuzione
| parametro | funzione |
|---|---|
| <nessun parametro> | mostra una tabella degli host per l'esecuzione |
| -q | lista delle code disponibili sui vari host |
| -j | mostra i job in esecuzione sui vari host |
Esempio:
$ qhost
HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS ------------------------------------------------------------------------------- global - - - - - - - bella linux-x64 2 - 1.9G - 2.4G - gpu1 lx26-amd64 48 0.00 1007.3G 2.7G 15.3G 0.0 runner-01 linux-x64 96 0.01 1511.6G 1.4G 16.0G 0.0 runner-02 linux-x64 96 0.00 1511.6G 1023.9M 16.0G 0.0 runner-03 linux-x64 96 46.96 1511.6G 2.4G 16.0G 0.0 runner-04 linux-x64 8 0.31 31.4G 2.0G 16.0G 38.0M runner-06 linux-x64 24 11.31 141.5G 3.5G 16.0G 40.4M runner-07 linux-x64 24 12.91 137.7G 2.2G 16.0G 73.8M runner-13 linux-x64 64 17.01 251.9G 22.2G 16.0G 35.7M runner-14 linux-x64 64 62.11 251.9G 3.2G 16.0G 0.0 runner-15 linux-x64 24 11.92 94.4G 16.2G 16.0G 0.0 runner-16 linux-x64 24 20.93 78.7G 4.4G 16.0G 742.9M runner-17 linux-x64 24 22.96 78.7G 4.2G 16.0G 51.3M runner-18 linux-x64 8 0.00 31.4G 360.4M 16.0G 60.8M runner-19 linux-x64 8 23.30 31.4G 6.7G 16.0G 40.2M
qsub
lancia un job
| parametro | funzione |
|---|---|
| -cwd | tutti i percorsi indicati sono relativi alla directory corrente |
| -o output.txt | redireziona lo standard output nel file output.txt. Se non specificato vengono generati file con suffisso .oXYZ, dove XYZ e' il job-ID |
| -e error.txt | redireziona lo standard error nel file error.txt. Se non specificato vengono generati file con suffisso .eXYZ, dove XYZ e' il job-ID |
| -m b|e|a|s|n | seleziona in che occasioni notificare via mail l'utente. DEFAULT: nessuna notifica. Le possibili opzioni (se ne possono specificare piu' di una) sono:
|
N.B.: Tutti i parametri della linea di comando possono essere messi in un job file anteponendo all'opzione (una o piu' per riga) i due caratteri '#$'.
qdel
elimina un job in coda
| parametro | funzione |
|---|---|
| -u MIALOGIN | cancella TUTTI i miei job (sia in esecuzione che in coda) |
| lista_di_job | cancella tutti e soli i job specificati in lista_di_job |
Per poter usare il cluster di calcolo è OBBLIGATORIO connettersi via SSH al server login.dei.unipd.it
Per prima cosa, quindi, collegatevi al server login: i comandi indicati dopo il carattere '$' sono quelli che dovete scrivere da tastiera.
$ ssh LoginDEI@login.dei.unipd.it
La password che viene chiesta è quella relativa alla vostra login del DEI.
ESEMPIO 1: sottomettere come semplice 'job' al sistema la stampa della lista dei files nella cartella corrente.
Lanciando semplicemente il comando 'ls' da terminale questo verrebbe eseguito sulla macchina dove siamo collegati in quel momento: vogliamo invece che l'esecuzione avvenga su uno dei nodi di calcolo. Per far ciò usiamo il comando 'qsub'.
$ qsub -cwd -m ea (...premete INVIO)
ls
( premete ora CTRL + d )
Your job 1598 ('STDIN') has been submittedIl job viene accodato (preso in carico) dal sistema: inizialmente lo stato (colonna 'state') sara' 'qw' (queued, waiting):
$ qstat job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1598 0.00000 STDIN mazzon qw 03/03/2009 11:50:51 1
Ad un certo punto il job passerà dallo stato 'qw' allo stato 'r' (running):
$ qstat job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1598 0.75000 STDIN mazzon r 03/03/2009 12:32:22 Q@runner-01.dei.unipd.it 1
Al termine della computazione l'output del programma si trova nel file STDIN.o1598 (dove 1598 è il JOBID: si veda il comando precedente).
In questa modalità di interazione dovete riscrivere ogni volta tutti i comandi!
ESEMPIO 2: avvio di uno script Matlab
1) Create un job file (ad esempio test.job) contenente:
#!/bin/bash
#
# Imposta il valore 'name' di qstat
#$ -N test
#
# Tutti i percorsi sono relativi alla cartella corrente (-cwd)
# Genera output ed errori nella cartella corrente.
#$ -cwd
#
# Non redirigo l'output: ogni esecuzione generera' un file diverso.
# Il file di output sara' test.job.oJOBID
# Il file degli errori sara' test.job.eJOBID
#
# Voglio ricevere una mail quando il job termina
# o in caso venga abortito
#
#$ -m ea
matlab -r ScriptDaEseguire
2) Spostatevi nella cartella contenente il job file e sottoponetelo al sistema di gestione:
$ cd path/to/my/files
$ qsub test.job
3) Per vedere l'avanzamento del lavoro è sufficiente digitare il comando qstat. L'output del comando indica lo stato del lavoro (colonna 'state'), e soprattutto il jobid (job-ID) assegnato.
job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1698 0.75000 test mazzon r 03/03/2009 12:32:22 Q@runner-01.dei.unipd.it 1
4) Eventuali file di output si trovano nella cartella contenente tutti i file MATLAB ed il job file
In questa modalita' di interazione per ripetere il job e' sufficiente rieseguire il qsub