Slurm accounts, QOS and limits¶
The state of the Phoebe accounting database in September 2026. Check the current values with
sacctmgr show qos and sacctmgr show assoc.
Accounts¶
All accounts hang directly under root with a fair-share weight of 1, and default to the
normal QOS.
| Account | Who | Users |
|---|---|---|
fzu_a_16 |
FZU division 16 | 8 |
fzu_a_29 |
FZU division 29 | 13 |
fzu_a_39 |
FZU division 39 | 32 |
ext_ceico |
external collaborators of CEICO | 8 |
ext_fzu |
external collaborators of FZU | 3 |
fzu_project001 |
one special project | 1 |
The accounts are only for internal accounting. The admin picks the account when adding a new
user: the user's FZU division, or ext_ceico / ext_fzu for people from outside FZU. Users
don't need to know their account or pass --account to their jobs.
Two associations in fzu_a_29 have their own group GPU limits: GrpTRES=gres/gpu=8 and
GrpTRES=gres/gpu=4.
QOS¶
| QOS | Priority | Per-user limit | Per-job limit | Associations with it as default |
|---|---|---|---|---|
normal |
256 | 16 A100 GPUs (gres/gpu:a100=16), 3000 running jobs |
- | 60 |
manyjobs |
100 | 128 CPUs, 3000 running jobs; flag OverPartQOS |
- | 1 |
newbie |
500 | 5 running jobs | - | 0 |
max400cpu |
0 | 3000 CPUs | - | 2 |
max500cpu |
0 | 1 CPU | - | 1 |
max64cpu |
0 | 64 CPUs | - | 0 |
| one per-user QOS (named after its user) | 0 | 128 CPUs | - | 0 |
gpu_max2 |
0 | 3 GPUs | 16 CPUs, 3 GPUs, 504 GB | 2 |
In the last 90 days, 20 042 jobs ran with normal, 64 with max400cpu and 10 with gpu_max2.
Add a user¶
Create the user in the accounting database and add them to an account:
The user gets the account's default QOS, normal.
Give a user another QOS¶
Allow the QOS and make it the user's default:
Use qos+= instead of qos= to add a QOS without removing the others. Jobs already in the
queue keep their old QOS; change them one by one:
Create a QOS with a per-user limit¶
For example, at most 400 CPUs per user:
Change the per-user GPU limit¶
The GPU limit for everyone lives in the normal QOS: