Porównanie SLURM i 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.
Spis treści
Najważniejsze komendy
| Komenda SLURM | Komenda PBS |
|---|---|
| sbatch | qsub |
| squeue | qstat |
| scancel | qdel |
Dyrektywa systemu kolejkowego dla skryptów batchowych
| SLURM | PBS |
|---|---|
| #SBATCH | #PBS |
Podstawowe parametry zadania
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ą.
Specyfikowanie wielkości pamięci
W przypadku PBS możliwe jest określenie ilości pamięci w następujący sposób dla całego zadania:
qsub -l mem=500mb job.sh
Alternatywnie można podać ilość pamięci na każdy rdzeń za pomocą parametru pmem:
qsub -l nodes=2:ppn=12,pmem=500mb job.sh
W przypadku SLURMa metoda specyfikowania pamięci jest inna. Możliwe jest określenie ilości pamięci dla każdego węzła (niezależnie, czy jest to jeden węzeł czy kilka):
sbatch --mem=2gb job.sh
Możliwe jest też określenie ilości pamięci dla każdego rdzenia (niezależnie, czy korzystamy z jednego czy wielu rdzeni), analogicznie do parametru pmem w PBS:
sbatch --mem-per-cpu=1gb job.sh
Standardowe wyjście zadania
SLURM domyślnie zapisuje wyjścia standardowe i błędu w pliku slurm-<jobid>.out w katalogu, z którego zadanie zostało uruchomione. Aby zmienić to zachowanie należy skorzystać z parametrów -o nazwa_pliku.txt do przekierowania wyjść do pliku.
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.