CODEWITHSUNDEEP
slurm
Cyclone
Cyclone

Reputation: 2133

parallel but different Slurm srun job step invocations not working

I'd like to run the same program on a large number of different input files. I could just submit each as a separate Slurm submission, but I don't want to swamp the queue by dumping 1000s of jobs on it at once. I've been trying to figure out how to process the same number of files by instead creating an allocation first, then within that allocation looping over all the files with srun, giving each invocation a single core from the allocation. The problem is that no matter what I do, only one job step runs at a time. The simplest test case I could come up with is:

#!/usr/bin/env bash

srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &

wait

It doesn't matter how many cores I assign the allocation:

time salloc -n 1 test
time salloc -n 2 test
time salloc -n 4 test

it always takes 4 seconds. Is it not possible to have multiple job steps execute in parallel?

Upvotes: 9

Views: 11009

Answers (3)

Isabella
Isabella

Reputation: 401

Since the OP solved his issue but didn't provide the code, I'll share my take on this problem below.

In my case, I encountered the error/warning step creation temporarily disabled, retrying (Requested nodes are busy). This is because, the srun command that executed first, allocated all the memory. The same cause as encountered by the OP. To solve this, one first optionally(?) specify the total memory allocation for sbatch (if you are using an sbatch script):

#SBATCH --ntasks=4
#SBATCH --mem=[XXXX]MB

And then specify the memory use per srun task:

srun --exclusive --ntasks=1 --mem-per-cpu [XXXX/4]MB sleep 1 &
srun --exclusive --ntasks=1 --mem-per-cpu [XXXX/4]MB sleep 1 &
srun --exclusive --ntasks=1 --mem-per-cpu [XXXX/4]MB sleep 1 &
srun --exclusive --ntasks=1 --mem-per-cpu [XXXX/4]MB sleep 1 &
wait

I didn't specify CPU count for srun because in my sbatch script I included #SBATCH --cpus-per-task=1. For the same reason I suspect you could use --mem instead of --mem-per-cpu in the srun command, but I haven't tested this configuration.

Upvotes: 4

Cyclone
Cyclone

Reputation: 2133

It turned out to be that the default memory per cpu was not defined, so even single core jobs were running by reserving all the node's RAM.

Setting DefMemPerCPU, or specifying explicit RAM reservations did the trick.

Upvotes: 9

damienfrancois
damienfrancois

Reputation: 59330

Beware that in that scenario, you measure both the running time and the waiting time. Your submission script should look like this:

#!/usr/bin/env bash

time {
srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &
srun --exclusive --ntasks 1 -c 1 sleep 1 &
wait
}

and simply submit with 

salloc -n 1 test
salloc -n 2 test
salloc -n 4 test

You then should observe the difference, along with messages such as srun: Job step creation temporarily disabled, retrying when using n<4.

Upvotes: 5

Related Questions