Customising a job
Instructor note
Total: 75min (Teaching:45Min | Discussion:0min | Breaks:0min | Exercises:30Min)
Objectives
Objectives
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.
The job we just ran used all 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, more memory, more time, among other special considerations. To get access to these resources we must customize our job script.
Comments in UNIX shell scripts (denoted by #
) are typically ignored, but there are exceptions.
For instance the special #!
comment at the beginning of scripts specifies what program should be
used to run it (you’ll typically see #!/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.
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 you want.
The following are several key resource requests:
Discussion
--ntasks=<ntasks>
or-n <ntasks>
: How many CPU cores does your job need, in total?--time <days-hours:minutes:seconds>
or-t <days-hours:minutes:seconds>
: How much real-world time (walltime) will your job take to run? Thepart can be omitted. --mem=<megabytes>
: How much memory on a node does your job need in megabytes? You can also specify gigabytes using by adding a little “g” afterwards (example: –mem=5g)--nodes=<nnodes>
or-N <nnodes>
: How many separate machines does your job need to run on? Note that if you set ntasks to a number greater than what one machine can offer, Slurm will set this value automatically.
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.
Discussion
Discuss the commands
scontrol
sacct
Examples
Submit a job that will use 1 full node and 1 minute of walltime.
[MY_USER_NAME@CLUSTER_NAME ~ ]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1 --exclusive
#SBATCH --time=00:01:00
echo -n "This script is running on "
sleep 60 # time in seconds
hostname
echo "This script has finished successfully."
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch --account=<PROJECT_NAME> --mem=1G example-job.sh
Print a SLURM variable. Move more arguments to the job script
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=<PROJECT_NAME>
#SBATCH --qos=preproc
#SBATCH --mem=1G
echo -n "This script is running on "
hostname
echo "This job was launched in the following directory:"
echo ${SLURM_SUBMIT_DIR}
Binding resource request
Resource requests are typically binding. If you exceed them, your job will be killed. Let’s use walltime as an example. We will request 60 seconds of walltime, and attempt to run a job for two minutes.
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=<PROJECT_NAME>
#SBATCH --qos=preproc
#SBATCH --mem=1G
#SBATCH --job-name=long_job
echo -n "This script is running on ... "
sleep 120 # time in seconds
hostname
echo "This script has finished successfully."
Submit the job and wait for it to finish. Once it is has finished, check the log file.
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch example-job.sh
[MY_USER_NAME@CLUSTER_NAME ~]$ watch -n 15 squeue -u $USER
....
[MY_USER_NAME@CLUSTER_NAME ~]$ cat slurm-38193.out
This job is running on: c1-14
slurmstepd: error: *** JOB 38193 ON gra533 CANCELLED AT 2021-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 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.
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!).
Warning
Please make sure to cancel the job you submited with the correct jobid (copy pasting the jobid in the example would not work
[MY_USER_NAME@CLUSTER_NAME ~]$ cat example-job.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --time=00:01:00
#SBATCH --account=<PROJECT_NAME>
#SBATCH --qos=preproc
#SBATCH --mem=1G
#SBATCH --job-name=long_job
echo -n "Script has started ... "
sleep 300 # time in seconds
[MY_USER_NAME@CLUSTER_NAME ~]$ sbatch example-job.sh
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
Submitted batch job 38759
JOBID ACCOUNT NAME ST REASON TIME TIME_LEFT NODES CPUS
38759 PROJECT_NAME example-job.sh PD Priority 0:00 1:00 1 1
Now cancel the job with its job number (printed in your terminal). A clean return of your command prompt indicates that the request to cancel the job was successful.
[MY_USER_NAME@CLUSTER_NAME ~]$ scancel 38759
# ... Note that it might take a minute for the job to disappear from the queue ...
[MY_USER_NAME@CLUSTER_NAME ~]$ squeue -u $USER
JOBID USER ACCOUNT NAME ST REASON START_TIME TIME TIME_LEFT NODES CPUS