Difference between revisions of "Complex submissions"

From IBERS Bioinformatics and HPC Wiki
Jump to: navigation, search
Line 25: Line 25:
 
Most of this was not really required for the actual job (e.g. getting the hostname and uptime from each machine). However it is good practice to include limits for sun grid engine to work well.  
 
Most of this was not really required for the actual job (e.g. getting the hostname and uptime from each machine). However it is good practice to include limits for sun grid engine to work well.  
  
'''Sun Grid Engine and Limits'''
+
== Sun Grid Engine and Limits ==
  
 
Sun Grid Engine does not know what you're attempting to do until you tell it. There are three pieces of information that the scheduler needs to best load balance your job in the queue. It needs to know how much memory you need, how many CPU cores (also known as slots) and how long the job is expected to run for. This information is passed to the scheduler from your grid engine script. If you fail to specify the number of cpu cores, memory or time required, it will use the scheduler defaults, which may not be the best for your task.
 
Sun Grid Engine does not know what you're attempting to do until you tell it. There are three pieces of information that the scheduler needs to best load balance your job in the queue. It needs to know how much memory you need, how many CPU cores (also known as slots) and how long the job is expected to run for. This information is passed to the scheduler from your grid engine script. If you fail to specify the number of cpu cores, memory or time required, it will use the scheduler defaults, which may not be the best for your task.

Revision as of 11:37, 14 July 2014

In Submitting your job using SGE we looked at the following script;

   
#specify the shell type
#$ -S /bin/sh

#run in the current working directory
#$ -cwd

#specify that the job will be killed if it uses over 2G or total memory or run for more than 1.5hours.
#indicate that the program should run for 1 hour and use 1G of total memory
#run times are given in seconds, or could alternatively use the format hh:mm:ss (notice I've used both formats)
#$ -l s_vmem=1G 
#$ -l h_vmem=2G 
#$ -l s_rt=3600
#$ -l h_rt=01:30:00

#specify which queue you wish to use
#$ -q amd.q

#run a program command to print hostname and uptime
hostname && uptime
    

Most of this was not really required for the actual job (e.g. getting the hostname and uptime from each machine). However it is good practice to include limits for sun grid engine to work well.

Sun Grid Engine and Limits

Sun Grid Engine does not know what you're attempting to do until you tell it. There are three pieces of information that the scheduler needs to best load balance your job in the queue. It needs to know how much memory you need, how many CPU cores (also known as slots) and how long the job is expected to run for. This information is passed to the scheduler from your grid engine script. If you fail to specify the number of cpu cores, memory or time required, it will use the scheduler defaults, which may not be the best for your task.

Requesting Memory

Requesting memory is achieved by using the h_vmem limit in your script, like so;

   
#$ -l h_vmem=40G
    

This will request 40G of RAM from the available nodes in the queue you've submitted it to. For information about the specification of the nodes available, please see Bert and Ernie - An Overview.

If you submit a job requesting more memory than is available on a single node in the queue then your job will fail to run. e.g. If you submit a job requiring 512GB RAM to the intel queue, it will fail to run as the maximum amount of memory a node has in the intel queue is 192GB.

If your job uses more memory than you've requested, your job will fail.

Requesting Time

Requesting memory is achieved by using the h_rt limit in your script, like so;

   
#$ -l h_rt=3600
    

This will tell the scheduler that the job will take 24hours to run (3600 seconds).

Requesting CPU Cores

SGE Defaults