Podstawy:SLURM vs PBS

Strona zawiera krótkie podsumowanie różnić w specyfikowaniu zasobów dla zadań w systemach SLURM i PBS. Strona może być pomocna dla osób przenoszących swoje skrypty pomiędzy tymi dwoma systemami kolejkowymi, ale nie jest wyczerpującym źródłem wiedzy. W przypadku wątpliwości prosimy o kontakt lub przestudiowanie dokumentacji do danego systemu kolejkowego.

Dyrektywa systemu kolejkowego dla plików batchowych

SLURM	PBS
#SBATCH	#PBS

Najważniejsze opcje oraz parametry

Opcja SLURM	Opcja PBS
-N (--nodes=)	-l nodes=
--ntasks-per-node=	-l ppn=
--cpus-per-task=	-l ppn=
--mem-per-cpu=	-l pmem=
--mem=	-l mem=
-t (--time=)	-l walltime=
-p (--partition=)	-q
-o filename -e filename	-j oe
--mail-type=	-m
--mail=	-M

Specyfikowanie partycji (kolejki), grantu i czasu trwania zadania

SLURM wymaga, podobnie jak PBS, aby specyfikować partycję (według PBS kolejkę), nazwę grantu i czas trwania zadania, wygląda to odpowiednio dla:

PBS:

qsub -q plgrid -A nazwa_grantu -l walltime=12:00:00 job.sh

SLURM:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 job.sh

Partycja w parametrach SLURMa odpowiada nazwie kolejki, stosowanej w PBS. Jeżeli posiadamy odpowiednio ustawiony grant domyślny można skrócić wywołanie sbatch do:

sbatch --time=12:00:00 job.sh

gdyż plgrid jest domyślną partycją.

Typowe konfiguracje zadań względem liczby i zastosowania rdzeni

SLURM w odróżnieniu od PBS pozwala na bardziej granularne wyspecyfikowanie zasobów. Dzięki temu, że system kolejkowy dysponuje taką informacją możliwe jest zautomatyzowanie i optymalizacja procesu uruchamiania aplikacji.

Poniższe przykłady często zawierają nadmiarowo dokładną specyfikację zasobów. Część parametrów może zostać pominięta, ze względu na ich wartość domyślną, lub fakt, że system kolejkowy jest w stanie wyliczyć pominięte parametry na podstawie pozostałych. W przypadku wątpliwości odnośnie kształtu alokacji zachęcamy do dokładnego specyfikowania parametrów lub kontaktu.

Zadanie jednordzeniowe

Najprostszy typ zadania, gdzie alokujemy jeden rdzeń.

PBS:

qsub -q plgrid -A nazwa_grantu -l nodes=1:ppn=1 -l walltime=12:00:00 job.sh

SLURM:

sbatch -p plgrid -A nazwa_grantu -N 1 -n 1 --time=12:00:00 job.sh

W obu przypadkach podawanie dokładnej liczby węzłów (-l nodes=1, -N) i procesów (-n) jest nadmiarowe, gdyż ich domyślne wartości wynoszą 1. W przypadku SLURMa komenda bez nadmiarowych argumentów wygląda następująco:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 job.sh

Zadanie wielowątkowe (OpenMP)

Zadanie alokuje jeden węzeł obliczeniowy, na którym zostanie uruchomiony 1 proces z 12 wątkami, alokacja obejmie 12 rdzeni.

PBS:

qsub -q plgrid -A nazwa_grantu -l nodes=1:ppn=12 -l walltime=12:00:00 job.sh

SLURM:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 1 -n 1 --cpus-per-task=12 job.sh

Warto zwrócić uwagę, że parametry oznaczające liczbę węzłów (-N) i procesów (-n) są nadmiarowe, gdyż ich domyślne wartości wynoszą 1. W przypadku SLURMa komenda bez nadmiarowych argumentów wygląda następująco:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 --cpus-per-task=12 job.sh

Zadanie wieloprocesowe/rozproszone (MPI)

Typowe zadanie MPI, gdzie uruchamiany jest jeden proces na każdy rdzeń. Przykładowe zadanie korzysta z dwóch węzłów po 12 rdzeni, co przekłada się na 24 "ranki" czyli procesy aplikacji.

PBS:

qsub -q plgrid -A nazwa_grantu -l nodes=2:ppn=12 -l walltime=12:00:00 job.sh

w samym skrypcie:
mpiexec applikacja.mpi

SLURM:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 -n 24 --ntasks-per-node=12 job.sh

w samym skrypcie:
mpiexec applikacja.mpi

Kluczowym parametrem jest -n określające sumaryczną liczbę procesów. System jest na tyle sprytny, że może sam wyliczyć ten parametr na podstawie liczby węzłów i ilości procesów per węzeł, wygląda to następująco:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 --ntasks-per-node=12 job.sh

analogicznie można pozostawić do wyliczenia ilość procesów per węzeł:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 -n 24 job.sh

Możliwe jest też pominięcie parametru -N co spowoduje, że aplikacja rozproszy się pomiędzy dowolną liczbę węzłów. Nie zalecamy takiej konfiguracji, gdyż aplikacje rozproszone najczęściej zyskują na efektywności w przypadku gdy korzysta się z węzłów przydzielonych na wyłączność dla danej aplikacji (co uzyskujemy określając ich odpowiednią liczbę z góry).

Zadanie hybrydowe (MPI + OpenMP)

Przykładowe zadanie składa się z 4 procesów po 6 wątków, co w sumie przekłada się na 2 węzły po 12 rdzenie, czyli w sumie 24 rdzenie. Zadanie będzie wymagało dodatkowych opcji przy komendzie mpiexec (w postaci zależnej od wykorzystywanej biblioteki OpenMP) tak aby każdy proces wiedział, że ma uruchomić po 6 wątków.

PBS:

qsub -q plgrid -A nazwa_grantu -l nodes=2:ppn=12 -l walltime=12:00:00 job.sh

w samym skrypcie:
OMP_NUM_THREADS=6

mpiexec -n 4 aplikacja.mpi

SLURM:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 -n 4 --ntasks-per-node=2 --cpus-per-task=6 job.sh

w samym skrypcie:
OMP_NUM_THREADS=6

mpiexec aplikacja.mpi

Warto zwrócić uwagę, że nie ma konieczności podawania parametru -n przy mpiexec, system uzupełni go automatycznie podając odpowiednią liczbę procesów.

Analogicznie jak w poprzednim przykładzie można nieznacznie uprościć specyfikację zasobów dla SLURMa:

sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 --ntasks-per-node=2 --cpus-per-task=6 job.sh

Najważniejsze zmienne systemowe

Zmienna SLURM	Zmienna PBS
SLURM_SUBMIT_DIR	PBS_O_WORKDIR
SLURM_NTASKS	brak odpowiednika
brak odpowiednika	PBS_NP
SLURM_JOB_ID	PBS_JOBID
SLURM_ARRAY_TASK_ID	PBS_ARRAYID

Wartość PBS_NP możemy wyliczyć za pomocą SLURM_NTASKS * SLURM_CPUS_PER_TASK przy założeniu, że zadanie posiada więcej niż 1 rdzeń per proces. W innym przypadku PBS_NP jest równe SLURM_NTASKS.

Najważniejsze komendy

Komenda SLURM	Komenda PBS
sbatch	qsub
squeue	qstat
scancel	qdel