Batch operation with SLURM

Batch operation

The Linux cluster is a network of networked computers (nodes) that works in batch mode.
To run a program on the cluster, you must first reserve resources such as computing time, the number of processors or the size of the main memory. To do this, you create a submit script file that is transferred to the workload manager SLURM (Simple Linux Utility for Resource Management).

In this file, you define both the desired resources and the commands for starting your program.

You can use our graphical script generator to create a submit script. The job is then submitted via the server its-cs1.its.uni-kassel.de.

As soon as your script has been submitted to SLURM, your computing job will be queued as a so-called job. The job starts automatically as soon as the required resources are available. During the runtime of your job, your personal home directory remains available on all participating nodes. Programs can be started there, data can be read and results can be written. If you wish, you can be notified by e-mail as soon as your job has finished.

There is no direct user input in batch mode. Instead, all output from your program is redirected to a file that you specify in the submit script.
As an alternative to classic batch mode, it is possible to reserve nodes for interactive use. This is useful if graphical interfaces are displayed or user input is required during program execution. Please note, however, that interactive work is significantly more time-consuming, as all resource entries must be made manually on the command line each time.

Proceed in this way if you want to start a program that requires a lot of computing power:

  • Find out about the available nodes and partitions (sinfo)
  • Define which hardware resources and modules you need and how the program should be executed (submit script)
  • Have the submit script executed by Slurm (sbatch)
  • Monitor your job (squeue) or be informed when the job is finished (enter email in submit script)

These individual steps are explained in more detail in the following chapters.

Job priority

The nodes in the cluster are divided into different partitions. Some partitions share the same nodes. Jobs in certain partitions have priority over others.

Batch jobs that are submitted in the minijobs partition have a higher priority than jobs in the public, exec, mpi and mpi1 partitions.
In addition, the priority of a job automatically increases as the waiting time in the queue increases. At the same time, the resource manager tries to make optimum use of the available resources: Jobs are started preferentially if they use the available resources efficiently, even if other jobs with a higher priority still have to wait.

An example:
If a high-priority job requires two computers, only one of which is currently free, jobs with a lower priority can also be started on the available computer until it is fully released. In order to use the cluster as efficiently as possible, it is important to provide realistic information about the required resources. If you want to reserve a large number of nodes at the same time, you should first check with sinfo how many nodes are available and currently free in the desired partition.