Scheduling jobs
Overview
Teaching: 45 min
Exercises: 30 minQuestions
What is a scheduler and why are they used?
How do I launch a program to run on any one node in the cluster?
How do I capture the output of a program that is run on a node in the cluster?
Objectives
Run a simple Hello World style program on the cluster.
Submit a simple Hello World style script to the cluster.
Use the batch system command line tools to monitor the execution of your job.
Inspect the output and error files of your jobs.
Job scheduler
An HPC system might have thousands of nodes and thousands of users. How do we decide who gets what and when? How do we ensure that a task is run with the resources it needs? This job is handled by a special piece of software called the scheduler. On an HPC system, the scheduler manages which jobs run where and when.
The following illustration compares these tasks of a job scheduler to a waiter in a restaurant. If you can relate to an instance where you had to wait for a while in a queue to get in to a popular restaurant, then you may now understand why sometimes your jobs do not start instantly as in your laptop.
Job scheduling roleplay (optional)
Your instructor will divide you into groups taking on different roles in the cluster (users, compute nodes and the scheduler). Follow their instructions as they lead you through this exercise. You will be emulating how a job scheduling system works on the cluster.
The scheduler used in this lesson is SLURM. Although SLURM is not used everywhere, running jobs is quite similar regardless of what software is being used. The exact syntax might change, but the concepts remain the same.
Filesystem on ARCHER2
At this point it is important to remember that ARCHER2 has two separate filesystems:
/home
and/work
.
/home
is meant for small files such as source code, and is the filesystem that you are on when you log in/work
is a much larger and faster filesystem, meant for production runs and storing large datasetsThe
/home
filesytem is not mounted on the compute nodes meaning that programs run in the batch queues cannot read from or write to files in your home directory. This has not been a problem so far as none of our programs have done file input or output. However, the parallel program we will run here reads and writes large images.
- When you log in, you will be in your home directory /home/ta018/ta018/userid/
- Before you run real programs on ARCHER2, you must change directory to /work/ta018/ta018/userid/
Running a batch job
The most basic use of the scheduler is to run a command non-interactively. Any command (or series of commands) that you want to run on the cluster is called a job, and the process of using a scheduler to run the job is called batch job submission.
In this case, the job we want to run is just a shell script. Let’s create a demo shell script to run as a test.
Creating our test job
Using your favorite text editor, create the following script and run it. Does it run on the cluster or just our login node?
#!/bin/bash echo 'This script is running on:' hostname sleep 60
If you completed the previous challenge successfully, you probably realise that there is a
distinction between running the job through the scheduler and just “running it”. To submit this job
to the scheduler, we use the sbatch
command.
userid@uan01:~> sbatch --partition=standard --qos=standard --reservation=ta018_108 --time=00:05:00 example-job.sh
Submitted batch job 36855
And that’s all we need to do to submit a job. Our work is done – now the scheduler takes over and
tries to run the job for us. While the job is waiting to run, it goes into a list of jobs called
the queue. To check on our job’s status, we check the queue using the command
squeue -u userid
.
userid@uan01:~> squeue -u userid
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
119867 standard example- userid R 0:00:06 1 nid001609
We can see all the details of our job, most importantly that it is in the “R”
or “RUNNING” state. Sometimes our jobs might need to wait in a queue
(“PD” or “PENDING”) or have an error. The best way to check
our job’s status is with squeue
. Of course, running squeue
repeatedly to check on things can be
a little tiresome. To see a real-time view of our jobs, we can use the watch
command. watch
reruns a given command at 2-second intervals. This is too frequent, and will likely upset your system
administrator. You can change the interval to a more reasonable value, for example 20 seconds, with the
-n 20
parameter. Let’s try using it to monitor another job.
userid@uan01:~> sbatch --partition=standard --qos=standard --reservation=ta018_108 --time=00:05:00 example-job.sh
userid@uan01:~> watch -n 20 squeue -u userid
You should see an auto-updating display of your job’s status. When it finishes, it will disappear
from the queue. Press Ctrl-C
when you want to stop the watch
command.
Customising a job
The job we just ran had a lot of command-line options and used all of the scheduler’s default options. In a real-world scenario, that’s probably not what we want. The default options represent a reasonable minimum. Chances are, we will need more cores and more time. To get access to these resources we must customize our job script.
Comments in UNIX (denoted by #
) are typically treated as comments and ignored. But there are exceptions. For instance the
special #!
comment at the beginning of scripts specifies what program should be used to run it
(typically /bin/bash
). Schedulers like SLURM also have a special comment
used to denote special scheduler-specific options. Though these comments differ from scheduler to
scheduler, SLURM’s special comment is #SBATCH
.
Anything following the #SBATCH
comment is
interpreted as an instruction to the scheduler. These options can also
be passed as command-line arguments, but it is often more convenient
to have them hard-wired into the job script.
The clever # trick …
The use of
#SBATCH
to denote commands to the scheduler is a very neat (and commonly used in Unix) trick which has a number of useful effects:
- You can specify commands that are interpreted at submission time (e.g. how much wallclock time you require) and commands that are interpreted much later at run time (e.g. the program you want to execute) in the same script.
- If you are using different HPC machines with different schedulers, you can have commands for both schedulers in the same script and the ones that aren’t relevant will simply be ignored as commments
- You can run the script interactively on the login nodes for debugging purposes (e.g. to check that all the input files are copied across properly) and the scheduler commands will be ignored as comment.
Let’s illustrate this by example. By default, a job’s name is the name of the script, but the
-J
option can be used to change the name of a job.
Submit the following job (sbatch example-job.sh
):
#!/bin/bash
#SBATCH --job_name=myjob
#SBATCH --partition=standard
#SBATCH --qos=standard
#SBATCH --time=00:05:00
#PBS -A tc011
#PBS -l walltime=00:10:00
#PBS -l select=1
echo 'This script is running on:'
hostname
sleep 60
userid@uan01:~> squeue -u userid
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
119867 standard myjob userid PD 0:00 1 (Resources)
Fantastic, we’ve successfully changed the name of our job!
Setting up email notifications
Jobs on an HPC system might run for days or even weeks. We probably have better things to do than constantly check on the status of our job with
squeue
. Looking at the man page forsbatch
, can you set up our test job to send you an email when it finishes?
Resource requests
But what about more important changes, such as the number of cores and memory for our jobs? One thing that is absolutely critical when working on an HPC system is specifying the resources required to run a job. This allows the scheduler to find the right time and place to schedule our job. If you do not specify requirements (such as the amount of time you need), you will likely be stuck with your site’s default resources, which is probably not what we want.
The following are several key resource requests:
-
--ntasks=<mpitasks>
- Number of MPI tasks to use. -
--ntasks-per-node=<mpitasks-per-node>
- Number of tasks per node -
--time <days-hours:minutes:seconds>
- Maximum real-world time (walltime) your job will be allowed to run. The<days>
part can be omitted.
Note that just requesting these resources does not make your job run faster! We’ll talk more about how to make sure that you’re using resources effectively in a later episode of this lesson.
Submitting resource requests
Submit a job that will use 2 full nodes and 10 minutes of walltime.
Resource requests are typically binding. If you exceed them, your job will be killed. Let’s use walltime as an example. We will request 30 seconds of walltime, and attempt to run a job for one minute.
#!/bin/bash
#SBATCH --partition=standard
#SBATCH --qos=standard
#SBATCH --time=00:00:30
echo 'This script is running on:'
hostname
sleep 120
Submit the job and wait for it to finish. Once it is has finished, check the error file.
userid@uan01:~> sbatch example-job.sh
userid@uan01:~> watch -n 20 squeue -u userid
userid@uan01:~> cat slurm-38193.out
This job is running on:
nid001147
slurmstepd: error: *** JOB 38193 ON cn01 CANCELLED AT 2017-07-02T16:35:48 DUE TO TIME LIMIT ***
Our job was killed for exceeding the amount of resources it requested. Although this appears harsh, this is actually a feature. Strict adherence to resource requests allows the scheduler to find the best possible place for your jobs. Even more importantly, it ensures that another user cannot use more resources than they’ve been given. If another user messes up and accidentally attempts to use all of the cores or memory on a node, SLURM will either restrain their job to the requested resources or kill the job outright. Other jobs on the node will be unaffected. This means that one user cannot mess up the experience of others, the only jobs affected by a mistake in scheduling will be their own.
But how much does it cost?
Although your job will be killed if it exceeds the selected runtime, a job that completes within the time limit is only charged for the time it actually used. However, you should always try and specify a wallclock limit that is close to (but greater than!) the expected runtime as this will enable your job to be scheduled more quickly. If you say your job will run for an hour, the scheduler has to wait until a full hour becomes free on the machine. If it only ever runs for 5 minutes, you could have set a limit of 10 minutes and it might have been run earlier in the gaps between other users’ jobs.
Cancelling a job
Sometimes we’ll make a mistake and need to cancel a job. This can be done with the scancel
command. Let’s submit a job and then cancel it using its job number (remember to change the
walltime so that it runs long enough for you to cancel it before it is killed!).
userid@uan01:~> sbatch example-job.sh
userid@uan01:~> squeue -u userid
Submitted batch job 38759
JOBID USER ACCOUNT NAME ST REASON START_TIME TIME TIME_LEFT NODES CPUS
38759 yourUsername yourAccount example-job.sh PD Priority N/A 0:00 1:00 1 1
Now cancel the job with its job number. Absence of any job info indicates that the job has been successfully cancelled.
userid@uan01:~> scancel 38759
... Note that it might take a minute for the job to disappear from the queue ...
userid@uan01:~> squeue -u userid
JOBID USER ACCOUNT NAME ST REASON START_TIME TIME TIME_LEFT NODES CPUS
Cancelling multiple jobs
We can also cancel all of our jobs at once using the
-u
option. This will delete all jobs for a specific user (in this case us). Note that you can only delete your own jobs.Try submitting multiple jobs and then cancelling them all with
scancel -u yourUsername
.
Other types of jobs
Up to this point, we’ve focused on running jobs in batch mode. SLURM also provides the ability to start an interactive session.
There are very frequently tasks that need to be done interactively. Creating an entire job
script might be overkill, but the amount of resources required is too much for a login node to
handle. A good example of this might be building a genome index for alignment with a tool like
HISAT2. Fortunately, we can run these types of
tasks as a one-off with srun
.
srun
runs a single command in the queue system and then exits.
Let’s demonstrate this by running the
hostname
command with srun
. (We can cancel an srun
job with Ctrl-c
.)
userid@uan01:~> srun --partition=standard --qos=standard --time=00:01:00 hostname
nid001976
srun
accepts all of the same options as sbatch
. However, instead of specifying these in a
script, these options are specified on the command-line when starting a job.
Typically, the resulting shell environment will be the same as that for
sbatch
.
Interactive jobs
Sometimes, you will need a lot of resource for interactive use. Perhaps it’s our first time running
an analysis or we are attempting to debug something that went wrong with a previous job.
Fortunately, SLURM makes it easy to start an interactive job with srun
:
userid@uan01:~> srun --partition=standard --qos=standard --time=00:10:00 --pty /bin/bash
You should be presented with a bash prompt. Note that the prompt may change
to reflect your new location, in this case the compute node we are logged on.
You can also verify this with hostname
.
Creating remote graphics
To see graphical output inside your jobs, you need to use X11 forwarding. To connect with this feature enabled, use the
-Y
option when you login withssh
with the commandssh -Y username@host
.If you are using a Mac, you must have installed XQuartz (and restarted your computer) for this to work.
If your cluster has the slurm-spank-x11 plugin installed, you can ensure X11 forwarding within interactive jobs by using the
--x11
option forsrun
with the commandsrun --x11 --pty bash
.
When you are done with the interactive job, type exit
to quit your session.
Running parallel jobs using MPI
As we have already seen, the power of HPC systems comes from parallelism, i.e. having lots of processors/disks etc. connected together rather than having more powerful components than your laptop or workstation. Often, when running research programs on HPC you will need to run a program that has been built to use the MPI (Message Passing Interface) parallel library. The MPI library allows programs to exploit multiple processing cores in parallel to allow researchers to model or simulate faster on larger problem sizes. The details of how MPI work are not important for this course or even to use programs that have been built using MPI; however, MPI programs typically have to be launched in job submission scripts in a different way to serial programs and users of parallel programs on HPC systems need to know how to do this. Specifically, launching parallel MPI programs typically requires four things:
- A special parallel launch program such as
mpirun
,mpiexec
,srun
oraprun
. - A specification of how many processes to use in parallel. For example, our parallel program may use 256 processes in parallel.
- A specification of how many parallel processes to use per compute node. For example, if our compute nodes each have 32 cores we often want to specify 32 parallel processes per node.
- The command and arguments for our parallel program.
To illustrate this process, we will use a simple MPI parallel program that sharpens an image.
(We will meet this example program in more detail in a later episode.) Here is a job submission
script that runs the sharpen program across two compute nodes on the cluster. Create a file
called run-sharpen.pbs
with the contents of this script in it.
#!/bin/bash
#SBATCH --partition=standard
#SBATCH --qos=standard
#SBATCH --time=00:05:00
#SBATCH --ntasks=16
#SBATCH --ntasks-per-node=16
module load epcc-job-env
module load training/sharpen/1.0
cp $SHARPEN_INPUT/fuzzy.pgm .
srun sharpen
The parallel launch line for the sharpen program can be seen towards the bottom of the script:
srun -cpu_bind=rank sharpen
and this corresponds to the four required items we described above:
- Parallel launch program: in this case the parallel launch program is
called
srun
; the additional argument controls which cores are used. - Total number of parallel processes: in this case this is 16 set
by the option
--ntasks=16
. - Number of parallel processes per node: in this case this is also 16,
and is specified by the option
--ntasks-per-node=16
option. - Our program and arguments: in this case this is
sharpen-mpi.x
.
As for our other jobs, we launch using the sbatch
command.
userid@uan01:~> sbatch run-sharpen.pbs
Submitted batch job 36855
If your job runs correctly, you should see an output file called
sharpened.pgm
userid@uan01:~> ls -l *.pgm
-rw-r--r-- 1 userid ta018 1762743 Jun 26 17:29 fuzzy.pgm
-rw------- 1 userid ta018 1678630 Jun 26 17:33 sharpened.pgm
If you only see fuzzy.pgm
and not sharpened.pgm
then look at
both the output and error files from SLURM to work out
what went wrong.
Running parallel jobs
Modify the sharpen script that you used above to use all 128 cores on one node. Check the output to confirm that it used the correct number of cores in parallel for the calculation.
Solution
Here is a modified script
#!/bin/bash #SBATCH --partition=standard #SBATCH --qos=standard #SBATCH --time=00:00:30 #SBATCH --ntasks=128 #SBATCH --ntasks-per-node=128 module load epcc-job-env module load training/sharpen/1.0 cp $SHARPEN_INPUT/fuzzy.pgm . srun --cpu_bind=rank sharpen-mpi.x
Configuring parallel jobs
You will see in the job output that information is displayed about where each MPI process is running, in particular which node it is on.
Modify the sharpen script that you run a total of 16 MPI tasks, but to use only 8 tasks on each of two nodes. Check the output file to ensure that you understand the job distribution.
Solution
#!/bin/bash #SBATCH --partition=standard #SBATCH --qos=standard #SBATCH --time=00:00:30 #SBATCH --ntasks=16 #SBATCH --ntasks-per-node=8 module load epcc-job-env module load training/sharpen/1.0 cp $SHARPEN_INPUT/fuzzy.pgm . srun --cpu_bind=rank sharpen-mpi.x
What do you think the job distribution will be if you run 16 processes with 7 processes per node? Does this agree with what you see in practice?
Key Points
The scheduler handles how compute resources are shared between users.
Everything you do should be run through the scheduler.
A job is just a shell script.
If in doubt, request slightly more resources than you will need.