Podstawy:SLURM vs PBS: Różnice pomiędzy wersjami

Z Komputery Dużej Mocy w ACK CYFRONET AGH
Skocz do:nawigacja, szukaj
 
(Nie pokazano 27 wersji utworzonych przez 2 użytkowników)
Linia 2: Linia 2:
 
[[Category:Podstawy]]
 
[[Category:Podstawy]]
  
−
Poniżej w tabeli znajduje się krótkie porównanie opcji oraz zmiennych systemowych pomiędzy systemami SLURM i PBS. Tabela może być pomocna dla osób przenoszących swoje skrypty pomiędzy tymi dwoma systemami kolejkowymi.
+
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===
+
=Najważniejsze komendy=
 
{| class="wikitable"
 
{| class="wikitable"
−
! width=50% |SLURM    !!width=50%|PBS
+
! width=50% |Komenda SLURM    !!width=50%|Komenda PBS
 +
|-
 +
| <tt>sbatch</tt> ||<tt>qsub</tt>
 +
|-
 +
| <tt>squeue</tt>|| <tt>qstat</tt>
 
|-
 
|-
−
| <tt>#SBATCH</tt> ||<tt>#PBS</tt>
+
| <tt>scancel</tt> || <tt>qdel</tt>  
 
|}
 
|}
  
−
===Najważniejsze opcje oraz parametry===
+
=Dyrektywa systemu kolejkowego dla skryptów batchowych=
 
{| class="wikitable"
 
{| class="wikitable"
−
! width=50% |Opcja SLURM    !!width=50%|Opcja PBS
+
! width=50% |SLURM    !!width=50%|PBS
 
|-
 
|-
−
| <tt>-N (--nodes=) </tt> ||<tt> -l nodes= </tt>
+
| <tt>#SBATCH</tt> ||<tt>#PBS</tt>
−
|-
 
−
| <tt>--ntasks-per-node= </tt>|| <tt>-l ppn=</tt>
 
−
|-
 
−
| <tt>--cpus-per-task=</tt> || <tt>-l ppn=</tt>
 
−
|-
 
−
| <tt>--mem-per-cpu=</tt> ||<tt> -l pmem=</tt>
 
−
|-
 
−
| <tt>--mem= </tt>||<tt> -l mem=</tt>
 
−
|-
 
−
| <tt>-t (--time=)  </tt>|| <tt>-l walltime=</tt>
 
−
|-
 
−
| <tt>-p (--partition=) </tt> || <tt>-q </tt>
 
−
|-
 
−
| <tt> -o filename -e filename </tt>|| <tt>-j oe </tt>
 
−
|-
 
−
| <tt> --mail-type=</tt> || <tt>-m </tt>
 
−
|-
 
−
| <tt> --mail= </tt>|| <tt>-M </tt>  
 
 
|}
 
|}
  
−
===Najważniejsze zmienne systemowe===
+
=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:
 +
<pre>
 +
qsub -q plgrid -A nazwa_grantu -l walltime=12:00:00 job.sh
 +
</pre>
 +
 
 +
SLURM:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 job.sh
 +
</pre>
 +
 
 +
Partycja w parametrach SLURMa odpowiada nazwie kolejki, stosowanej w PBS. Jeżeli posiadamy odpowiednio ustawiony grant domyślny można skrócić wywołanie <tt>sbatch</tt> do:
 +
<pre>
 +
sbatch --time=12:00:00 job.sh
 +
</pre>
 +
gdyż <tt>plgrid</tt> 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:
 +
<pre>
 +
qsub -l mem=500mb job.sh
 +
</pre>
 +
Alternatywnie można podać ilość pamięci na każdy rdzeń za pomocą parametru pmem:
 +
<pre>
 +
qsub -l nodes=2:ppn=12,pmem=500mb job.sh
 +
</pre>
 +
 
 +
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):
 +
<pre>
 +
sbatch --mem=2gb job.sh
 +
</pre>
 +
 
 +
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:
 +
<pre>
 +
sbatch --mem-per-cpu=1gb job.sh
 +
</pre>
 +
 
 +
==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 <tt>-o nazwa_pliku.txt</tt> 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:
 +
<pre>
 +
qsub -q plgrid -A nazwa_grantu -l nodes=1:ppn=1 -l walltime=12:00:00 job.sh
 +
</pre>
 +
 
 +
SLURM:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu -N 1 -n 1 --time=12:00:00 job.sh
 +
</pre>
 +
 
 +
W obu przypadkach podawanie dokładnej liczby węzłów (<tt>-l nodes=1</tt>, <tt>-N</tt>) i procesów (<tt>-n</tt>) jest nadmiarowe, gdyż ich domyślne wartości wynoszą <tt>1</tt>. W przypadku SLURMa komenda bez nadmiarowych argumentów wygląda następująco:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 job.sh
 +
</pre>
 +
 
 +
==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:
 +
<pre>
 +
qsub -q plgrid -A nazwa_grantu -l nodes=1:ppn=12 -l walltime=12:00:00 job.sh
 +
</pre>
 +
 
 +
SLURM:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 1 -n 1 --cpus-per-task=12 job.sh
 +
</pre>
 +
 
 +
Warto zwrócić uwagę, że parametry oznaczające liczbę węzłów (<tt>-N</tt>) i procesów (<tt>-n</tt>) są nadmiarowe, gdyż ich domyślne wartości wynoszą <tt>1</tt>. W przypadku SLURMa komenda bez nadmiarowych argumentów wygląda następująco:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 --cpus-per-task=12 job.sh
 +
</pre>
 +
 
 +
==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:
 +
<pre>
 +
qsub -q plgrid -A nazwa_grantu -l nodes=2:ppn=12 -l walltime=12:00:00 job.sh
 +
 
 +
w samym skrypcie:
 +
mpiexec applikacja.mpi
 +
</pre>
 +
 
 +
SLURM:
 +
<pre>
 +
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
 +
</pre>
 +
 
 +
Kluczowym parametrem jest <tt>-n</tt> 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:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 --ntasks-per-node=12 job.sh
 +
</pre>
 +
 
 +
analogicznie można pozostawić do wyliczenia ilość procesów per węzeł:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 -n 24 job.sh
 +
</pre>
 +
 
 +
Możliwe jest też pominięcie parametru <tt>-N</tt> 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 <tt>mpiexec</tt> (w postaci zależnej od wykorzystywanej biblioteki OpenMP) tak aby każdy proces wiedział, że ma uruchomić po 6 wątków.
 +
 
 +
PBS:
 +
<pre>
 +
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
 +
</pre>
 +
 
 +
SLURM:
 +
<pre>
 +
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
 +
</pre>
 +
 
 +
Warto zwrócić uwagę, że nie ma konieczności podawania parametru <tt>-n</tt> przy <tt>mpiexec</tt>, 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:
 +
<pre>
 +
sbatch -p plgrid -A nazwa_grantu --time=12:00:00 -N 2 --ntasks-per-node=2 --cpus-per-task=6 job.sh
 +
</pre>
 +
 
 +
=Najważniejsze zmienne systemowe=
 
{| class="wikitable"
 
{| class="wikitable"
 
! width=50% |Zmienna SLURM    !!width=50%|Zmienna PBS
 
! width=50% |Zmienna SLURM    !!width=50%|Zmienna PBS
Linia 43: Linia 183:
 
|-
 
|-
 
| <tt>SLURM_NTASKS</tt>|| brak odpowiednika
 
| <tt>SLURM_NTASKS</tt>|| brak odpowiednika
 +
|-
 
| brak odpowiednika || <tt>PBS_NP</tt>
 
| brak odpowiednika || <tt>PBS_NP</tt>
 
|-
 
|-
Linia 51: Linia 192:
  
 
Wartość <tt>PBS_NP</tt> możemy wyliczyć za pomocą <tt>SLURM_NTASKS</tt> * <tt>SLURM_CPUS_PER_TASK</tt> przy założeniu, że zadanie posiada więcej niż 1 rdzeń per proces. W innym przypadku <tt>PBS_NP</tt> jest równe <tt>SLURM_NTASKS</tt>.
 
Wartość <tt>PBS_NP</tt> możemy wyliczyć za pomocą <tt>SLURM_NTASKS</tt> * <tt>SLURM_CPUS_PER_TASK</tt> przy założeniu, że zadanie posiada więcej niż 1 rdzeń per proces. W innym przypadku <tt>PBS_NP</tt> jest równe <tt>SLURM_NTASKS</tt>.
−
 
−
===Najważniejsze komendy===
 
−
{| class="wikitable"
 
−
! width=50% |Komenda SLURM    !!width=50%|Komenda PBS
 
−
|-
 
−
| <tt>sbatch</tt> ||<tt>qsub</tt>
 
−
|-
 
−
| <tt>squeue</tt>|| <tt>qstat</tt>
 
−
|-
 
−
| <tt>scancel</tt> || <tt>qdel</tt>
 
−
|}
 

Aktualna wersja na dzień 14:06, 11 gru 2017


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.

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.

Źródło: „https://kdm.cyfronet.pl/mediawiki/index.php?title=Podstawy:SLURM_vs_PBS&oldid=2088”