HOME| CRESCO| Guide/tutorials| Contatti| F.A.Q.

Guide / tutorials

Batch Jobs/LSF.

SOMMARIO:

  1. Comandi base di LSF
  2. Le code di LSF specifiche per CRESCO
  3. Uso efficiente della sezione 2 di CRESCO
  4. Sottomissione di un' job parallelo (MPI).
    1. OpenMPI (gcc, pgi, intel)
    2. Mvapich (gcc, pgi, intel)
    3. MPI Intel (solo intel)
    4. LAM/MPI (solo gcc)
  5. Gestione della tmp
  6. Links utili

1. Comandi base di LSF

La sottomissione di batch jobs su CRESCO, e' del tutto analoga a quella per l'ENEAGRID. Per prendere confidenza con l'ambiente LSF e' necessario conoscere i principali comandi per:
Una guida sintetica si può trovare QUI.

In ogni caso per approfondimenti o per vedere 'dal vivo' come usare LSF e' utile guardare i video dei seminari tenuti da A. Secco via Web. Sono accessibili dal sito di Cresco al seguente link [ Seminari LSF ].
In particolare vi segnaliamo i link presenti al suddetto indirizzo, sotto le voci:

[sommario]

2. Le code di LSF specifiche per CRESCO

La struttura delle code e' specifica di CRESCO.

Le code PRIORITARIE per i job paralleli e consigliate per lavorare in Cresco sono (in ordine di priorità):

IMPORTANTE: I job paralleli DEVONO richiedere un numero di processori multipli di 8.

Esistono anche code per i job seriali:
Queste 2 code sono meno prioritarie rispetto alle precedenti, e devono essere usate:
Specificando la durata del job (minore è la durata, maggiore la probabilità di girare) specificando la memoria da usare nel caso di job molto grandi.
Infine, esiste una coda interattiva, limitata a sessioni di 12 ore:

[sommario]

3. Uso efficiente della sezione 2 di CRESCO

La sezione 2 e' composta da macchine efficienti per l'alto parallelismo e sono caratterizzate dalla risorsa LSF denominata "high_parallel".
Queste sono riconoscibili dall'hostname della forma "cresco2x000.portici.enea.it" dove i numeri "000" vanno sostituiti con il numero progressivo che le identifica, attualmente da 001 a 340.
Queste macchine sono state inserite nel cluster in periodi diversi e non hanno le stesse architettura: in particolare

001-256    Intel(R) Xeon(R) 5345  (Clovertown)    per un totale di 2048 core
257-284    Intel(R) Xeon(R) 5530  (Nehalem)       per un totale di  224 core
285-312    Intel(R) Xeon(R) 5620  (Westmare)     per un totale di 224 core
313-340    Intel(R) Xeon(R) 5530  (Nehalem)       per un totale di 224 core

Le macchine Westmere e Nehalem in generale, anche se molto dipende dai particolari applicativi utilizzati, hanno prestazioni parallele migliori delle Clovertown.
Per lavorare utilizzando queste macchine, in generale, basta utilizzare una delle seguenti code cresco parallele:

cresco_16h2
cresco_16h8
cresco_16h24
cresco_128h2
cresco_128h8
cresco_128h24
cresco_512h2
cresco_512h8
cresco_512h24

ricordando però che le code cresco_16hxx possono sottomettere job anche sulla sezione 1 (più orientata al largo suo di memoria).

In automatico le code cercano di occupare prima le macchine di tipo Clovertown, poi Nehalem e infine Westmere.
Quando il job parallelo utilizza macchine di differenti prestazioni, questo avra' una velocità di esecuzione limitata dalla presenza delle macchine meno performanti.
Per utilizzare un gruppo di macchine dello stesso tipo puo' essere usata, in fase di sottomissione LSF, la richiesta di un particolare modello di macchina e cioe':

 "-R select[type==high_parallel && model==intel_E5345]" per usare esclusivamente macchine Clovertown
 "-R select[type==high_parallel && model==intel_E5530]" per usare esclusivamente macchine Nehalem
 "-R select[type==high_parallel && model==intel_E5620]" per usare esclusivamente macchine Westmere

Si possono fare anche combinazioni. Ad esempio
 "-R select[type==high_parallel && (model==intel_E5530 || model==intel_E5620)]" per usare esclusivamente e indifferentemente macchine Nehalem e Westmere;
"-R select[type==high_parallel]" per usare qualsiasi macchina della sezione 2 (utile per chi usa le code cresco_16hxx e non vuole sottomettere sulla sezione 1).

Si vuole far comunque notare che la disponibilita' di macchine Clovertown e' molto più ampia delle altre quindi e' possibile avere tempi di attesa superiori per l'esecuzione del job nel caso vengano escluse.

[sommario]

4. Sottomissione di un job parallelo (MPI).

E' utile sintetizzare come LSF gestisce l'esecuzione dei job: quando LSF esegue un job (ovvero dopo aver sottomesso il programma con bsub), viene impostata la variabile d'ambiente LSB_HOSTS che contiene gli hostname delle macchine sulle quali avviene l'esecuzione. Per i job paralleli, LSB_HOSTS contiene la lista completa degli host allocati. Tuttavia LSF e' solo un'interfaccia per l'esecuzione dei job paralleli e non supporta particolari applicazioni, piuttosto le implementazioni dei vari paradigmi di programmazione parallela permettono l'esecuzione con LSF usando script di shell e wrapper, questi gestiscono la lista degli host su cui avviene l'esecuzione usando la variabile sopra citata (eventualmente sovrascritta) o gli host_file. La struttura base del comando di sottomissione per un job parallelo e':

bsub -n n_procs  mpirun_wrapper.sh

dove "-n" serve a specificare il numero di processori e mpirun_wrapper.sh e' uno script che contiene il comando "mpirun" ed il programma MPI da lanciare. La descrizione di tale wrapper segue (presentiamo anche un esempio pratico).

NOTA: Poiche' LSF alloca un certo insieme di hosts (a causa dell'opzione "-n ...") e "mpirun" richiede la lista di hosts (l'hostfile) su cui lanciare i processi MPI, le due liste devono coincidere. Per ottenere ciò si può sfruttare la variabile che LSF definisce quando si allocano gli slot con l'opzione "-n". Tale variabile e' "LSB_DJOB_HOSTFILE" ed essa contiene il path dell'hostfile creato da LSF.

Lo script mpirun_wrapper.sh deve fare quanto segue:

Supponiamo di avere un programma MPI (gia' compilato) chiamato "Hello_MPI". Per sottomettere con LSF digiterò il seguente comando:

bsub -n 16 -o lsf.out -e lsf.err -q cresco_16h2 ./my_script.sh

Sto specificando:

Ma come deve essere fatto lo script my_script.sh ?. Ecco una versione essenziale per le implementazioni disponibili su CRESCO:

• OpenMPI (gcc, pgi, intel)

#!/bin/sh

exe=/afs/enea.it/por/user/raia/Hello_MPI    # path of your MPI program
HOSTFILE=$LSB_DJOB_HOSTFILE     # name of hostfile for mpirun

N_procs=`cat $LSB_DJOB_HOSTFILE | wc -l`     # give to mpirun same number of slots

mpirun --mca pls_rsh_agent "blaunch.sh" -n $N_procs --hostfile $HOSTFILE $exe

ATTENZIONE: occorre mantenere la stringa --mca pls_rsh_agent "blaunch.sh", affinche' venga usata l'utility blaunch di LSF (!! Senza questa stringa "mpirun" userebbe ssh e la procedura sopra descritta non funzionerebbe !!).

Bisogna inoltre precisare che la sintassi indicata risulta valida per la versione 1.2.8 di OpenMPI installata sui nodi della sezione 1 e della sezione 2 di Cresco Portici. Per le versioni della serie 1.3 e superiori, la sintassi --mca pls_rsh_agent "blaunch.sh" va sostituita con --mca plm_rsh_agent "blaunch.sh" oppure con --mca orte_rsh_agent "blaunch.sh" (sintassi indicata come ottimale dagli sviluppatori di OpenMPI). Questa informazione assume importanza rilevante per la corretta esecuzione dei job sui cluster Cresco di Casaccia e Frascati dove sono installate versioni OpenMPI anche della serie 1.4.

• Mvapich(gcc, pgi, intel)

Analogamente se si utilizza MvaPICH (gcc, intel, pgi), lo script my_script.sh va leggermente modificato:

#!/bin/sh

exe=/afs/enea.it/por/user/raia/Hello_MPI    # path of your MPI program
HOSTFILE=$LSB_DJOB_HOSTFILE     # name of hostfile for mpirun

N_procs=`cat $LSB_DJOB_HOSTFILE | wc -l`     # give to mpirun same number of slots

mpirun_rsh -rsh -np $N_procs -hostfile $HOSTFILE $exe

Qui si sostituisce la stringa --mca pls_rsh_agent "blaunch.sh" con -rsh, ma in realta' viene usato lo stesso meccanismo di lancio dei tasks.

• MPI intel (solo intel)

Per MPI Intel lo script my_script.sh va leggermente modificato:

#!/bin/sh

exe=$PWD/Hello_MPI    # path of your MPI program
HOSTFILE=$LSB_DJOB_HOSTFILE     # name of hostfile for mpirun

N_procs=`cat $LSB_DJOB_HOSTFILE | wc -l`     # give to mpirun same number of slots

lenght=`echo $LSB_MCPU_HOSTS | wc -w`

for i in `seq 1 2 $lenght`
do
echo $LSB_MCPU_HOSTS | awk -v v1=$i '{print $v1}'>>mpdmac
done

nmpd=`cat $PWD/mpdmac | wc -l`
mpdboot -r rsh -f $PWD/mpdmac -n $nmpd

mpiexec -machinefile $HOSTFILE -n $N_procs $exe

mpdallexit
rm -f mpdmac

• LAM/MPI (solo gcc)

Invece se si utilizza LAM/MPI (solo gcc), lo script my_script.sh va leggermente modificato nel seguente modo:

#!/bin/sh

exe=/afs/enea.it/por/user/raia/Hello_MPI.lam_gcc    # path of your MPI program
HOSTFILE=$LSB_DJOB_HOSTFILE     # name of hostfile for mpirun
export LAMRSH="blaunch.sh"

lamboot -v $HOSTFILE

N_procs=`cat $LSB_DJOB_HOSTFILE | wc -l`     # give to mpirun same number of slots

mpirun -np $N_procs $exe

lamhalt

Qui impostando la variabile d'ambiente LAMRSH a "blaunch.sh" ci si assicura che il lancio dei tasks paralleli venga fatto con "blaunch" sugli hosts dell'Universo LAM definito con il comando "lamboot".


Nota 1: l'uso del wrapper (qui indicato con "my_script.sh") deve essere coerente con la selezione MPI corrente. Nel caso si voglia selezionare la LAM/MPI, poiche essa rappresenta l'implementazione di default, occorre o cancellare sotto la propria home di AFS, il file ".mpi-selector" oppure eseguire il comando:

mpi-selector --unset

Nota 2: facendo un copia/incolla dello script my_script.sh, e' sufficiente cambiare il path del proprio eseguibile ed aggiungere le opzioni al programma subito dopo la variabile "$exe".

[sommario]

5. Gestione della tmp

I job paralleli possono scrivere, durante la propria esecuzione, nella cartella tmp dei nodi di calcolo su cui vengono eseguiti. Per evitare di congestionare tale spazio, il sistema prevede una gestione della tmp che permette di conservare soltanto i dati degli ultimi 10 giorni a partire dal corrente. La scelta di tale intervallo temporale e' dettata dalla durata della piu' lunga coda definita in LSF (i.e., 'cresco_largeramh240').

[sommario]

6. Link utili

[top]

ultimo aggiornamento: 26/01/2012|e-mail: Giovanni Ponti - Guido Guarnieri

Cookies Policy