Document Actions
90 Tips & tricks
Up to Table of Contents
Basics
A queuing system (also called a batch system) is a set of system services that takes care of running tasks submitted by the users on the compute nodes. Each task, or job as we prefer to call them, is simply a shell script that can contain some directives on what resources a job needs to run properly. You do not need to put the directives in the script you can also provide them on the command line to the submit command qsub.
So, you submit your jobscript with the qsub command and specify what resources you expect your job needs. These resources are basically about how many cpus, how much memory needed and how long the job will need to run to complete. If you do not specify a parameter you will get the system default which as of this writing is
| Type | Default | Flag |
|---|---|---|
| CPUS | 1 | -lnodes |
| Memory | 499MB | -lpmem |
| Walltime | 48 hours | -lwalltime |
Example
A job that needs to run for 12 hours using 16 cpus and needs 1000MB memory per cpu could be submitted like this:
qsub -lnodes=16,pmem=1000mb,walltime=16:00:00 jobscript.sh
or, by putting the directives into the jobscript.sh:
#PBS -lnodes=16 #PBS -lpmem=1000mb #PBS -lwalltime=16:00:00
The directives needs to at the beginning of the job script before you start executing commands. You will find links to more info at the bottom of this page.
General recommendations on job parameters
Walltime
We recommend you to be as precise as you can when specifying the parameters as they will inflict on how fast your jobs will start to run we generally have these two rules for prioritizing jobs:
- Large jobs, that is jobs with high cpucounts, are prioritized.
- Short jobs take precedence over long jobs.
Cpucount
You should run a few tests to see what is the best fit between minimizing runtime and maximizing your allocated cpu-quota. That is you should not ask for more cpus for a job than you really can utilize efficiently. Try to run your job on 1,2,4,8,16 cpus and so on to see when the runtime for your job starts tailing off. When you start to see less than 30% improvement in runtime when doubling the cpu-counts you should probably not go any further. We have started to make some recommendations on much used applications here.
