Scheduling Basics — Magus02 HPC

📍 Magus02 Knowledge Base → Basics → Scheduling Basics

This page explains the fundamental concepts behind batch scheduling on HPC clusters. For specific Slurm commands and job types, see Batch Scheduler.

What is a Batch Scheduler?

On Magus02, users do not run calculations directly and interactively on the compute nodes (as they would on a laptop). Instead, they submit batch jobs to the Slurm scheduler.

The scheduler:

• Stores submitted jobs in a queue
• Evaluates each job's resource requirements and priority
• Distributes jobs to suitable compute nodes when resources are available
• Manages all 57+ compute nodes making up 98%+ of the cluster

The login nodes are for compiling code, editing files, and submitting jobs. The compute nodes (accessed only through the scheduler) are where actual computation happens.

⚠️ Do not run compute jobs on login nodes. Heavy workloads on login nodes slow the system for all users and may result in your processes being killed. Always use Slurm for anything that takes more than a few seconds.

How a Batch Job Works

1. You write a jobscript — a shell script containing your commands and resource requests
2. You submit it with sbatch jobscript.sh
3. Slurm adds it to a queue and waits for enough free resources
4. When resources become available, Slurm runs your job on compute nodes
5. Output is written to files you specified in the script

You specify three key resources:

Resource	Slurm Flag	Description
Time	--time=HH:MM:SS	Maximum runtime. Job is killed if it exceeds this.
Cores	--ntasks or --cpus-per-task	Number of CPU cores needed.
Memory	--mem=XG or --mem-per-cpu=XG	RAM needed. Job may crash or not start if underspecified.

Scheduling Algorithms

Modern schedulers like Slurm use a combination of strategies:

First Come, First Served (FCFS)

Jobs run in the order they were submitted. Simple and fair, but small jobs can wait behind large ones unnecessarily.

Shortest Job First

Jobs with shorter declared runtimes get priority. Very long-running jobs may be delayed significantly.

Backfilling

Slurm's default strategy. It maintains FCFS priority but allows shorter jobs to fill gaps in the schedule without delaying higher-priority jobs. This means short jobs typically see short wait times even when the cluster is busy.

To benefit from backfilling, request an accurate runtime — not too long (wastes priority) and not too short (job gets killed before finishing).

Magus02 Queue Structure

Queue	Processor	Min Cores	Max Cores	Max Nodes	Wall Time	Max Cores/User	Max Pending	Max Running
medium	AMD EPYC 7763	32	128	77	1 week	512	2	2
small	AMD EPYC 7043	8	32	16	1 month	128	2	4
high_mem	AMD EPYC 7543	32	256	12	2 weeks	1024	2	2
large	AMD EPYC 7763	64	256	24	2 weeks	1024	2	2
GPU	Intel Xeon Platinum 8368	16	16	4	1 week	32	2	2
low/long	AMD EPYC 7763	32	1024	All	1 month	1024	2	8

✅ Queue selection guide:

• Testing / debugging → small
• Standard multi-node runs → medium
• Large production jobs → large
• Gaussian / large in-memory apps → high_mem
• GPU workloads (CUDA) → GPU
• Long, low-priority jobs → low/long

References

• Batch Scheduler — Job Submission Guide
• FAQ: Batch Jobs
• Magus02 Main Page — Queue Details

---

↑ Back to Knowledge Base · Maintained by HPC Administration · wiki.snu.edu.in