HPC Documentation

Guides, references, and tutorials for the WCM cluster

Resource Requests: CPUs, Memory, GPUs

Resource Requests: CPUs, Memory, and GPUs

Correct resource requests help your jobs start sooner and keep the cluster fair for everyone.

CPU Request Scenarios

ScenarioRecommended Request
Single-threaded process--ntasks=1 --cpus-per-task=1
Multi-threaded process using 16 threads--ntasks=1 --cpus-per-task=16
16 isolated processes, 1 thread each--ntasks=16 --nodes=1
16 isolated processes, 2 threads each--ntasks=16 --nodes=1 --cpus-per-task=2

What the Main Flags Mean

  • --cpus-per-task: threads per task
  • --ntasks: number of tasks or processes
  • --nodes: number of nodes across which tasks may be distributed

Unless you are using MPI, job steps, or many truly separate concurrent tasks, most jobs should use --ntasks=1 and scale with --cpus-per-task.

Memory Guidelines

If you have run the job before, use sacct to compare requested memory to actual maximum memory use.

sacct -S $(date -d "-7 days" +%D) --state=CD -o "user,JobID,JobName,ReqMem,MaxRSS,state,exit"

If you have never run the job before, start conservatively and adjust upward only as needed.

GPU Requests

On SCU systems, GPU requests are typically made with a GRES request such as:

--gres=gpu:1

Slurm supports site-defined GRES for GPUs and other generic resources.

Script Examples

CPU-only Job

#!/bin/bash -l
#SBATCH --partition=scu-cpu
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=02:00:00

python analysis.py

GPU Training Job

#!/bin/bash -l
#SBATCH --partition=scu-gpu
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --gres=gpu:1
#SBATCH --time=24:00:00

python train.py

Why Accurate Requests Matter

  • Over-requesting resources slows down queue movement.
  • Under-requesting memory may cause immediate job termination.
  • Unused resources still count against scheduling profiles and fairshare priority.

SCU High-Performance Computing Technical Documentation — 2026