| title | teaching | exercises | questions | objectives | keypoints | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Scheduler Fundamentals |
45 |
30 |
|
|
|
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 job do not start instantly as in your laptop.
{% include figure.html max-width="75%" caption="" file="/fig/restaurant_queue_manager.svg" alt="Compare a job scheduler to a waiter in a restaurant" %}
The scheduler used in this lesson is {{ site.sched.name }}. Although {{ site.sched.name }} 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.
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 a shell script -- essentially a text file containing a list of UNIX commands to be executed in a sequential manner. Our shell script will have three parts:
- On the very first line, add
{{ site.remote.bash_shebang }}. The#!(pronounced "hash-bang" or "shebang") tells the computer what program is meant to process the contents of this file. In this case, we are telling it that the commands that follow are written for the command-line shell (what we've been doing everything in so far). - Anywhere below the first line, we'll add an
echocommand with a friendly greeting. When run, the shell script will print whatever comes afterechoin the terminal.echo -nwill print everything that follows, without ending the line by printing the new-line character.
- On the last line, we'll invoke the
hostnamecommand, which will print the name of the machine the script is run on.
{{ site.remote.prompt }} nano example-job.sh
{: .language-bash}
{{ site.remote.bash_shebang }}
echo -n "This script is running on "
hostname
{: .output}
Run the script. Does it execute on the cluster or just our login node?
{{ site.remote.prompt }} bash example-job.sh{: .language-bash}
This script is running on {{ site.remote.host }}{: .output} {: .solution} {: .challenge}
This script ran on the login node, but we want to take advantage of
the compute nodes: we need the scheduler to queue up example-job.sh
to run on a compute node.
To submit this task to the scheduler, we use the
{{ site.sched.submit.name }} command.
This creates a job which will run the script when dispatched to
a compute node which the queuing system has identified as being
available to perform the work.
{{ site.remote.prompt }} {{ site.sched.submit.name }} {% if site.sched.submit.options != '' %}{{ site.sched.submit.options }} {% endif %}example-job.sh
{: .language-bash}
sbatch: Your job has no time specification (--time=) and the default time is short. You can cancel your job with 'scancel <JOB_ID>' if you wish to resubmit.
sbatch: Warning: It appears your working directory may not be on one of the work filesystem. It is /mnt/cephfs/ceph01/site-home/home/tc036/tc036/nkg85-whpc. The home filesystem is not available from the compute nodes - please check that this is what you intended. You can cancel your job with 'scancel <JOBID>' if you wish to resubmit.
Submitted batch job 3934401
{: .output}
Ah! What went wrong here? Slurm is telling us that the file system we are currently on, /home, is not available
on the compute nodes and that we are getting the default, short runtime. We will deal with the runtime properly
later, but we need to move to a different file system to submit the job and have it visible to the
compute nodes. On Cirrus, this is the /work file system. The path is similar to home but with
/work at the start. Lets move there now, copy our job script across and resubmit:
{{ site.remote.prompt }} cd /work/tc036/tc036/yourUsername
{{ site.remote.prompt }} cp ~/example-job.sh .
{{ site.remote.prompt }} {{ site.sched.submit.name }} {{ site.sched.submit.options }} --time=00:00:10 example-job.sh
{: .language-bash}
Submitted batch job 3934430
{: .output}
That's better! 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
{{ site.sched.status }} {{ site.sched.flag.user }}.
{{ site.remote.prompt }} {{ site.sched.status }} {{ site.sched.flag.user }}
{: .language-bash}
{% include {{ site.snippets }}/scheduler/basic-job-status.snip %}
On the login node, this script printed output to the terminal -- but now, when
{{ site.sched.status }}shows the job has finished, nothing was printed to the terminal.Cluster job output is typically redirected to a file in the directory you launched it from. Use
lsto find andcatto read the file.On some HPC systems you may need to redirect the output explictly in your job submission script. You can achieve this by setting the options for error
--error=<error_filename>and output--output=<output_filename>filenames with#SBATCHin your job script. On Cirrus this is handled by default with output and error files named according to the job submission id.
{: .discussion}
The job we just ran 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, 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
{{ site.local.bash_shebang }}). Schedulers like {{ site.sched.name }} also
have a special comment used to denote special scheduler-specific options.
Though these comments differ from scheduler to scheduler,
{{ site.sched.name }}'s special comment is {{ site.sched.comment }}. Anything
following the {{ site.sched.comment }} comment is interpreted as an
instruction to the scheduler.
Let's illustrate this by example. By default, a job's name is the name of the
script, but the {{ site.sched.flag.name }} option can be used to change the
name of a job. Add an option to the script:
{{ site.remote.prompt }} cat example-job.sh
{: .language-bash}
{{ site.remote.bash_shebang }}
{{ site.sched.comment }} {{ site.sched.flag.name }}=hello-world
echo -n "This script is running on "
hostname
{: .output}
Submit the job and monitor its status:
{{ site.remote.prompt }} {{ site.sched.submit.name }} {% if site.sched.submit.options != '' %}{{ site.sched.submit.options }} {% endif %} --time=00:00:10 example-job.sh
{{ site.remote.prompt }} {{ site.sched.status }} {{ site.sched.flag.user }}
{: .language-bash}
{% include {{ site.snippets }}/scheduler/job-with-name-status.snip %}
Fantastic, we've successfully changed the name of our job!
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.
{% include {{ site.snippets }}/scheduler/option-flags-list.snip %}
Note that just requesting these resources does not make your job run faster, nor does it necessarily mean that you will consume all of these resources. It only means that these are made available to you. Your job may end up using less memory, or less time, or fewer nodes than you have requested, and it will still run.
It's best if your requests accurately reflect your job's requirements. We'll talk more about how to make sure that you're using resources effectively in a later episode of this lesson.
All of the options we specify can be supplied on the command line (as we do here for
--partition=standardand--qos=standard) or in the job script (as we have done for the job name above). These are interchangeable. It is often more convenient to put the options in the job script as it avoids lots of typing at the command line. {: .callout}
Modify our
hostnamescript so that it runs for a minute, then submit a job for it on the cluster. You should also move all the options we have been specifying on the command line (e.g.--partitionand--qos) into the script at this point.{{ site.remote.prompt }} cat example-job.sh{: .language-bash}
{{ site.remote.bash_shebang }} {{ site.sched.comment }} --partition=standard {{ site.sched.comment }} --qos=standard {{ site.sched.comment }} {{ site.sched.flag.time }}=00:01 # timeout in HH:MM echo -n "This script is running on " sleep 20 # time in seconds hostname{: .output}
{{ site.remote.prompt }} {{ site.sched.submit.name }} example-job.sh{: .language-bash}
Why are the {{ site.sched.name }} runtime and
sleeptime not identical? {: .solution} {: .challenge}
{% include {{ site.snippets }}/scheduler/print-sched-variables.snip %}
Resource requests are typically binding. If you exceed them, your job will be killed. Let's use wall time as an example. We will request 1 minute of wall time, and attempt to run a job for two minutes.
{{ site.remote.prompt }} cat example-job.sh
{: .language-bash}
{{ site.remote.bash_shebang }}
{{ site.sched.comment }} --partition=standard
{{ site.sched.comment }} --qos=standard
{{ site.sched.comment }} {{ site.sched.flag.name }}=long_job
{{ site.sched.comment }} {{ site.sched.flag.time }}=00:01 # timeout in HH:MM
echo "This script is running on ... "
sleep 240 # time in seconds
hostname
{: .output}
Submit the job and wait for it to finish. Once it is has finished, check the log file.
{{ site.remote.prompt }} {{ site.sched.submit.name }} example-job.sh
{{ site.remote.prompt }} {{ site.sched.status }} {{ site.sched.flag.user }}
{: .language-bash}
{% include {{ site.snippets }}/scheduler/runtime-exceeded-job.snip %}
{% include {{ site.snippets }}/scheduler/runtime-exceeded-output.snip %}
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, {{ site.sched.name }} 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.
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. {: .callout}
Sometimes we'll make a mistake and need to cancel a job. This can be done with
the {{ site.sched.del }} 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!).
{{ site.remote.prompt }} {{ site.sched.submit.name }} example-job.sh
{{ site.remote.prompt }} {{ site.sched.status }} {{ site.sched.flag.user }}
{: .language-bash}
{% include {{ site.snippets }}/scheduler/terminate-job-begin.snip %}
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.
{{ site.remote.prompt }} {{site.sched.del }} 3936036
# It might take a minute for the job to disappear from the queue...
{{ site.remote.prompt }} {{ site.sched.status }} {{ site.sched.flag.user }}
{: .language-bash}
{% include {{ site.snippets }}/scheduler/terminate-job-cancel.snip %}
{% include {{ site.snippets }}/scheduler/terminate-multiple-jobs.snip %}
Up to this point, we've focused on running jobs in batch mode. {{ site.sched.name }} 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 {{ site.sched.interactive }}.
{% include {{ site.snippets }}/scheduler/using-nodes-interactively.snip %}
{% include links.md %}