Prometheus:Podstawy: Różnice pomiędzy wersjami

Z Komputery Dużej Mocy w ACK CYFRONET AGH
Skocz do:nawigacja, szukaj
(→‎Partycje: Dodatnie partycji plgrid)
m
 
(Nie pokazano 96 wersji utworzonych przez 6 użytkowników)
Linia 1: Linia 1:
−
__NOTITLE__
+
== Logowanie ==
  
−
== Logowanie ==
+
Dostęp do klastra Prometheus realizowany jest za pośrednictwem maszyn dostępowych:
 +
<pre>
 +
prometheus.cyfronet.pl (alias na jedną z poniższych maszyn):
 +
 
 +
login01.prometheus.cyfronet.pl
 +
login02.prometheus.cyfronet.pl
 +
</pre>
 +
 
 +
np.
 +
 
 +
<pre>
 +
ssh <plgtestowy>@prometheus.cyfronet.pl
 +
</pre>
  
−
Dostęp do klastra Prometheus realizowany jest za pośrednictwem maszyny dostępowej:
+
Możliwe jest także użycie krótszej domeny '''pro.cyfronet.pl'''.
−
<code>
 
−
login01.pro.cyfronet.pl
 
−
</code>
 
−
Możliwe jest także użycie dłuższego aliasu '''login01.prometheus.cyfronet.pl''' (a także, zamiast '''cyfronet.pl''', domeny '''cyf-kr.edu.pl''').
 
  
 
Logowanie na maszynę dostępową możliwe jest poprzez SSH.
 
Logowanie na maszynę dostępową możliwe jest poprzez SSH.
 +
Odciski palca (tzw. fingeprint) kluczy:
 +
<pre>
 +
(ECDSA)  SHA256:tKk4RpOzWSTf+H8oN7COX1o5xMGSX7vMk956oHcdSB8
 +
(ED25519) SHA256:roerSF6HBUEqJpoPk36BXwz7NsPRIrTguoApYoYK+ro
 +
(RSA)    SHA256:v/iUvEh8faHN7IoZ5Vpm0kU6OYKXkGyWp9O9ZFkbeDw
 +
 +
(ECDSA)  MD5:16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd
 +
(ED25519) MD5:33:4e:15:cf:71:07:b3:6d:62:0e:b3:7a:9e:7c:7e:13
 +
(RSA)    MD5:f0:ea:1e:85:79:e0:29:f7:de:64:7a:df:ed:c4:f4:fa
 +
</pre>
  
−
Aktualnie logowanie jest ograniczone i możliwe jedynie pośrednio z maszyny dostępowej [[Zeus:Podstawy#Nazwa maszyny dostępowej|Zeusa]].
+
Proszę upewnić się, że został przedstawiony poprawny odcisk klucza.
  
 
== Dostępne oprogramowanie ==
 
== Dostępne oprogramowanie ==
Linia 17: Linia 35:
 
Opis dostępnego oprogramowania znajduje się [[Oprogramowanie|tutaj]].
 
Opis dostępnego oprogramowania znajduje się [[Oprogramowanie|tutaj]].
  
−
Dostęp do oprogramowania realizoway jest za pomocą narzędzia [[Prometheus:Lmod|Lmod]].  
+
Dostęp do oprogramowania realizowany jest za pomocą narzędzia [[Prometheus:Lmod|Lmod]].
  
 
== Partycje ==
 
== Partycje ==
  
−
Odpowiednikiem kolejek PBS dla systemu SLURM są partycje. Prometheus posiada aktualnie następujące partycje:
+
Odpowiednikiem kolejek PBS dla systemu SLURM są partycje. Prometheus posiada aktualnie następujące partycje dostępne dla użytkowników:
  
 
{| class="wikitable"  style="text-align:center;"
 
{| class="wikitable"  style="text-align:center;"
−
! Nazwa partycji !! Zasoby !! Informacje
+
! Nazwa partycji !! Maksymalny czas<br/> trwania zadania !! Informacje
 
|-
 
|-
−
| red || 576 węzłów (13824 CPU) || Partycja domyślna, pierwsza wyspa
+
| '''plgrid''' || 72:00:00 || Partycja domyślna
 
|-
 
|-
−
| green || 576 węzłów (13824 CPU) || Druga wyspa
+
| '''plgrid-testing''' || 1:00:00 || Partycja dla zadań testowych i do przygotowywania obliczeń (np. budowanie aplikacji, kopiowanie plików), maksymalnie 10 zadań użytkownika w kolejce, w tym 3 działające
 
|-
 
|-
−
| blue || 576 węzłów (13824 CPU) || Trzecia wyspa
+
| '''plgrid-now''' || 12:00:00 || Polecana dla zadań interaktywnych, partycja dla zadań testowych i do przygotowywania obliczeń (np. budowanie aplikacji, kopiowanie plików), maksymalnie 1 zadanie użytkownika działające, maksymalnie jeden serwer i 24 rdzenie, bez dostępu do serwerów z GPU
 
|-
 
|-
−
| '''plgrid''' || 288 węzłów (6912 CPU) || Partycja dla infrastruktury PL-Grid '''(aktualnie jedyna dostępna dla użytkowników)'''
+
| '''plgrid-short''' || 1:00:00 || Partycja dla krótkich zadań (walltime do 1h); zwiększa prawdopodobieństwo szybszego uruchomienia zadania
 
|-
 
|-
−
| all || 1728 węzłów (41472 CPU) || Zbiór wszystkich węzłów Prometheusa
+
| '''plgrid-long''' || 168:00:00 || Partycja dla zadań o wydłużonym walltime (negocjowana w grancie)
 +
|-
 +
| '''plgrid-large''' || 24:00:00 || Partycja dla zadań wymagających co najmniej 432 rdzeni (18 serwerów); zawiera dodatkowe zasoby niedostępne dla partycji '''plgrid'''
 +
|-
 +
| '''plgrid-gpu''' || 72:00:00 || Partycja dla zadań wykorzystujących karty GPGPU (dostęp negocjowana w grancie)
 +
|-
 +
| '''plgrid-gpu-v100''' || 24:00:00 || Partycja dla zadań wykorzystujących karty GPGPU Nivdia V100, dedykowana dla ML/AI (dostęp negocjowany w grancie)
 +
|-
 +
 
 
|}
 
|}
  
Linia 44: Linia 70:
  
 
'''Uwagi:'''
 
'''Uwagi:'''
−
* Aktualnie dla użytkowników udostępniona jest wyłącznie partycja '''plgrid'''
+
* Wybór odpowiedniej partycji oraz określenie przybliżonego czasu trwania zadania znacząco zwiększa prawdopodobieństwo szybkiego uruchomienia obliczeń. Zalecane jest, aby zlecać zadanie do kolejki, której maksymalny czas trwania zadania jest jak najkrótszy (np. '''plgrid-short''' jeśli jest to możliwe).
−
* Zadania nieprzekraczające rozmiaru wyspy obliczeniowej powinny być uruchamiane w ramach partycji wyspy. Zlecanie obliczeń w partycji <tt> all </tt> powoduje potencjalne rozbicie zadania pomiędzy wyspami obliczeniowymi, co skutkuje obniżeniem efektywności obliczeń.
+
* Brak wyboru partycji skutkuje ustawieniem partycji domyślnej, którą jest partycja '''plgrid'''.
 +
* Zadania zlecane do partycji '''plgrid''' (lub te dla których partycja nie została określona) mogą zostać automatycznie przeniesione przez system kolejkowy do partycji '''plgrid-large''' lub '''plgrid-short''' jeśli taka zmiana może wpłynąć na ich szybsze uruchomienie.
 +
* Aktualnie dla wszystkich użytkowników udostępnione są partycje '''plgrid''', '''plgrid-testing''', '''plgrid-short''' oraz '''plgrid-large'''. Dostęp do pozostałych partycji przyznawany jest na podstawie grantu właściwego i rozpatrywany jest indywidualnie dla każdego grantu.
 +
* Aby otrzymać dostęp do partycji '''plgrid-long''', należy to wyraźnie zaznaczyć we wniosku o grant właściwy.
 +
* Dostęp do partycji '''plgrid-gpu''' wymaga zawnioskowania o oddzielny grant przeznaczony w całości wyłącznie na obliczenia z wykorzystaniem GPGPU.
 +
* Partycja '''plgrid-testing''' nie powinna być używana do dużych obliczeń, a wyłącznie do testów i innych operacji (np. budowanie aplikacji, kopiowanie danych w trybie interaktywnym)
 +
 
 +
== Zasoby dyskowe ==
 +
 
 +
{| class="wikitable" style="text-align:center;"
 +
! Lokalizacja !! Limit danych !! Limit liczby plików !! Przeznaczenie !! Sposób<br/>dostępu !! Przepustowość !! Pojemność !! Kopia<br/> bezpieczeństwa !! '''Możliwość wykonywania intensywnych<br/> zapisów i/lub odczytów''' !! Dostęp !! Uwagi
 +
|-
 +
|<tt>$HOME</tt> || 40 GB || 1 000 000 || [[Podstawy#Katalogi_domowe|katalog domowy użytkownika]] || NFS || 1 GB/s || ∞ ||tak || nie || globalnie ||
 +
|-
 +
|<tt>$SCRATCH</tt> || 100 TB || 1 000 000 || [[Podstawy#Przestrzeń tymczasowa|przestrzeń dla plików tymczasowych zadań]] || Lustre || 120 GB/s || 5 PB || nie || tak || globalnie || dane starsze niż '''30 dni'''<br/>będą usuwane automatycznie
 +
|-
 +
| <tt>$PLG_GROUPS_STORAGE/<nazwa_zespołu></tt>  ||colspan="2"| suma grantów || przestrzeń dla katalogów zespołów (PL-Grid) || Lustre || 30 GB/s || 2,5 PB || nie || nie || globalnie ||
 +
|-
 +
|<tt>$SCRATCH_LOCAL</tt> || 768 GB || ∞ || [[Podstawy#Lokalna_przestrze.C5.84_typu_scratch|lokalna przestrzeń typu scratch]] || Lustre || 120 GB/s || - ||nie || tak || lokalnie<br/>na węźle obl. || niedostępne po<br/>zakończeniu zadania,<br/>wymagana opcja '''-C localfs'''
 +
|}
 +
 
 +
=== Zmienne środowiskowe ===
 +
 
 +
Osobiste:
 +
* $HOME, $PLG_USER_STORAGE, np. '/people/plgtestowy' - wskazuje na katalog domowy
 +
* $PLG_USER_SCRATCH_SHARED, $SCRATCH np. '/net/scratch/people/plgtestowy/' - scratch dla użytkownika - '''tu należy trzymać dane podczas obliczeń'''
 +
 
 +
Zespołowe (do nich należy dodać nazwę zespołu):
 +
* PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, np. '/net/archive/groups' - wskazuje na katalog do składowania danych zespołów (dane wejściowe, wyjściowe, wymiana danych pomiędzy osobami)
 +
 
 +
=== Lokalna przestrzeń typu scratch ===
 +
 
 +
Dla obliczeń generujących bardzo dużą ilość operacji na metadanych (open/close/create/remove) możliwe jest wykorzystanie dedykowanego zasobu dyskowego typu scratch, tworzonego specjalnie na potrzeby zadania. Aby tego dokonać, podczas zlecania zadania (w momencie alokacji zasobów, tj. zanim otrzymamy numer zadania) należy podać parametr <code>-C localfs</code>.
 +
Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa:
 +
<code>#SBATCH -C localfs</code>
 +
 
 +
Tak zlecone zadanie będzie miało do dyspozycji nowy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową '''$SCRATCH_LOCAL''' (w formacie /localfs/<numer_zadania>). Przestrzeń '''$SCRATCH_LOCAL''' przystosowana jest szczególnie dla obliczeń na małych plikach. Każdy z węzłów zadania posiada oddzielną przestrzeń '''$SCRATCH_LOCAL''' dostępną wyłącznie na czas działania zadania.
 +
 
 +
Każdorazowo rozmiar zasobu '''$SCRATCH_LOCAL''' wynosi 768 GiB na każdy zaalokowany na potrzeby zadania węzeł obliczeniowy.
 +
Prosimy o kontakt w przypadku, gdyby taka wartość okazała się niewystarczająca.
 +
 
 +
'''Uwaga:''' Katalog '''$SCRATCH_LOCAL''' dostępny jest wyłącznie na węzłach obliczeniowych zaalokowanych dla zadania i tylko na czas jego trwania. Co więcej, nie jest on współdzielony między węzłami (każdy węzeł posiada osobną przestrzeń). Po zakończeniu zadania użytkownik traci dostęp do zasobu. Jeśli dane tam przechowywane są istotne, to przed zakończeniem obliczeń powinny zostać one kopiowane do katalogu grupy ($PLG_GROUPS_STORAGE/<nazwa_zespołu>) lub ewentualnie do katalogu domowego użytkownika ($HOME).
 +
 
 +
=== Przestrzeń dyskowa w pamięci operacyjnej MEMFS  ===
 +
 
 +
W celu wykorzystania pamięci RAM do przechowywania plików tymczasowych należy  dodatkowo wyspecyfikować parametr "-C memfs” przy zlecaniu zadania.
 +
Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa:
 +
<code>#SBATCH -C memfs</code>
 +
 
 +
Po uruchomieniu zadania owy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową '''$MEMFS'''. Należy pamiętać, że pamięć wykorzystywana przy zapisie na MEMFS jest liczona do pamięci zarezerwowanej dla zadania a zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".
 +
 
 +
'''Uwaga:''' Przy wykorzystaniu pamięci operacyjnej jako zasobu dyskowego MEMFS należy pamiętać, że:
 +
* metodę tą można stosować tylko dla zadań jednowęzłowych
 +
* należy pamiętać, że zużycie pamięci przez zadanie łącznie z pamięcią wykorzystywną w MEMFS nie może przekraczać pamięci zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".
 +
* metodę tą można stosować jedynie gdy całościowe zapotrzebowania zadania na dyski oraz pamięć nie przekracza całości dostępnej pamięci węzła (dla normalnych węzłów Prometheusa 120GB)
 +
* najlepiej przeprowadzać obliczenia w trybie pełnowęzłowym.
  
 
== Uruchamianie zadań ==
 
== Uruchamianie zadań ==
Linia 52: Linia 133:
  
 
Zadanie może być zlecone zarówno w trybie wsadowym jak i w trybie interaktywnym.
 
Zadanie może być zlecone zarówno w trybie wsadowym jak i w trybie interaktywnym.
 +
 +
'''<span style="color: crimson">Przed uruchomieniem zadań zapoznaj się z informacjami o [[System_Grant%C3%B3w|systemie grantów]]</span>'''
 +
 
=== Tryb wsadowy ===
 
=== Tryb wsadowy ===
  
 
Do zlecania zadania w trybie wsadowym służy komenda <tt>sbatch</tt>.
 
Do zlecania zadania w trybie wsadowym służy komenda <tt>sbatch</tt>.
 
Użycie komendy:
 
Użycie komendy:
−
<code>sbatch skrypt.sh</code>
+
<code>sbatch skrypt.sh</code>.<br/>
 +
Wszystkie opcje należy poprzedzić dyrektywą '''#SBATCH''' (koniecznie ze znakiem #).<br/>
 +
Szczegółowe informacje: <code>man sbatch</code> oraz <code>sbatch --help</code>.
  
 
'''Przykładowy skrypt:'''
 
'''Przykładowy skrypt:'''
  
−
---
+
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
−
<code>
+
 
 
<syntaxhighlight lang="bash">
 
<syntaxhighlight lang="bash">
−
#!/bin/bash -l
+
#!/bin/bash
 
## Nazwa zlecenia
 
## Nazwa zlecenia
 
#SBATCH -J ADFtestjob
 
#SBATCH -J ADFtestjob
−
## Liczba węzłów
+
## Liczba alokowanych węzłów
 +
#SBATCH -N 1
 +
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
 +
#SBATCH --ntasks-per-node=1
 +
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
 +
#SBATCH --mem-per-cpu=1GB
 +
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
 +
#SBATCH --time=01:00:00
 +
## Nazwa grantu do rozliczenia zużycia zasobów
 +
#SBATCH -A <grant_id>
 +
## Specyfikacja partycji
 +
#SBATCH -p plgrid-testing
 +
## Plik ze standardowym wyjściem
 +
#SBATCH --output="output.out"
 +
## Plik ze standardowym wyjściem błędów
 +
#SBATCH --error="error.err"
 +
 
 +
 
 +
## przejscie do katalogu z ktorego wywolany zostal sbatch
 +
cd $SLURM_SUBMIT_DIR
 +
 
 +
srun /bin/hostname
 +
module load plgrid/apps/adf/2014.07
 +
adf input.adf
 +
 
 +
</syntaxhighlight>
 +
 
 +
==== Zadania wykorzystujące MPI ====
 +
 
 +
Uruchamianie zadań MPI na Prometheuszu wygląda podobnie jak uruchamianie takich zadań na innych klastrach wyposażonych w system kolejkowy SLURM integrujący się z bibliotekami MPI. W przypadku Prometheusa dostępne są różne wersje bibliotek MPI (najczęściej OpenMPI i IntelMPI) dla większości dostępnych kompilatorów. Podczas uruchamiania aplikacji proszę nie podawać explicite parametru <code>-n</code> lub <code>-np</code> system dobierze odpowiednie wartości na podstawie parametrów alokacji (umieszczonych w skrypcie startowym) i zostaną one zastosowane. W uzasadnionych przypadkach, gdzie aplikacja wymaga specyficznej konfiguracji (np. lokalne wątkowanie), można podać wspomniane parametry.
 +
 
 +
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
 +
 
 +
<syntaxhighlight lang="bash">
 +
#!/bin/bash
 +
## Nazwa zlecenia
 +
#SBATCH -J MPITest
 +
## Liczba alokowanych węzłów
 
#SBATCH -N 2
 
#SBATCH -N 2
−
## Maksymalna liczba zadań w zleceniu (domyślnie ilość rdzeni)
+
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
−
#SBATCH -n 48
 
−
## Ilość zadań na węzeł
 
 
#SBATCH --ntasks-per-node=24
 
#SBATCH --ntasks-per-node=24
−
## Maksymalna ilość zużytej pamięci na węzeł (w MB)
+
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
−
#SBATCH --mem 24000
+
#SBATCH --mem-per-cpu=5GB
−
## Maksymalny czas trwania zlecenia
+
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
−
#SBATCH --time=20:00:00  
+
#SBATCH --time=01:00:00  
 
## Nazwa grantu do rozliczenia zużycia zasobów
 
## Nazwa grantu do rozliczenia zużycia zasobów
−
#SBATCH -A testgrant
+
#SBATCH -A <grant_id>
 
## Specyfikacja partycji
 
## Specyfikacja partycji
−
#SBATCH -p blue
+
#SBATCH -p plgrid-testing
 
## Plik ze standardowym wyjściem
 
## Plik ze standardowym wyjściem
−
#SBATCH --output="adf.out"
+
#SBATCH --output="output.out"
 
## Plik ze standardowym wyjściem błędów
 
## Plik ze standardowym wyjściem błędów
−
#SBATCH --error="adf.err"
+
#SBATCH --error="error.err"
−
## Typ powiadomień e-mail
+
 
−
#SBATCH --mail-type=ALL
+
srun /bin/hostname
−
## E-mail na który wysłać powiadomienia
+
 
−
#SBATCH --mail-user=user@example.com
+
## Zaladowanie modulu IntelMPI
 +
module add plgrid/tools/impi
  
 
## przejscie do katalogu z ktorego wywolany zostal sbatch
 
## przejscie do katalogu z ktorego wywolany zostal sbatch
 
cd $SLURM_SUBMIT_DIR
 
cd $SLURM_SUBMIT_DIR
  
−
srun /bin/hostname
+
mpiexec ./calcDiff 100 50
−
module load apps/adf/2014.07
+
</syntaxhighlight>
−
adf input.adf
+
 
 +
Dobrą praktyką jest kompilowanie i uruchamianie aplikacji przy pomocy środowiska budowanego tym samym zestawem modułów. Zalecamy korzystanie z wrappera <code>mpiexec</code>. Wielkość alokacji, w tym przypadku 2 węzły po 24 rdzenie, przekłada się bezpośrednio na 48 tasków dostępnych dla aplikacji korzystającej z MPI. Dopuszczalne jest uruchomienie serii aplikacji MPI w jednym skrypcie, ale najczęściej, ze względu na długi czas wykonania, nie jest to optymalny sposób prowadzenia obliczeń. Niedopuszczalne jest jednoczesne uruchomienie wielu aplikacji MPI w ramach jednej alokacji, taka praktyka prowadzi do kłopotówzwiązanych z alokacją zasobów na wyłączność dla danej aplikacji.
 +
 
 +
==== Proste zrównoleglenie wielu niezależnych zadań ====
 +
 
 +
Dość częstym przypadkiem użycia klastra jest przetworzenie wielu paczek danych, gdzie każda paczka jest przetwarzana niezależnie. Dobrym przykładem takich zadań jest przetwarzanie wielu obrazów w ten sam sposób. SLURM umożliwia proste zrównoleglenie takiego przetwarzania poprzez użycie komendy '''srun'''. Przykładowy skrypt, który zrównolegli uruchomienie wielu instancji obliczeń, gdzie stopień równoległości jest ustalany na podstawie parametrów zadania, znajduje się poniżej:
 +
 
 +
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
 +
 
 +
<syntaxhighlight lang="bash">
 +
#!/bin/bash
 +
## Nazwa zlecenia
 +
#SBATCH -J testjob
 +
## Liczba alokowanych węzłów
 +
#SBATCH -N 2
 +
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
 +
#SBATCH --ntasks-per-node=24
 +
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
 +
#SBATCH --mem-per-cpu=5GB
 +
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
 +
#SBATCH --time=01:00:00
 +
## Nazwa grantu do rozliczenia zużycia zasobów
 +
#SBATCH -A <grant_id>
 +
## Specyfikacja partycji
 +
#SBATCH -p plgrid-testing
 +
## Plik ze standardowym wyjściem
 +
#SBATCH --output="output.out"
 +
## Plik ze standardowym wyjściem błędów
 +
#SBATCH --error="error.err"
 +
 
 +
module load plgrid/tools/imagemagick
 +
 
 +
## przejscie do katalogu z ktorego wywolany zostal sbatch
 +
cd $SLURM_SUBMIT_DIR
  
 +
ls *.tif | xargs -t -d "\n" -P ${SLURM_NTASKS} -n 1 srun -n 1 -N 1 --mem=5gb mogrify -format png
 
</syntaxhighlight>
 
</syntaxhighlight>
−
</code>
+
 
−
---
+
Powyższy skrypt dla każdego pliku *tif w katalogu uruchomi aplikację <code>mogrify</code>, tak aby skonwertować obraz do pliku png. Pierwszą czynnością jest wylistowanie plików wejściowych, następnie wynik jest przekazywany do komendy <code>xargs</code>, która przez parametr '''-P''' zapewnia równoległe uruchomienie dalszego polecania <code>srun</code>. Do każdej instancji <code>srun</code> zostanie przekazany jeden parametr, maksymalna równoległość wyniesie '''${SLURM_NTASKS}'''. Każdy <code>srun</code> uruchomi aplikację <code>mogrify</code> na jednym rdzeniu z przydzielonym 5GB pamięci.
  
 
=== Tryb interaktywny ===
 
=== Tryb interaktywny ===
  
 
Do zlecania zadań w trybie interaktywnym z powłoką służy komenda (przykład):
 
Do zlecania zadań w trybie interaktywnym z powłoką służy komenda (przykład):
−
<code>srun -p partycja -N 2 -n 48 -A testgrant --pty /bin/bash -l</code>
+
<code>srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l</code>
 +
Powyższa komenda uruchomi zadanie w partycji plgrid-testing na 1 węźle z alokacją 1 rdzenia.
  
 
Samo polecenie <tt>srun</tt> odpowiada za uruchomienie komendy w ramach zaalokowanych zasobów.<br>
 
Samo polecenie <tt>srun</tt> odpowiada za uruchomienie komendy w ramach zaalokowanych zasobów.<br>
−
Jednak w przypadku, gdy zasoby nie zostały wcześniej zaalokowane, komenda ta dodatkowo dokonuje ich rezerwacji przed uruchomieniem obliczeń.
+
Jednak w przypadku, gdy zasoby nie zostały wcześniej zaalokowane, komenda ta uprzednio dokonuje ich rezerwacji tuż przed uruchomieniem obliczeń.
 +
 
 +
=== Zadania tablicowe ===
 +
 
 +
Zadania tablicowe to mechanizm pozwalający na zlecanie dużej ilości zadań wsadowych, które są do siebie podobne. Zadania tablicowe posiadają swój indeks, dostępny jako zmienną środowiskowa '''$SLURM_ARRAY_TASK_ID''' wewnątrz zadania, dzięki któremu można odpowiednio parametryzować uruchamianą aplikację. Sposób zlecania zadania jest analogiczny jak w przypadku zwykłych zadań wsadowych, a przykładowy skrypt zawierający parametr <code>--array</code> <code>-a</code>, definiujący zakres indeksów, wygląda następująco:
 +
 
 +
'''<span style="color: crimson">UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp.</span>'''
 +
 
 +
<syntaxhighlight lang="bash">
 +
#!/bin/bash
 +
## Nazwa zlecenia
 +
#SBATCH -J testjob
 +
## Liczba alokowanych węzłów
 +
#SBATCH -N 1
 +
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
 +
#SBATCH --ntasks-per-node=1
 +
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
 +
#SBATCH --mem-per-cpu=1GB
 +
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
 +
#SBATCH --time=01:00:00
 +
## Nazwa grantu do rozliczenia zużycia zasobów
 +
#SBATCH -A <grant_id>
 +
## Specyfikacja partycji
 +
#SBATCH -p plgrid-testing
 +
## Plik ze standardowym wyjściem
 +
#SBATCH --output="output.out"
 +
## Plik ze standardowym wyjściem błędów
 +
#SBATCH --error="error.err"
 +
## Parametr wyznaczający indeksy zadania tablicowego
 +
#SBATCH --array=0-100
 +
 
 +
## przejscie do katalogu z ktorego wywolany zostal sbatch
 +
cd $SLURM_SUBMIT_DIR
 +
 
 +
myCalculations $SLURM_ARRAY_TASK_ID
 +
 
 +
</syntaxhighlight>
 +
 
 +
=== Zadania wykorzystujące GPGPU ===
 +
 
 +
==== Dostęp do węzłów z GPGPU ====
 +
 
 +
Dla zadań korzystających w obliczeniach z kart GPGPU przeznaczona została specjalna partycja -  '''plgrid-gpu'''.
 +
Aby móc przeprowadzać obliczenia z wykorzystaniem GPGPU konieczne jest złożenie wniosku o grant właściwy, który przeznaczony zostanie w całości wyłącznie na obliczenia z wykorzystaniem kart GPGPU. Grant taki nie powinien być używany do przeprowadzania obliczeń w partycjach innych niż '''plgrid-gpu'''.
 +
We wniosku o grant należy wyraźnie zaznaczyć, że wymagany jest dostęp do partycji '''plgrid-gpu'''. Zalecane jest także (ale nie jest to konieczne), aby grant taki posiadał w nazwie wyraz '''gpu''' (np. obliczeniagpu) - ułatwia to identyfikację grantów.
 +
Każdy wniosek o dostęp do partycji '''plgrid-gpu''' jest rozpatrywany indywidualnie przez dostawcę zasobów.
 +
 
 +
==== Informacje ogólne ====
 +
 
 +
Karty GPU w systemie kolejkowym SLURM są rodzajem tzw. generic resources (GRES), a ich identyfikatorem jest "gpu".<br/>
 +
Informację o tym na których węzłach/partycjach znajdują się karty GPU można otrzymać np. przy pomocy komendy <tt>sinfo</tt>:
 +
 
 +
<code>sinfo -o '%P || %N || %G'</code>
 +
 
 +
Zlecanie zadań odbywa się poprzez podanie opcji <code>--partition=plgrid-gpu --gres=gpu[:count]</code> systemu kolejkowego.<br/>
 +
W przypadku gdy nie ma podanej opcji <tt>count</tt>, system kolejkowy domyślnie alokuje jedną kartę na węźle obliczeniowym.
 +
 
 +
Po zleceniu zadania system kolejkowy automatycznie ustawia zmienną środowiskową <tt>$CUDA_VISIBLE_DEVICES</tt> oraz zezwala na dostęp do zaalokowanych do kart.
 +
 
 +
==== Zadania interaktywne ====
 +
 
 +
Przykładowo, gdy chcemy uruchomić zadanie interaktywne na jednym serwerze i zażądać 2 kart GPU:
 +
 
 +
<code>srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l</code>
 +
 
 +
==== Zadania interaktywne MPI ====
 +
 
 +
Uwaga! Wyjątkiem jest uruchamianie interaktywnych aplikacji MPI (np. w celach testów). Z powodu nieco innej obsługi kart GPU niż zwykłych procesorów przez system SLURM, uruchomienie zadania interaktywnego wymaga niestandardowej procedury.
 +
 
 +
Przykładowo, gdy chcemy uruchomić zadanie interaktywne na dwóch serwerach i zażądać 2 kart GPU na każdym z nich (łącznie 4 karty GPU) na czas 1 godziny:
 +
 
 +
<code>salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00</code>
 +
 
 +
Polecenie salloc zaalokowało nasze zadanie i zwróciło jego numer, przykładowo 1234.
 +
 
 +
Następnie uruchamiamy srun wymagając 0 kart GPU w zadaniu o numerze zwróconym przez salloc:
 +
 
 +
<code>srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l</code>
 +
 
 +
Otrzymaliśmy dostęp do powłoki na jednym z węzłów, teraz po załadowaniu odpowiedniego modułu MPI można już uruchomić własną aplikację za pomocą mpirun lub mpiexec. Isotne jest aby podczas uruchamiania aplikacji nie przekazywać zmiennych środowiska, czyli w przypadku IntelMPI należy dodać parametr <code>-genvnone</code>Aplikacja będzie miała dostęp do wszystkich kart GPU zaalokowanych w komendzie salloc, niezależnie od wymagania gpu:0 użytego w srun.
 +
 
 +
Po zakończeniu testów należy usunąć alokację za pomocą:
 +
 
 +
<code>scancel 1234</code>
 +
 
 +
==== Zadania wsadowe ====
 +
 
 +
Dla skryptu wsadowego dodatkowe zmiany nie są potrzebne, przykładowo gdy żądamy po jednej karcie na węzeł obliczeniowy, wystarczy dopisać do skryptu:
 +
 
 +
<syntaxhighlight lang="bash">
 +
#SBATCH --partition=plgrid-gpu
 +
#SBATCH --gres=gpu
 +
</syntaxhighlight>
  
  
 
'''Uwaga:''' Wszelkie informacje na temat komend SLURMa można znaleźć w manualu, np.: <code> man sbatch</code>
 
'''Uwaga:''' Wszelkie informacje na temat komend SLURMa można znaleźć w manualu, np.: <code> man sbatch</code>
 +
 
== Monitorowanie kolejek, partycji, węzłów, zadań i zasobów ==
 
== Monitorowanie kolejek, partycji, węzłów, zadań i zasobów ==
  
−
*; lista aktualnie zakolejkowanych/uruchomionych zadań:
+
*; Sktypty specyficzne dla Prometheusa
−
: <code>squeue</code>
+
** '''[[Prometheus:pro-jobs|pro-jobs]]''' - statystyki dla zakolejkowanych lub już uruchomionych zadań użytkownika
−
*; właściwości partycji:
+
** '''[[Prometheus:pro-jobs-history|pro-jobs-history]]''' - statystyki dla zakończonych zadań użytkownika
−
: <code>scontrol show partition [<nazwa_partycji>]</code>
+
** '''[[Prometheus:pro-fs|pro-fs]]''' - statystyki użycia zasobów dyskowych przez użytkownika
−
*; lista węzłów:
+
** '''[[Prometheus:pro-groupdir-fix|pro-groupdir-fix]]''' - korekcja uprawnień danych w katalogu zespołu
−
: <code>sinfo</code>
+
** '''pro-grant-jobs''' - lista zadań w ramach grantów użytkownika (zawiera także zadania innych członków grup grantowych użytkownika)
−
*; właściwości węzła:
+
 
−
: <code>scontrol show node [<nazwa_węzła>]</code>
+
 
−
*; szczegóły zadania:
+
*; Narzędzia systemu SLURM
−
: <code>scontrol show job [<ID_zadania>]</code>
+
**<code>squeue</code> - lista aktualnie zakolejkowanych/uruchomionych zadań (użytkownik widzi zadania z grantów do niego należących, w celu wyświetlenia tylko swoich zadań należy podać opcję -u, tj. <code>squeue -u $USER</code>)
−
*; zużycie zasobów w ramach kroków (step) działającego zadania:
+
**<code>scontrol show job [<ID_zadania>]</code> - szczegóły zadania
−
: <code>sstat -a -j ID_zadania/ID_zadania.batch</code>
+
**<code>sstat -a -j <ID_zadania>/<ID_zadania.batch></code> - zużycie zasobów w ramach kroków (step) działającego zadania
−
*; zużycie zasobów zakończonego już zadania/kroku:
+
**<code>scancel <ID_zadania></code> - usunięcie zadania (działającego lub zakolejkowanego)
−
: <code>sacct</code>
+
**<code>sacct</code> - zużycie zasobów zakończonego już zadania/kroku
 +
**<code>scontrol show partition [<nazwa_partycji>]</code> - właściwości partycji
 +
**<code>sinfo</code> - lista węzłów
 +
**<code>scontrol show node [<nazwa_węzła>]</code> - właściwości węzła
  
 
<!-- == Opis właściwości węzłów obliczeniowych == -->
 
<!-- == Opis właściwości węzłów obliczeniowych == -->
 
<!-- == Sposób korzystania z sieci Infiniband == -->
 
<!-- == Sposób korzystania z sieci Infiniband == -->
 +
 +
== Przenoszenie danych z klastra Zeus ==
 +
 +
Klastry Zeus i Prometheus nie współdzielą żadnych zasobów dyskowych, w związku z tym, aby korzystać z danych zgromadzonych na Zeusie, należy je najpierw skopiować. W tym celu możemy posłużyć się komendami:
 +
* <code>scp</code> - w przypadku małych plików (używa loginu i hasła),
 +
* <code>globus-url-copy</code> - w przypadku dużych plików (używa loginu i hasła LUB grid proxy),
 +
* <code>uberftp</code> - w przypadku dużych plików, interaktywnie (używa grid proxy).
 +
 +
 +
Podstawowe informacje o komendzie globus-url-copy:
 +
* składnia: <code>globus-url-copy ŻRÓDŁO CEL</code>, gdzie źródło i cel poprzedzone są nazwą protokołu: np. <code>file://</code>,
 +
* aby pobrać pliki z zeusa używamy 2 protokołów:
 +
** gsiftp - <code>gsiftp://zeus.cyfronet.pl/</code> - uwierzytelnianie za pomocą proxy (musimy najpierw stworzyć grid proxy komendą <code>grid-proxy-init</code>),
 +
** sshftp - <code>sshftp://zeus.cyfronet.pl/</code> - uwierzytelnianie hasłem PLGrid,
 +
* uwierzytelnianie proxy pozwala uruchamiać wiele transferów bez podawania hasła za każdym razem,
 +
* protokół docelowy to <code>file://</code> czyli plik/katalog lokalny,
 +
* dla ŻRÓDŁA i CELU musimy podać pełną ścieżkę pliku lub możemy użyć skrótu w postaci <code>~plgLOGIN</code> do naszego katalogu domowego,
 +
* dla CELU (czyli protokołu <code>file://</code>) możemy podać też zmienne środowiskowe np. <code>$PWD</code> - bieżący katalog,
 +
* w przypadku CELU gdy podamy nazwę pliku np. <code>$PWD/nazwa.txt</code>, plik zapisze się pod daną nazwą, a gdy podamy tylko katalog, to plik zapisze się pod taką samą nazwą jak źródłowy,
 +
* aby przesyłać całe katalogi, należy je najpierw spakować komendą <code>tar -czf archiwum.tar katalog</code>,
 +
* w przypadku gdy nasz login na klastrze Prometheus różni się od tego na klastrze Zeus możemy użyć wyłącznie protokołu "sshftp://" a do ŹRÓDŁA należy dodać login na klastrze Zeus np. <code>sshftp://MOJ_USERNAME@zeus.cyfronet.pl/</code>.
 +
 +
 +
Przykład użycia komendy <code>globus-url-copy</code>:
 +
* skopiuj z katalogu domowego użytkownika plgLOGIN na klastrze Zeus, do bieżącego katalogu plik "bigfile.txt" i nadaj mu tą samą nazwę:
 +
<pre>globus-url-copy sshftp://zeus.cyfronet.pl/~plgLOGIN/bigfile.txt file://$PWD/</pre>
 +
* skopiuj plik "/mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt" z klastara Zeus do bieżącego katalogu:
 +
<pre>globus-url-copy sshftp://zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/</pre>
 +
* j.w. ale z podanym loginem z klastra Zeus (domyślnie używany jest taki sam użytkownik na jakiego jesteśmy zalogowani)
 +
<pre>globus-url-copy sshftp://MOJ_USERNAME@zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/</pre>
 +
 +
 +
Odnośniki do dodatkowych pomocy/dokumentacji:
 +
* scp:
 +
** http://linux.die.net/man/1/scp
 +
* globus-url-copy:
 +
** http://linux.die.net/man/1/globus-url-copy
 +
** http://toolkit.globus.org/toolkit/docs/4.0/data/gridftp/rn01re01.html
 +
* uberftp:
 +
** http://linux.die.net/man/1/uberftp
 +
** https://twiki.opensciencegrid.org/bin/view/Documentation/StorageUberFtp
 +
* grid-proxy-init
 +
** http://linux.die.net/man/1/grid-proxy-init
 +
** http://toolkit.globus.org/toolkit/docs/4.0/security/prewsaa/rn01re05.html
 +
 
== Zasady obowiązujące na klastrze Prometheus ==
 
== Zasady obowiązujące na klastrze Prometheus ==
  
−
* obliczenia wykonywane na maszynie dostępowej będą usuwane bez ostrzeżenia
+
* Obliczenia wykonywane na maszynie dostępowej będą usuwane bez ostrzeżenia. Maszyna dostępowa powinna służyć wyłącznie do przygotowywania plików wejściowych obliczeń i do ich zlecania na klaster za pośrednictwem systemu kolejkowego. Kopiowanie dużych ilości danych również może w znacznym stopniu obciążać maszynę dostępową, dlatego też zaleca się, aby kopiowanie przeprowadzać na węźle obliczeniowym (w zadaniu interaktywnym, np. <code>srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l</code>). Podobnie jest z kompilacją programów - ją również należy wykonywać na węźle obliczeniowym, a nie bezpośrednio na maszynie dostępowej.
−
* obliczenia wykraczające poza zakres deklarowanego tematu badań zużywające znaczną część zasobów klastra będą usuwane bez ostrzeżenia
+
* Obliczenia wykraczające poza zakres deklarowanego tematu badań zużywające znaczną część zasobów klastra będą usuwane bez ostrzeżenia.
−
* W celu skompilowania programu proszę użyć polecenia: <code>srun -p all -n 1 --pty /bin/bash -l</code><br/>Polecenie to spowoduje zalogowanie użytkownika na węzeł obliczeniowy, tam proszę uruchomić kompilację programu
+
* Dane obliczeniowe należy składować i przetwarzać na systemie plików Lustre pod lokalizacją $SCRATCH.
 +
* W obliczeniach '''nie''' należy korzystać z katalogu /tmp, do przechowywania plików tymczasowych należy wykorzystywać katalogi znajdujące się pod zmiennymi $SCRATCH, $SCRATCHDIR lub $TMPDIR.
 +
* Na maszynie dostępowej ustawiony jest limit pamięciowy 6 GiB dla sumy wszystkich procesów danego użytkownika. Próba przekroczenia limitu powoduje automatyczne zabicie procesu próbującego przekroczyć ustalony limit.
 +
 
 +
== Kontakt ==
 +
Pomoc dla użytkowników [http://www.plgrid.pl PL-Grid]: [https://helpdesk.plgrid.pl/ Helpdesk PL-Grid] <br /> Kontakt z administratorami: [mailto:prometheus@cyfronet.pl prometheus@cyfronet.pl], +48 12 632 33 55 w. 603

Aktualna wersja na dzień 09:47, 7 cze 2023

Logowanie

Dostęp do klastra Prometheus realizowany jest za pośrednictwem maszyn dostępowych: 

prometheus.cyfronet.pl (alias na jedną z poniższych maszyn):

login01.prometheus.cyfronet.pl
login02.prometheus.cyfronet.pl

np. 

ssh <plgtestowy>@prometheus.cyfronet.pl

Możliwe jest także użycie krótszej domeny pro.cyfronet.pl.

Logowanie na maszynę dostępową możliwe jest poprzez SSH. Odciski palca (tzw. fingeprint) kluczy: 

 (ECDSA)   SHA256:tKk4RpOzWSTf+H8oN7COX1o5xMGSX7vMk956oHcdSB8
 (ED25519) SHA256:roerSF6HBUEqJpoPk36BXwz7NsPRIrTguoApYoYK+ro
 (RSA)     SHA256:v/iUvEh8faHN7IoZ5Vpm0kU6OYKXkGyWp9O9ZFkbeDw

 (ECDSA)   MD5:16:e5:7f:69:45:d0:0f:6c:49:8d:c0:99:0b:e1:e9:dd
 (ED25519) MD5:33:4e:15:cf:71:07:b3:6d:62:0e:b3:7a:9e:7c:7e:13
 (RSA)     MD5:f0:ea:1e:85:79:e0:29:f7:de:64:7a:df:ed:c4:f4:fa

Proszę upewnić się, że został przedstawiony poprawny odcisk klucza.

Dostępne oprogramowanie

Opis dostępnego oprogramowania znajduje się tutaj.

Dostęp do oprogramowania realizowany jest za pomocą narzędzia Lmod.

Partycje

Odpowiednikiem kolejek PBS dla systemu SLURM są partycje. Prometheus posiada aktualnie następujące partycje dostępne dla użytkowników:

Nazwa partycji Maksymalny czas
trwania zadania		 Informacje
plgrid 72:00:00 Partycja domyślna
plgrid-testing 1:00:00 Partycja dla zadań testowych i do przygotowywania obliczeń (np. budowanie aplikacji, kopiowanie plików), maksymalnie 10 zadań użytkownika w kolejce, w tym 3 działające
plgrid-now 12:00:00 Polecana dla zadań interaktywnych, partycja dla zadań testowych i do przygotowywania obliczeń (np. budowanie aplikacji, kopiowanie plików), maksymalnie 1 zadanie użytkownika działające, maksymalnie jeden serwer i 24 rdzenie, bez dostępu do serwerów z GPU
plgrid-short 1:00:00 Partycja dla krótkich zadań (walltime do 1h); zwiększa prawdopodobieństwo szybszego uruchomienia zadania
plgrid-long 168:00:00 Partycja dla zadań o wydłużonym walltime (negocjowana w grancie)
plgrid-large 24:00:00 Partycja dla zadań wymagających co najmniej 432 rdzeni (18 serwerów); zawiera dodatkowe zasoby niedostępne dla partycji plgrid
plgrid-gpu 72:00:00 Partycja dla zadań wykorzystujących karty GPGPU (dostęp negocjowana w grancie)
plgrid-gpu-v100 24:00:00 Partycja dla zadań wykorzystujących karty GPGPU Nivdia V100, dedykowana dla ML/AI (dostęp negocjowany w grancie)

Dokładne informacje na temat partycji można otrzymać przy pomocy polecenia

scontrol show partition [<nazwa_partycji>]

Uwagi:

  • Wybór odpowiedniej partycji oraz określenie przybliżonego czasu trwania zadania znacząco zwiększa prawdopodobieństwo szybkiego uruchomienia obliczeń. Zalecane jest, aby zlecać zadanie do kolejki, której maksymalny czas trwania zadania jest jak najkrótszy (np. plgrid-short jeśli jest to możliwe).
  • Brak wyboru partycji skutkuje ustawieniem partycji domyślnej, którą jest partycja plgrid.
  • Zadania zlecane do partycji plgrid (lub te dla których partycja nie została określona) mogą zostać automatycznie przeniesione przez system kolejkowy do partycji plgrid-large lub plgrid-short jeśli taka zmiana może wpłynąć na ich szybsze uruchomienie.
  • Aktualnie dla wszystkich użytkowników udostępnione są partycje plgrid, plgrid-testing, plgrid-short oraz plgrid-large. Dostęp do pozostałych partycji przyznawany jest na podstawie grantu właściwego i rozpatrywany jest indywidualnie dla każdego grantu.
  • Aby otrzymać dostęp do partycji plgrid-long, należy to wyraźnie zaznaczyć we wniosku o grant właściwy.
  • Dostęp do partycji plgrid-gpu wymaga zawnioskowania o oddzielny grant przeznaczony w całości wyłącznie na obliczenia z wykorzystaniem GPGPU.
  • Partycja plgrid-testing nie powinna być używana do dużych obliczeń, a wyłącznie do testów i innych operacji (np. budowanie aplikacji, kopiowanie danych w trybie interaktywnym)

Zasoby dyskowe

Lokalizacja Limit danych Limit liczby plików Przeznaczenie Sposób
dostępu		 Przepustowość Pojemność Kopia
bezpieczeństwa		 Możliwość wykonywania intensywnych
zapisów i/lub odczytów		 Dostęp Uwagi
$HOME 40 GB 1 000 000 katalog domowy użytkownika NFS 1 GB/s ∞ tak nie globalnie
$SCRATCH 100 TB 1 000 000 przestrzeń dla plików tymczasowych zadań Lustre 120 GB/s 5 PB nie tak globalnie dane starsze niż 30 dni
będą usuwane automatycznie
$PLG_GROUPS_STORAGE/<nazwa_zespołu> suma grantów przestrzeń dla katalogów zespołów (PL-Grid) Lustre 30 GB/s 2,5 PB nie nie globalnie
$SCRATCH_LOCAL 768 GB ∞ lokalna przestrzeń typu scratch Lustre 120 GB/s - nie tak lokalnie
na węźle obl.		 niedostępne po
zakończeniu zadania,
wymagana opcja -C localfs

Zmienne środowiskowe

Osobiste:

  • $HOME, $PLG_USER_STORAGE, np. '/people/plgtestowy' - wskazuje na katalog domowy
  • $PLG_USER_SCRATCH_SHARED, $SCRATCH np. '/net/scratch/people/plgtestowy/' - scratch dla użytkownika - tu należy trzymać dane podczas obliczeń

Zespołowe (do nich należy dodać nazwę zespołu):

  • PLG_GROUPS_STORAGE, PLG_GROUPS_SHARED, np. '/net/archive/groups' - wskazuje na katalog do składowania danych zespołów (dane wejściowe, wyjściowe, wymiana danych pomiędzy osobami)

Lokalna przestrzeń typu scratch

Dla obliczeń generujących bardzo dużą ilość operacji na metadanych (open/close/create/remove) możliwe jest wykorzystanie dedykowanego zasobu dyskowego typu scratch, tworzonego specjalnie na potrzeby zadania. Aby tego dokonać, podczas zlecania zadania (w momencie alokacji zasobów, tj. zanim otrzymamy numer zadania) należy podać parametr -C localfs. Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa: #SBATCH -C localfs

Tak zlecone zadanie będzie miało do dyspozycji nowy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową $SCRATCH_LOCAL (w formacie /localfs/<numer_zadania>). Przestrzeń $SCRATCH_LOCAL przystosowana jest szczególnie dla obliczeń na małych plikach. Każdy z węzłów zadania posiada oddzielną przestrzeń $SCRATCH_LOCAL dostępną wyłącznie na czas działania zadania.

Każdorazowo rozmiar zasobu $SCRATCH_LOCAL wynosi 768 GiB na każdy zaalokowany na potrzeby zadania węzeł obliczeniowy. Prosimy o kontakt w przypadku, gdyby taka wartość okazała się niewystarczająca.

Uwaga: Katalog $SCRATCH_LOCAL dostępny jest wyłącznie na węzłach obliczeniowych zaalokowanych dla zadania i tylko na czas jego trwania. Co więcej, nie jest on współdzielony między węzłami (każdy węzeł posiada osobną przestrzeń). Po zakończeniu zadania użytkownik traci dostęp do zasobu. Jeśli dane tam przechowywane są istotne, to przed zakończeniem obliczeń powinny zostać one kopiowane do katalogu grupy ($PLG_GROUPS_STORAGE/<nazwa_zespołu>) lub ewentualnie do katalogu domowego użytkownika ($HOME).

Przestrzeń dyskowa w pamięci operacyjnej MEMFS

W celu wykorzystania pamięci RAM do przechowywania plików tymczasowych należy dodatkowo wyspecyfikować parametr "-C memfs” przy zlecaniu zadania. Przykładowo, w skrypcie wsadowym powinna znaleźć się dyrektywa: #SBATCH -C memfs

Po uruchomieniu zadania owy zasób dyskowy dostępny dla użytkownika na węzłach obliczeniowych pod zmienną środowiskową $MEMFS. Należy pamiętać, że pamięć wykorzystywana przy zapisie na MEMFS jest liczona do pamięci zarezerwowanej dla zadania a zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".

Uwaga: Przy wykorzystaniu pamięci operacyjnej jako zasobu dyskowego MEMFS należy pamiętać, że:

  • metodę tą można stosować tylko dla zadań jednowęzłowych
  • należy pamiętać, że zużycie pamięci przez zadanie łącznie z pamięcią wykorzystywną w MEMFS nie może przekraczać pamięci zadeklarowanej parametrem "--mem" lub "--mem-per-cpu".
  • metodę tą można stosować jedynie gdy całościowe zapotrzebowania zadania na dyski oraz pamięć nie przekracza całości dostępnej pamięci węzła (dla normalnych węzłów Prometheusa 120GB)
  • najlepiej przeprowadzać obliczenia w trybie pełnowęzłowym.

Uruchamianie zadań

Zlecanie zadań na klastrze Prometheus odbywa się poprzez system kolejkowy SLURM.

Zadanie może być zlecone zarówno w trybie wsadowym jak i w trybie interaktywnym.

Przed uruchomieniem zadań zapoznaj się z informacjami o systemie grantów

Tryb wsadowy

Do zlecania zadania w trybie wsadowym służy komenda sbatch. Użycie komendy: sbatch skrypt.sh.
Wszystkie opcje należy poprzedzić dyrektywą #SBATCH (koniecznie ze znakiem #).
Szczegółowe informacje: man sbatch oraz sbatch --help.

Przykładowy skrypt:

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp. 

#!/bin/bash
## Nazwa zlecenia
#SBATCH -J ADFtestjob
## Liczba alokowanych węzłów
#SBATCH -N 1
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=1
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=1GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"


## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

srun /bin/hostname
module load plgrid/apps/adf/2014.07 
adf input.adf

Zadania wykorzystujące MPI

Uruchamianie zadań MPI na Prometheuszu wygląda podobnie jak uruchamianie takich zadań na innych klastrach wyposażonych w system kolejkowy SLURM integrujący się z bibliotekami MPI. W przypadku Prometheusa dostępne są różne wersje bibliotek MPI (najczęściej OpenMPI i IntelMPI) dla większości dostępnych kompilatorów. Podczas uruchamiania aplikacji proszę nie podawać explicite parametru -n lub -np system dobierze odpowiednie wartości na podstawie parametrów alokacji (umieszczonych w skrypcie startowym) i zostaną one zastosowane. W uzasadnionych przypadkach, gdzie aplikacja wymaga specyficznej konfiguracji (np. lokalne wątkowanie), można podać wspomniane parametry.

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp. 

#!/bin/bash
## Nazwa zlecenia
#SBATCH -J MPITest
## Liczba alokowanych węzłów
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"

srun /bin/hostname

## Zaladowanie modulu IntelMPI
module add plgrid/tools/impi

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

mpiexec ./calcDiff 100 50

Dobrą praktyką jest kompilowanie i uruchamianie aplikacji przy pomocy środowiska budowanego tym samym zestawem modułów. Zalecamy korzystanie z wrappera mpiexec. Wielkość alokacji, w tym przypadku 2 węzły po 24 rdzenie, przekłada się bezpośrednio na 48 tasków dostępnych dla aplikacji korzystającej z MPI. Dopuszczalne jest uruchomienie serii aplikacji MPI w jednym skrypcie, ale najczęściej, ze względu na długi czas wykonania, nie jest to optymalny sposób prowadzenia obliczeń. Niedopuszczalne jest jednoczesne uruchomienie wielu aplikacji MPI w ramach jednej alokacji, taka praktyka prowadzi do kłopotówzwiązanych z alokacją zasobów na wyłączność dla danej aplikacji.

Proste zrównoleglenie wielu niezależnych zadań

Dość częstym przypadkiem użycia klastra jest przetworzenie wielu paczek danych, gdzie każda paczka jest przetwarzana niezależnie. Dobrym przykładem takich zadań jest przetwarzanie wielu obrazów w ten sam sposób. SLURM umożliwia proste zrównoleglenie takiego przetwarzania poprzez użycie komendy srun. Przykładowy skrypt, który zrównolegli uruchomienie wielu instancji obliczeń, gdzie stopień równoległości jest ustalany na podstawie parametrów zadania, znajduje się poniżej:

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp. 

#!/bin/bash
## Nazwa zlecenia
#SBATCH -J testjob
## Liczba alokowanych węzłów
#SBATCH -N 2
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=24
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=5GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"

module load plgrid/tools/imagemagick

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

ls *.tif | xargs -t -d "\n" -P ${SLURM_NTASKS} -n 1 srun -n 1 -N 1 --mem=5gb mogrify -format png

Powyższy skrypt dla każdego pliku *tif w katalogu uruchomi aplikację mogrify, tak aby skonwertować obraz do pliku png. Pierwszą czynnością jest wylistowanie plików wejściowych, następnie wynik jest przekazywany do komendy xargs, która przez parametr -P zapewnia równoległe uruchomienie dalszego polecania srun. Do każdej instancji srun zostanie przekazany jeden parametr, maksymalna równoległość wyniesie ${SLURM_NTASKS}. Każdy srun uruchomi aplikację mogrify na jednym rdzeniu z przydzielonym 5GB pamięci.

Tryb interaktywny

Do zlecania zadań w trybie interaktywnym z powłoką służy komenda (przykład): srun -p plgrid-testing -N 1 --ntasks-per-node=1 -n 1 -A <grant_id> --pty /bin/bash -l Powyższa komenda uruchomi zadanie w partycji plgrid-testing na 1 węźle z alokacją 1 rdzenia.

Samo polecenie srun odpowiada za uruchomienie komendy w ramach zaalokowanych zasobów.
Jednak w przypadku, gdy zasoby nie zostały wcześniej zaalokowane, komenda ta uprzednio dokonuje ich rezerwacji tuż przed uruchomieniem obliczeń.

Zadania tablicowe

Zadania tablicowe to mechanizm pozwalający na zlecanie dużej ilości zadań wsadowych, które są do siebie podobne. Zadania tablicowe posiadają swój indeks, dostępny jako zmienną środowiskowa $SLURM_ARRAY_TASK_ID wewnątrz zadania, dzięki któremu można odpowiednio parametryzować uruchamianą aplikację. Sposób zlecania zadania jest analogiczny jak w przypadku zwykłych zadań wsadowych, a przykładowy skrypt zawierający parametr --array -a, definiujący zakres indeksów, wygląda następująco:

UWAGA! To jest przykładowy skrypt, którego NIE NALEŻY uruchamiać. Przed jego uruchomieniem należy przeglądnąć podane opcje i dostosować je do własnych potrzeb, zmieniając m.i. nazwę grantu, nazwę partycji, czas trwania zadania, itp. 

#!/bin/bash
## Nazwa zlecenia
#SBATCH -J testjob
## Liczba alokowanych węzłów
#SBATCH -N 1
## Liczba zadań per węzeł (domyślnie jest to liczba alokowanych rdzeni na węźle)
#SBATCH --ntasks-per-node=1
## Ilość pamięci przypadającej na jeden rdzeń obliczeniowy (domyślnie 5GB na rdzeń)
#SBATCH --mem-per-cpu=1GB
## Maksymalny czas trwania zlecenia (format HH:MM:SS)
#SBATCH --time=01:00:00 
## Nazwa grantu do rozliczenia zużycia zasobów
#SBATCH -A <grant_id>
## Specyfikacja partycji
#SBATCH -p plgrid-testing
## Plik ze standardowym wyjściem
#SBATCH --output="output.out"
## Plik ze standardowym wyjściem błędów
#SBATCH --error="error.err"
## Parametr wyznaczający indeksy zadania tablicowego
#SBATCH --array=0-100

## przejscie do katalogu z ktorego wywolany zostal sbatch
cd $SLURM_SUBMIT_DIR

myCalculations $SLURM_ARRAY_TASK_ID

Zadania wykorzystujące GPGPU

Dostęp do węzłów z GPGPU

Dla zadań korzystających w obliczeniach z kart GPGPU przeznaczona została specjalna partycja - plgrid-gpu. Aby móc przeprowadzać obliczenia z wykorzystaniem GPGPU konieczne jest złożenie wniosku o grant właściwy, który przeznaczony zostanie w całości wyłącznie na obliczenia z wykorzystaniem kart GPGPU. Grant taki nie powinien być używany do przeprowadzania obliczeń w partycjach innych niż plgrid-gpu. We wniosku o grant należy wyraźnie zaznaczyć, że wymagany jest dostęp do partycji plgrid-gpu. Zalecane jest także (ale nie jest to konieczne), aby grant taki posiadał w nazwie wyraz gpu (np. obliczeniagpu) - ułatwia to identyfikację grantów. Każdy wniosek o dostęp do partycji plgrid-gpu jest rozpatrywany indywidualnie przez dostawcę zasobów.

Informacje ogólne

Karty GPU w systemie kolejkowym SLURM są rodzajem tzw. generic resources (GRES), a ich identyfikatorem jest "gpu".
Informację o tym na których węzłach/partycjach znajdują się karty GPU można otrzymać np. przy pomocy komendy sinfo:

sinfo -o '%P || %N || %G'

Zlecanie zadań odbywa się poprzez podanie opcji --partition=plgrid-gpu --gres=gpu[:count] systemu kolejkowego.
W przypadku gdy nie ma podanej opcji count, system kolejkowy domyślnie alokuje jedną kartę na węźle obliczeniowym.

Po zleceniu zadania system kolejkowy automatycznie ustawia zmienną środowiskową $CUDA_VISIBLE_DEVICES oraz zezwala na dostęp do zaalokowanych do kart.

Zadania interaktywne

Przykładowo, gdy chcemy uruchomić zadanie interaktywne na jednym serwerze i zażądać 2 kart GPU:

srun -p plgrid-gpu -N 1 -n 24 -A <grant_id> --gres=gpu:2 --pty /bin/bash -l

Zadania interaktywne MPI

Uwaga! Wyjątkiem jest uruchamianie interaktywnych aplikacji MPI (np. w celach testów). Z powodu nieco innej obsługi kart GPU niż zwykłych procesorów przez system SLURM, uruchomienie zadania interaktywnego wymaga niestandardowej procedury.

Przykładowo, gdy chcemy uruchomić zadanie interaktywne na dwóch serwerach i zażądać 2 kart GPU na każdym z nich (łącznie 4 karty GPU) na czas 1 godziny:

salloc -p plgrid-gpu -N 2 --ntasks-per-node 24 -n 48 -A <grant_id> --gres=gpu:2 --time 1:00:00

Polecenie salloc zaalokowało nasze zadanie i zwróciło jego numer, przykładowo 1234.

Następnie uruchamiamy srun wymagając 0 kart GPU w zadaniu o numerze zwróconym przez salloc:

srun --jobid=1234 --gres=gpu:0 -O --pty /bin/bash -l

Otrzymaliśmy dostęp do powłoki na jednym z węzłów, teraz po załadowaniu odpowiedniego modułu MPI można już uruchomić własną aplikację za pomocą mpirun lub mpiexec. Isotne jest aby podczas uruchamiania aplikacji nie przekazywać zmiennych środowiska, czyli w przypadku IntelMPI należy dodać parametr -genvnoneAplikacja będzie miała dostęp do wszystkich kart GPU zaalokowanych w komendzie salloc, niezależnie od wymagania gpu:0 użytego w srun.

Po zakończeniu testów należy usunąć alokację za pomocą:

scancel 1234

Zadania wsadowe

Dla skryptu wsadowego dodatkowe zmiany nie są potrzebne, przykładowo gdy żądamy po jednej karcie na węzeł obliczeniowy, wystarczy dopisać do skryptu: 

#SBATCH --partition=plgrid-gpu
#SBATCH --gres=gpu


Uwaga: Wszelkie informacje na temat komend SLURMa można znaleźć w manualu, np.: man sbatch

Monitorowanie kolejek, partycji, węzłów, zadań i zasobów

  • Sktypty specyficzne dla Prometheusa
    • pro-jobs - statystyki dla zakolejkowanych lub już uruchomionych zadań użytkownika
    • pro-jobs-history - statystyki dla zakończonych zadań użytkownika
    • pro-fs - statystyki użycia zasobów dyskowych przez użytkownika
    • pro-groupdir-fix - korekcja uprawnień danych w katalogu zespołu
    • pro-grant-jobs - lista zadań w ramach grantów użytkownika (zawiera także zadania innych członków grup grantowych użytkownika)


  • Narzędzia systemu SLURM
    • squeue - lista aktualnie zakolejkowanych/uruchomionych zadań (użytkownik widzi zadania z grantów do niego należących, w celu wyświetlenia tylko swoich zadań należy podać opcję -u, tj. squeue -u $USER)
    • scontrol show job [<ID_zadania>] - szczegóły zadania
    • sstat -a -j <ID_zadania>/<ID_zadania.batch> - zużycie zasobów w ramach kroków (step) działającego zadania
    • scancel <ID_zadania> - usunięcie zadania (działającego lub zakolejkowanego)
    • sacct - zużycie zasobów zakończonego już zadania/kroku
    • scontrol show partition [<nazwa_partycji>] - właściwości partycji
    • sinfo - lista węzłów
    • scontrol show node [<nazwa_węzła>] - właściwości węzła


Przenoszenie danych z klastra Zeus

Klastry Zeus i Prometheus nie współdzielą żadnych zasobów dyskowych, w związku z tym, aby korzystać z danych zgromadzonych na Zeusie, należy je najpierw skopiować. W tym celu możemy posłużyć się komendami:

  • scp - w przypadku małych plików (używa loginu i hasła),
  • globus-url-copy - w przypadku dużych plików (używa loginu i hasła LUB grid proxy),
  • uberftp - w przypadku dużych plików, interaktywnie (używa grid proxy).


Podstawowe informacje o komendzie globus-url-copy:

  • składnia: globus-url-copy ŻRÓDŁO CEL, gdzie źródło i cel poprzedzone są nazwą protokołu: np. file://,
  • aby pobrać pliki z zeusa używamy 2 protokołów:
    • gsiftp - gsiftp://zeus.cyfronet.pl/ - uwierzytelnianie za pomocą proxy (musimy najpierw stworzyć grid proxy komendą grid-proxy-init),
    • sshftp - sshftp://zeus.cyfronet.pl/ - uwierzytelnianie hasłem PLGrid,
  • uwierzytelnianie proxy pozwala uruchamiać wiele transferów bez podawania hasła za każdym razem,
  • protokół docelowy to file:// czyli plik/katalog lokalny,
  • dla ŻRÓDŁA i CELU musimy podać pełną ścieżkę pliku lub możemy użyć skrótu w postaci ~plgLOGIN do naszego katalogu domowego,
  • dla CELU (czyli protokołu file://) możemy podać też zmienne środowiskowe np. $PWD - bieżący katalog,
  • w przypadku CELU gdy podamy nazwę pliku np. $PWD/nazwa.txt, plik zapisze się pod daną nazwą, a gdy podamy tylko katalog, to plik zapisze się pod taką samą nazwą jak źródłowy,
  • aby przesyłać całe katalogi, należy je najpierw spakować komendą tar -czf archiwum.tar katalog,
  • w przypadku gdy nasz login na klastrze Prometheus różni się od tego na klastrze Zeus możemy użyć wyłącznie protokołu "sshftp://" a do ŹRÓDŁA należy dodać login na klastrze Zeus np. sshftp://MOJ_USERNAME@zeus.cyfronet.pl/.


Przykład użycia komendy globus-url-copy:

  • skopiuj z katalogu domowego użytkownika plgLOGIN na klastrze Zeus, do bieżącego katalogu plik "bigfile.txt" i nadaj mu tą samą nazwę:
globus-url-copy sshftp://zeus.cyfronet.pl/~plgLOGIN/bigfile.txt file://$PWD/
  • skopiuj plik "/mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt" z klastara Zeus do bieżącego katalogu:
globus-url-copy sshftp://zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/
  • j.w. ale z podanym loginem z klastra Zeus (domyślnie używany jest taki sam użytkownik na jakiego jesteśmy zalogowani)
globus-url-copy sshftp://MOJ_USERNAME@zeus.cyfronet.pl//mnt/gpfs/work/plgrid/groups/plggGROUP_NAME/bigfile.txt file://$PWD/


Odnośniki do dodatkowych pomocy/dokumentacji:

Zasady obowiązujące na klastrze Prometheus

  • Obliczenia wykonywane na maszynie dostępowej będą usuwane bez ostrzeżenia. Maszyna dostępowa powinna służyć wyłącznie do przygotowywania plików wejściowych obliczeń i do ich zlecania na klaster za pośrednictwem systemu kolejkowego. Kopiowanie dużych ilości danych również może w znacznym stopniu obciążać maszynę dostępową, dlatego też zaleca się, aby kopiowanie przeprowadzać na węźle obliczeniowym (w zadaniu interaktywnym, np. srun -p plgrid -A grant_id -n 1 --pty /bin/bash -l). Podobnie jest z kompilacją programów - ją również należy wykonywać na węźle obliczeniowym, a nie bezpośrednio na maszynie dostępowej.
  • Obliczenia wykraczające poza zakres deklarowanego tematu badań zużywające znaczną część zasobów klastra będą usuwane bez ostrzeżenia.
  • Dane obliczeniowe należy składować i przetwarzać na systemie plików Lustre pod lokalizacją $SCRATCH.
  • W obliczeniach nie należy korzystać z katalogu /tmp, do przechowywania plików tymczasowych należy wykorzystywać katalogi znajdujące się pod zmiennymi $SCRATCH, $SCRATCHDIR lub $TMPDIR.
  • Na maszynie dostępowej ustawiony jest limit pamięciowy 6 GiB dla sumy wszystkich procesów danego użytkownika. Próba przekroczenia limitu powoduje automatyczne zabicie procesu próbującego przekroczyć ustalony limit.

Kontakt

Pomoc dla użytkowników PL-Grid: Helpdesk PL-Grid
Kontakt z administratorami: prometheus@cyfronet.pl, +48 12 632 33 55 w. 603

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