|
2 | 2 | # SLURM |
3 | 3 |
|
4 | 4 | CSCS uses the [SLURM](https://slurm.schedmd.com/documentation.html) as its workload manager to efficiently schedule and manage jobs on Alps vClusters. |
5 | | -SLURM is an open-source, highly scalable job scheduler that allocates computing resources, queues user jobs, and optimizes workload distribution across the cluster. It supports advanced scheduling policies, job dependencies, resource reservations, and accounting, making it well-suited for high-performance computing environments. |
| 5 | +SLURM is an open-source, highly scalable job scheduler that allocates computing resources, queues user jobs, and optimizes workload distribution across the cluster. |
| 6 | +It supports advanced scheduling policies, job dependencies, resource reservations, and accounting, making it well-suited for high-performance computing environments. |
| 7 | + |
| 8 | +<div class="grid cards" markdown> |
| 9 | + |
| 10 | +- :fontawesome-solid-mountain-sun: __Running on nodes__ |
| 11 | + |
| 12 | + Specific guidance for configuring Slurm jobs on different node types. |
| 13 | + |
| 14 | + [:octicons-arrow-right-24: GH200 nodes (Daint, Clariden, Santis)][ref-slurm-gh200] |
| 15 | + |
| 16 | + [:octicons-arrow-right-24: AMD CPU-only nodes (Eiger)][ref-slurm-amdcpu] |
| 17 | + |
| 18 | +- :fontawesome-solid-mountain-sun: __Node sharing__ |
| 19 | + |
| 20 | + Guides on how to effectively use all resouces on nodes by running more than one job per node. |
| 21 | + |
| 22 | + [:octicons-arrow-right-24: Node sharing][ref-slurm-sharing] |
| 23 | + |
| 24 | + [:octicons-arrow-right-24: Multiple MPI jobs per node][ref-slurm-exclusive] |
| 25 | + |
| 26 | +</div> |
6 | 27 |
|
7 | 28 | ## Accounting |
8 | 29 |
|
@@ -148,3 +169,83 @@ The configuration that is optimal for your application may be different. |
148 | 169 |
|
149 | 170 | !!! todo |
150 | 171 | document how slurm is configured on AMD CPU nodes (e.g. eiger) |
| 172 | + |
| 173 | +[](){#ref-slurm-over-subscription} |
| 174 | +## Node over-subscription |
| 175 | + |
| 176 | +The nodes on Alps provide a lot of resources, particularly the GPU nodes that have 4 GPUs. |
| 177 | +For workflows and use cases with tasks that require only a subset of these resources, for example a simulation that only needs one GPU, allocating a whole node to run one task is a waste of resources. |
| 178 | + |
| 179 | +!!! example |
| 180 | + A workflow that runs a single [GROMACS][ref-uenv-gromacs] simulation, that uses one GPU. |
| 181 | + |
| 182 | + * The optimal use of resources would allocate one quarter of a node, and allow other jobs to access the other three GPUs. |
| 183 | + |
| 184 | + A workflow that runs 100 independent [GROMACS][ref-uenv-gromacs] simulations, where each simulation requires two GPUs. |
| 185 | + |
| 186 | + * The optimal use of resources would allocate 50 nodes, with two simulations run on each node. |
| 187 | + |
| 188 | +[](){#ref-slurm-sharing} |
| 189 | +### Node sharing |
| 190 | + |
| 191 | +!!! under-construction |
| 192 | + Node sharing, whereby jobs can request part of the resources on a node, and multiple jobs can run on a node (possibly from different users) is _not currently available on Alps clusters_. |
| 193 | + |
| 194 | + CSCS will support this feature on some Alps [clusters][ref-alps-clusters] in the near-medium future. |
| 195 | + |
| 196 | +[](){#ref-slurm-exclusive} |
| 197 | +### Running more than one MPI job per node |
| 198 | + |
| 199 | +The approach is to: |
| 200 | + |
| 201 | +1. first allocate all the resources on each node to the job; |
| 202 | +2. then subdivide those resources at each invocation of srun. |
| 203 | + |
| 204 | +If slurm believes that a request for resources (cores, gpus, memory) overlaps with what another step has already allocated, it will defer the execution until the resources are relinquished. |
| 205 | + |
| 206 | +First ensure that *all* resources are allocated to the whole job with the following preamble: |
| 207 | + |
| 208 | +```bash title="Slurm preamble on a GH200 node" |
| 209 | +#!/usr/bin/env bash |
| 210 | +#SBATCH --exclusive --mem=450G |
| 211 | +``` |
| 212 | + |
| 213 | +* `--exclusive` allocates all the CPUs and GPUs; |
| 214 | +* `--mem=450G` most of allowable memory (there are 4 Grace CPUs with ~120 GB of memory on the node) |
| 215 | + |
| 216 | +!!! note |
| 217 | + `--mem=0` can be used to allocate all memory on the node, however there is currently a configuration issue that causes this to fail. |
| 218 | + |
| 219 | +`--exclusive` has two different meanings depending on whether it's used in the job context (here) or in the job step context (srun). We need to use both. |
| 220 | + |
| 221 | +!!! todo "use [affinity](https://github.com/bcumming/affinity) for these examples" |
| 222 | + |
| 223 | +=== "single node" |
| 224 | + |
| 225 | + !!! example "three jobs on one node" |
| 226 | + ```bash |
| 227 | + #!/usr/bin/env bash |
| 228 | + #SBATCH --exclusive --mem=450G |
| 229 | + #SBATCH -N1 |
| 230 | + |
| 231 | + srun -n1 --exclusive --gpus=2 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 232 | + srun -n1 --exclusive --gpus=1 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 233 | + srun -n1 --exclusive --gpus=1 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 234 | + |
| 235 | + wait |
| 236 | + ``` |
| 237 | + |
| 238 | +=== "multi-node" |
| 239 | + |
| 240 | + !!! example "three jobs on two nodes" |
| 241 | + ```bash |
| 242 | + #!/usr/bin/env bash |
| 243 | + #SBATCH --exclusive --mem=450G |
| 244 | + #SBATCH -N2 |
| 245 | + |
| 246 | + srun -N2 -n2 --exclusive --gpus-per-task=1 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 247 | + srun -N2 -n1 --exclusive --gpus-per-task=1 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 248 | + srun -N2 -n1 --exclusive --gpus-per-task=1 --cpus-per-gpu=5 --mem=50G bash -c "echo JobStep:\${SLURM_STEP_ID}" |
| 249 | + |
| 250 | + wait |
| 251 | + ``` |
0 commit comments