Over Efficient Jobs

Owned by Gaby Rodriguez
Last updated: Feb 28, 2023
4 min read

If you received an email with the subject line "O2 Overefficient Jobs" and you're not sure why or how, then you're in the right place. 

Quick Overefficiency Example

An overefficient job uses more CPUs or Threads than you requested for the job. For example, 

#!/bin/bash #SBATCH -p short #SBATCH -t 0-01:00 #SBATCH -c 4 bowtie -p 10 -S hg19 -1 read1.fastq -2 read2.fastq myalign.sam

In the above sbatch script, the multithreading option in the bowtie command (-p 10) does not match the number of requested threads for the sbatch job (#SBATCH -c 4).

X bowtie -p 10 -S hg19 -1 read1.fastq -2 read2.fastq myalign.sam



In order to fix it, you can simply adjust the value of the argument -p to match the value specified in #SBATCH -c

✔ bowtie -p 4 -S hg19 -1 read1.fastq -2 read2.fastq myalign.sam



NOTE: The particular letter or word used for the multithreading option depends on the particular software tool. It's -p for bowtie and -num_threads for blast. Some programs can't  multithread at all, in which case requesting multiple cores from SLURM will simply wasting resources and increase your pending time.

What is Job Efficiency?

Job efficiency is the amount of CPU resources a job uses compared to the amount of CPU resources you requested for the job (with #SBATCH -c or srun -c). Ideally, these will be equal, and the efficiency will be approximately 1.

Why is Job Efficiency Important?

O2 has dozens of cores per node. In general, each core can run a single process/thread. The SLURM scheduler dispatched (assigns) jobs to nodes based on the number of cores requested, as well as the amount of memory required (plus other criteria specified in a user's sbatch command). Multiple jobs by different users often run on the same node, so one user's job may negatively impact another user's job.

Efficiency Categories

A SLURM job can fall in one of three categories 

  1. Efficient - If the number of active threads started within the job matches the number of requested CPU cores and the efficiency is close to 100%, the process and its threads are efficiently using the allocated resources. 


  2. Overefficient - If the process starts more threads than the number of cores allocated. The efficiency won't exceed 100% because a linux kernel feature called cgroups forces all the parallel threads to access only the allocated cores. However, the parallel threads are now fighting for the same, under-allocated CPU resource. Therefore any parallelization advantage is lost, and the job is actually running slower because it's paying the negative cost of parallelization without receiving any positive bene