„Debrecen2 GPU klaszter en” változatai közötti eltérés

Innen: KIFÜ Wiki
157. sor: 157. sor:
 
==== SLURM warnings ====
 
==== SLURM warnings ====
 
<pre>
 
<pre>
Resources/AssociationResourceLimit - Erőforrásra vár
+
Resources / AssociationResourceLimit - Waiting for a resource
AssociationJobLimit/QOSJobLimit - Nincs elég CPU idő vagy a maximális CPU szám le van foglalva
+
AssociationJobLimit / QOSJobLimit - Not enough CPU time or maximum CPU number is reserved
Piority - Alacsony prioritás miatt várakozik
+
Priority - Waiting due to low priority
 +
 
 
</pre>
 
</pre>
Az utóbbi esetben, csökkenteni kell a job által lefoglalni kívánt időt. Egy adott projekt részére maximálisan 512 CPU-n futhatnak jobok egy adott időben.
+
In the latter case, the time to be reserved by the job must be reduced. Jobs for a given project can run on up to 512 CPUs at a given time.
  
==== Licenszek ellenőrzése ====
+
==== Checking licenses ====
 
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
 
Az elérhető és éppen használt licenszekről a következő parancs ad információt:
 
<pre>
 
<pre>
169. sor: 170. sor:
 
</pre>
 
</pre>
  
==== Karbantartás ellenőrzése ====
+
==== Checking maintenance ====
A karbantartási időablakban az ütemező nem indít új jobokat, de beküldeni lehet. A karbantartások időpontjairól a következő parancs ad tájékoztatást:
+
In the maintenance time window, the scheduler does not start new jobs, but jobs could still be submitted. The following command provides information on maintenance dates:
 
<pre>
 
<pre>
 
sreservations
 
sreservations
 
</pre>
 
</pre>
  
==== Összesített felhasználás ====
+
==== Aggregate consumption ====
Egy hónapra visszamenőleg az elfogyasztott CPU perceket a következő paranccsal kérhetjük le:
+
You can retrieve the CPU minutes consumed up to one month ago with the following command:
 
<pre>
 
<pre>
 
susage
 
susage
 
</pre>
 
</pre>
  
==== Teljes fogyasztás ====
+
==== Total consumption ====
Ha szeretnénk tájékozódni arról, hogy egy bizony idő óta mennyi a CPU idő felhasználásunk akkor azt ezzel paranccsal tudjuk lekérdezni:
+
If you want to know how much CPU time you have been using for a certain period, you can query it with this command:
 
<pre>
 
<pre>
 
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
 
sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01
 
</pre>
 
</pre>
  
=== Feladatok futtatása ===
+
=== Submitting jobs ===
Alkalmazások futtatása a szupergépeken kötegelt (batch) üzemmódban lehetséges. Ez azt jelenti, hogy minden futtatáshoz egy job szkriptet kell elkészíteni, amely tartalmazza az igényelt erőforrások leírását és a futtatáshoz szükséges parancsokat. Az ütemező paramétereit (erőforrás igények) a <code>#SBATCH</code> direktívával kell megadni.
+
It is possible to run applications on supercomputers in batch mode. This means that for each run, a job script must be created that includes a description of the resources required and the commands required to run. Scheduler parameters (resource requirements) must be specified with the <code>#SBATCH</code> directive.
  
 
==== Kötelező paraméterek ====
 
==== Kötelező paraméterek ====

A lap 2021. június 24., 11:16-kori változata

Cluster Debrecen2 (Leo)
Type HP SL250s
Core / node 8 × 2 Xeon E5-2650v2 2.60GHz
GPU / node 68 * 3 Nvidia K20x + 16 * 3 Nvidia K40x
# of compute nodes 84
Max Walltime 7-00:00:00
Max core / project 336
Max mem / core 7000 MB

Requesting CPU time


Login

ssh USER@login.debrecen2.hpc.niif.hu

If a non-default key is used, it must be specified with the -i KEY option (SSH and SCP commands).

Copying files with SCP

Download from the HOME directory and upload to the HOME directory:

Up: scp FILE USER@login.debrecen2.hpc.niif.hu: FILE
Down: scp USER@login.debrecen2.hpc.niif.hu: FILE FILE

Data synchronization

Larger files / directory structures shall be synchronized using the following commands

Up: rsync -a -e ssh DIRECTORY USER@login.debrecen2.hpc.niif.hu:/home/USER
Down: rsync -a -e ssh USER@login.debrecen2.hpc.niif.hu:/home/USER/DIRECTORY

The --delete option must be specified to synchronize deleted files.

User interface

               short form of CWD
                     |
    DEBRECEN2[login] ~ (0)$
        |       |       |
   HPC station  |       |
    short machine name  |
               exit code of the previous command

Module environment

The list of available modules is obtained with the following command:

module avail

the list of already loaded modules:

module list

You can load an application with the following command:

module load APP

The environment variables set by KIFÜ are listed by the nce command.

Data sharing for project members

To share files / directories ACLs must be set. To make the HOME directory readable by another user (OTHER):

setfacl -m u:OTHER:rx $HOME

To make a specific directory (DIRECTORY) writable:

setfacl -m u:OTHER:rxw $HOME/DIRECTORY

You can list extended rights with the following command:

getfacl $HOME/DIRECTORY

Using a shared home directory

The common file system that is available for the login nodes of the supercomputers is accessible under the following path:

/mnt/fhgfs/home/$USER

Backups could be made into the shared directory with the following command:

rsync -avuP --delete $HOME/DIRECTORY /mnt/fhgfs/home/$USER

Compiling applications

Users are encouraged to try compiling needed applications in their own home directory first. If it fails for some reason, then the next step is to ask the Hungarian supercomputer users because there is a good chance that others have already run into the same problem. They can be reached at: hpc-forum at listserv.niif.hu. You can subscribe to this mailing list [1]. You should also check the archive when looking into the issue. KIFÜ HPC support has extremely limited capacity to handle individual compiling requests but still you may contact hpc-support at niif.hu with your problem. In the latter case please be patient for a few days while waiting for responses.

Using the SLURM scheduler

The supercomputer has a CPU hour (machine time) based schedule. The following command provides information about the status of the user's Slurm projects (Account):

sbalance

The second column (Usage) shows the machine time spent by each user, and the fourth column shows the total machine time of the account. The last two columns provide information about the maximum (Account Limit) and available machine time.

Scheduler Account Balance
---------- ----------- + ---------------- ----------- + ------------- -----------
User             Usage |          Account       Usage | Account Limit   Available (CPU hrs)
---------- ----------- + ---------------- ----------- + ------------- -----------
bob *                7 |           foobar           7 |         1,000         993
alice                0 |           foobar           7 |         1,000         993

Estimating CPU time

It is advisable to estimate the wall clock time before large-scale (production) runs. To do this, use the following command:

sestimate -N NODES -t WALLTIME

where NODES is the number of nodes to be reserved and WALLTIME is the maximum run time.

It is important to specify the wall clock time you want to reserve as accurately as possible, as the scheduler also ranks the jobs waiting to be run based on this. It is generally true that the shorter job will take place sooner. It is advisable to check the actual run time with the sacct command afterwards.

Status information

The squeue and the sinfo command provide information about the general state of the cluster. Each job submitted is assigned a unique identification number (JOBID). Knowing this, we can ask for more information. Characteristics of the submitted or already running job:

scontrol show job JOBID

Each job is also put into a so-called accounting database. From this you can retrieve the characteristics of the jobs you have run and the statistics of resource usage. You can view detailed statistics with the following command:

sacct -l -j JOBID

The following command provides information about the memory used:

smemory JOBID

The next one shows disk usage:

sdisk JOBID

SLURM warnings

Resources / AssociationResourceLimit - Waiting for a resource
AssociationJobLimit / QOSJobLimit - Not enough CPU time or maximum CPU number is reserved
Priority - Waiting due to low priority

In the latter case, the time to be reserved by the job must be reduced. Jobs for a given project can run on up to 512 CPUs at a given time.

Checking licenses

Az elérhető és éppen használt licenszekről a következő parancs ad információt:

slicenses

Checking maintenance

In the maintenance time window, the scheduler does not start new jobs, but jobs could still be submitted. The following command provides information on maintenance dates:

sreservations

Aggregate consumption

You can retrieve the CPU minutes consumed up to one month ago with the following command:

susage

Total consumption

If you want to know how much CPU time you have been using for a certain period, you can query it with this command:

sreport -t Hours Cluster AccountUtilizationByUser Accounts=ACCOUNT Start=2015-01-01

Submitting jobs

It is possible to run applications on supercomputers in batch mode. This means that for each run, a job script must be created that includes a description of the resources required and the commands required to run. Scheduler parameters (resource requirements) must be specified with the #SBATCH directive.

Kötelező paraméterek

A következő paramétereket minden esetben meg kell adni:

#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=NAME
#SBATCH --time=TIME

ahol az ACCOUNT a terhelendő számla neve (elérhető számláinkről az sbalance parancs ad felvilágosítást), a NAME a job rövid neve, a TIME pedig a maximális walltime idő (DD-HH:MM:SS). A következő időformátumok használhatók: "minutes", "minutes:seconds", "hours:minutes:seconds", "days-hours", "days-hours:minutes" és "days-hours:minutes:seconds".

GPU-k lefoglalása

A GPU-k lefoglalása a következő direktívával törénik:

#SBATCH --gres=gpu:N

Az N a GPU-k/node számát adja meg, ami 1, 2 és 3 lehet maximum.

Interaktív használat

Rövid interaktív feladatokat az 'srun' paranccsal tudunk beküldeni, pl.:

srun -l -n 1 -t TIME --gres=gpu:1 -A ACCOUNT APP

Batch job-ok indítása

A jobok feladását a következő parancs végzi:

sbatch slurm.sh

Sikeres feladás esetén a következő kimenetet kapjuk:

Submitted batch job JOBID

ahol a JOBID a feladat egyedi azonosítószáma.

A feladat leállítását a következő parancs végzi:

scancel JOBID

Nem újrainduló jobok

Nem újrainduló jobokhoz a következő direktívát kell használni:

#SBATCH --no-requeue

Feladat sorok

A szupergépen két, egymást nem átfedő, sor (partíció) áll rendelkezésre, a prod-gpu-k40 sor és a prod-gpu-k20 sor. Mind a kettő éles számolásokra való, az első olyan CN gépeket tartalmaz amikben Nvidia K40x GPU-k, a másodikban pedig Nvidia K20x GPU-k vannak. Az alapértelmezett sor a prod-gpu-k20. A prod-gpu-k40 partíciót a következő direktívával lehet kiválasztani:

#SBATCH --partition=prod-gpu-k40

A szolgáltatás minősége (QOS)

A szolgáltatást alapértelmezett minősége normal, azaz nem megszakítható a futás.

Magas prioritás

A magas prioritású jobok maximum 24 óráig futhatnak, és kétszer gyorsabb időelszámolással rendelkeznek, cserébe az ütemező előreveszi ezeket a feladatokat.

#SBATCH --qos=fast
Alacsony prioritás

Lehetőség van alacsony prioritású jobok feladására is. Az ilyen feladatokat bármilyen normál prioritású job bármikor megszakíthatja, cserébe az elhasznált gépidő fele számlázódik csak. A megszakított jobok automatikusan újraütemeződnek. Fontos, hogy olyan feladatokat indítsunk alacsony prioritással, amelyek kibírják a véletlenszerű megszakításokat, rendszeresen elmentik az állapotukat (checkpoint) és ebből gyorsan újra tudnak indulni.

#SBATCH --qos=lowpri

Memória foglalás

Alapértelmezetten 1 CPU core-hoz 1000 MB memória van rendelve, ennél többet a következő direktívával igényelhetünk:

#SBATCH --mem-per-cpu=MEMORY

ahol MEMORY MB egységben van megadva. A maximális memória/core 7800 MB lehet.

Email értesítés

Levél küldése job állapotának változásakor (elindulás,leállás,hiba):

#SBATCH --mail-type=ALL
#SBATCH --mail-user=EMAIL

ahol az EMAIL az értesítendő emial cím.

Tömbfeladatok (arrayjob)

Tömbfeladatokra akkor van szükségünk, egy szálon futó (soros) alkalmazást szeretnénk egyszerre sok példányban (más-más adatokkal) futtatni. A példányok számára az ütemező a SLURM_ARRAY_TASK_ID környezeti változóban tárolja az egyedi azonosítót. Ennek lekérdezésével lehet az arrayjob szálait elkülöníteni. A szálak kimenetei a slurm-SLURM_ARRAY_JOB_ID-SLURM_ARRAY_TASK_ID.out fájlokba íródnak. Az ütemező a feltöltést szoros pakolás szerint végzi. Ebben az esetben is érdemes a processzorszám többszörösének választani a szálak számát. Bővebb ismertető

#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=array
#SBATCH --time=24:00:00
#SBATCH --array=1-96
srun envtest.sh

OpenMPI feladatok

MPI feladatok esetén meg kell adnunk az egy node-on elinduló MPI processzek számát is (#SBATCH --ntasks-per-node=). A leggyakoribb esetben ez az egy node-ban található CPU core-ok száma. A párhuzamos programot az mpirun paranccsal kell indítani.

#!/bin/bash
#SBATCH -A ACCOUNT
#SBATCH --job-name=mpi
#SBATCH -N 2
#SBATCH --ntasks-per-node=8
#SBATCH --time=12:00:00
mpirun --report-pid ${TMPDIR}/mpirun.pid PROGRAM

OpenMPI FAQ: http://www.open-mpi.org/faq

OpenMP (OMP) feladatok

OpenMP párhuzamos alkalmazásokhoz maximum 1 node-ot lehet lefoglalni. Az OMP szálák számát az OMP_NUM_THREADS környezeti változóval kell megadni. A változót vagy az alkamazás elé kell írni (ld. példa), vagy exportálni kell az indító parancs előtt: export OMP_NUM_THREADS=8

A következő példában egy taskhoz 8 CPU core-t rendeltunk, a 8 CPU core-nak egy node-on kell lennie. A CPU core-ok számát a SLURM_CPUS_PER_TASK változó tartalmazza, és ez állítja be az OMP szálak számát is.

Alice felhasználó a foobar számla terhére, maximum 6 órára indít el egy 8 szálas OMP alkalmazást.

#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=omp
#SBATCH --time=06:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./a.out

Hibrid MPI-OMP feladatok

Hibrid MPI-OMP módról akkor beszélünk, ha a párhuzamos alkalmazás MPI-t és OMP-t is használ. Érdemes tudni, hogy az Intel MKL-el linkelt programok MKL hívásai OpenMP képesek. Általában a következő elosztás javasolt: az MPI processzek száma 1-től az egy node-ban található CPU foglalatok száma, az OMP szálak ennek megfelelően az egy node-ban található összes CPU core szám vagy annak fele, negyede (értelem szerűen). A jobszkipthez a fenti két mód paramétereit kombinálni kell.

A következő példában 2 node-ot, és node-onként 1-1 taskot indítunk taskonként 10 szállal. Alice felhasználó a foobar számla terhére, 8 órára, 2 node-ra küldött be egy hibrid jobot. Egy node-on egyszerre csak 1 db MPI processz fut ami node-onként 8 OMP szálat használ. A 2 gépen összesen 2 MPI proceszz és 2 x 8 OMP szál fut.

#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=mpiomp
#SBATCH --time=08:00:00
#SBATCH -N 2
#SBATCH --ntasks=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=8
#SBATCH -o slurm.out
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
mpirun ./a.out

Maple Grid feladatok

Maple-t az OMP feladatokhoz hasonlóan 1 node-on lehet futtatni. Használatához be kell tölteni a maple modult is. A Maple kliens-szerver üzemmódban működik ezért a Maple feladat futtatása előtt szükség van a grid szerver elindítására is (${MAPLE}/toolbox/Grid/bin/startserver). Ez az alkalmazás licensz köteles, amit a jobszkriptben meg kell adni (#SBATCH --licenses=maplegrid:1). A Maple feladat indátását a ${MAPLE}/toolbox/Grid/bin/joblauncher paranccsal kell elvégezni.

Alice felhasználó a foobar számla terhére, 6 órára indítja el a Maple Grid alkalmazást:

#!/bin/bash
#SBATCH -A foobar
#SBATCH --job-name=maple
#SBATCH -N 1
#SBATCH --ntasks-per-node=16
#SBATCH --time=06:00:00
#SBATCH -o slurm.out
#SBATCH --licenses=maplegrid:1

module load maple

${MAPLE}/toolbox/Grid/bin/startserver
${MAPLE}/toolbox/Grid/bin/joblauncher ${MAPLE}/toolbox/Grid/samples/Simple.mpl