[資源管理] Slurm QoS (Quality of Service)

[資源管理] Slurm QoS (Quality of Service) === ###### tags: `Slurm / 資源管理` ###### tags: `Slurm`, `HPC`, `Linux`, `Slinky`, `SlinkyProject`, `Account`, `Accounting`, `SlurmDBD`, `Account`, `Association`, `Partition`, `QoS`, `ResourceLimits`, `TRES`, `Priority`, `Preemption`, `sacctmgr`, `scontrol`, `sbatch`, `srun`, `salloc`, `squeue`, `sinfo` [TOC] ## docs - [[TWCC] Slurm 佇列 (Partition)](https://man.twcc.ai/@f1-manual/partition) - 每位用戶可同時執行工作數 - 每位用戶可派送工作數 - [[TWCC] 12. 服務品質 (QOS)](https://man.twcc.ai/@f1-manual/slurm_instructions#12-%E6%9C%8D%E5%8B%99%E5%93%81%E8%B3%AA-QOS) --- ## 介紹  > - codebase: https://github.com/SchedMD/slurm > - by `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/01/27) ### 什麼是 QoS？ **QoS (Quality of Service)** 是 Slurm 中用來**控制和限制資源使用**的機制。它可以設定不同的服務等級，對不同用戶、群組或專案提供差異化的資源存取策略。 > 正確應為：對不同 user、account 或 partition 提供差異化的資源存取策略 ### 主要用途 1. **資源配額管理** - 限制 CPU、記憶體、節點數量等 2. **優先權控制** - 決定作業排程順序 3. **公平性保證** - 確保資源公平分配 4. **服務分級** - 提供高級/標準/經濟等不同服務等級 ### 如何使用？ #### 1. 建立 QoS ```bash # 建立一個名為 high_priority 的 QoS sacctmgr add qos high_priority # 建立帶參數的 QoS sacctmgr add qos normal \ Priority=100 \ MaxWall=24:00:00 \ MaxJobsPerUser=10 \ MaxSubmitJobsPerUser=50 ``` #### 2. 查看 QoS ```bash # 列出所有 QoS sacctmgr show qos # 查看特定 QoS 詳細資訊 sacctmgr show qos normal format=name,priority,maxwall,maxjobspu ``` #### 3. 套用 QoS QoS 可以套用到： - **使用者 (User)** - **帳號/專案 (Account)** - **分區 (Partition)** ```bash # 套用到使用者 sacctmgr modify user username set qos=high_priority # 套用到帳號 sacctmgr modify account projectA set qos=normal # 套用到分區（在 slurm.conf） # PartitionName=gpu QoS=gpu_qos ``` #### 4. 使用者提交作業時指定 QoS ```bash # 使用特定 QoS 提交作業 sbatch --qos=high_priority job_script.sh # 或在腳本中指定 #SBATCH --qos=high_priority ``` ### 不同場景設定案例 - ### 場景 1：研究團隊分級服務 **需求**：提供三種服務等級 - VIP/標準/經濟 ```bash # 1. VIP - 高優先權，長時間，多資源 sacctmgr add qos vip \ Priority=1000 \ MaxWall=7-00:00:00 \ MaxCPUsPerUser=512 \ MaxJobsPerUser=20 \ Preempt=normal,economy # --- # 使用 Preempt，要先設定 normal 和 economy 的 QoS # 否則會有錯誤訊息： # sacctmgr: error: You gave a bad qos 'normal'. Valid QOS's are (null) # 2. 標準 - 中等優先權，適中限制 sacctmgr add qos normal \ Priority=500 \ MaxWall=2-00:00:00 \ MaxCPUsPerUser=256 \ MaxJobsPerUser=15 # 3. 經濟 - 低優先權，短時間，少資源 sacctmgr add qos economy \ Priority=100 \ MaxWall=12:00:00 \ MaxCPUsPerUser=64 \ MaxJobsPerUser=5 # 套用到不同團隊 sacctmgr modify account lab_A set qos=vip sacctmgr modify account lab_B set qos=normal sacctmgr modify account lab_C set qos=economy ``` **套用對象**：Account (研究實驗室帳號) **設定位置**：SlurmDB (使用 sacctmgr) --- - ### 場景 2：GPU 資源專用管理 **需求**：GPU 節點需要特殊配額和時間限制 ```bash # 建立 GPU 專用 QoS sacctmgr add qos gpu_short \ Priority=800 \ MaxWall=4:00:00 \ MaxTRESPerUser=gres/gpu=4 \ MaxJobsPerUser=2 sacctmgr add qos gpu_long \ Priority=400 \ MaxWall=48:00:00 \ MaxTRESPerUser=gres/gpu=2 \ MaxJobsPerUser=1 # 在 slurm.conf 設定 partition 的 QoS # PartitionName=gpu_partition Nodes=gpu[01-10] QoS=gpu_long # 允許特定使用者使用 sacctmgr modify user alice set qos+=gpu_short,gpu_long ``` **套用對象**：User (個別使用者) + Partition (GPU 分區) **設定位置**：SlurmDB (sacctmgr) + slurm.conf (Partition 配置) --- - ### 場景 3：防止資源壟斷 **需求**：限制單一使用者/群組不能佔用過多資源 ```bash # 建立公平使用 QoS sacctmgr add qos fair_share \ Priority=500 \ MaxWall=24:00:00 \ MaxCPUsPerUser=128 \ MaxJobsPerUser=10 \ MaxSubmitJobsPerUser=30 \ GrpCPUs=1024 \ GrpJobs=50 # 套用到整個 Account（會影響該 Account 下所有使用者） sacctmgr modify account shared_resources set qos=fair_share ``` **套用對象**：Account (共享資源帳號) **設定位置**：SlurmDB (sacctmgr) --- - ### 場景 4：緊急作業優先處理 **需求**：提供緊急作業快速通道，可以搶佔 (preempt) 低優先權作業 ```bash # 建立緊急 QoS（可以搶佔其他作業） sacctmgr add qos urgent \ Priority=10000 \ MaxWall=2:00:00 \ MaxJobsPerUser=1 \ Preempt=normal,economy Flags=OverPartQOS # 建立可被搶佔的 QoS sacctmgr add qos normal \ Priority=500 \ MaxWall=24:00:00 \ \ PreemptMode=requeue # 只允許管理員或特定使用者使用緊急 QoS sacctmgr modify user admin set qos+=urgent ``` **套用對象**：User (特定授權使用者) **設定位置**：SlurmDB (sacctmgr) --- - ### 場景 5: 依時段差異化計費 **需求**: 尖峰時段使用較貴，離峰時段較便宜 ```bash # 尖峰時段 QoS（高計費倍率） sacctmgr add qos peak_hours \ Priority=600 \ UsageFactor=2.0 # 離峰時段 QoS（低計費倍率） sacctmgr add qos off_peak \ Priority=400 \ UsageFactor=0.5 # 套用到所有使用者，讓他們自行選擇 sacctmgr modify account default set qos+=peak_hours,off_peak # 使用者提交時選擇 sbatch --qos=off_peak night_job.sh ``` **套用對象**: Account (預設帳號，所有使用者可用) **設定位置**: SlurmDB (sacctmgr) --- ### QoS 常用參數說明 | 參數 | 說明 | |------|------| | `Priority` | 優先權數值 (越高越優先) | | `MaxWall` | 最大執行時間 (格式: DD-HH:MM:SS) | | `MaxCPUsPerUser` | 每使用者最大 CPU 數 | | `MaxJobsPerUser` | 每使用者最大同時執行作業數 | | `MaxSubmitJobsPerUser` | 每使用者最大排隊作業數 | | `MaxTRESPerUser` | 每使用者最大 TRES 資源 (如 GPU) | | `GrpCPUs` | 群組總 CPU 上限 | | `GrpJobs` | 群組總作業數上限 | | `Preempt` | 可以搶佔的 QoS 列表 | | `PreemptMode` | 搶佔模式 (suspend/requeue/cancel) | | `UsageFactor` | 計費倍率 | | `Flags` | 特殊旗標 (如 OverPartQOS) | ### 檢視目前 QoS 配置 ```bash # 查看所有 QoS sacctmgr show qos format=name,priority,maxwall,maxjobspu,maxsubmitpu # 查看使用者的 QoS sacctmgr show user username format=user,account,qos # 查看作業使用的 QoS scontrol show job <job_id> | grep QOS ``` ### 總結 - **QoS 套用對象**: User、Account、Partition - **設定位置**: 主要在 SlurmDB (使用 `sacctmgr`)，Partition QoS 在 `slurm.conf` - **使用方式**: 提交作業時用 `--qos` 指定，或由系統自動套用預設 QoS - **核心概念**: 透過優先權、資源限制、搶佔機制達到資源管理目標 --- ## QoS 指令 ### QoS 操作範例：建立與套用 > by `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/01/21) > - ### Step 1: 建立 QOS (使用 sacctmgr) ```bash # 建立名為 limit_3_jobs 的 QOS，限制每位 user 最多同時執行 3 個 job sacctmgr add qos limit_3_jobs MaxJobsPerUser=3 # 驗證 QOS 是否建立成功 sacctmgr show qos format=Name,MaxJobsPerUser ``` **補充選項** (根據需求可添加更多限制): ```bash # 建立更完整的 QOS 設定 sacctmgr add qos limit_3_jobs \ MaxJobsPerUser=3 \ MaxSubmitJobsPerUser=10 \ Priority=100 # 查看詳細 QOS 資訊 sacctmgr show qos limit_3_jobs -p ``` --- - ### Step 2: 套用 QOS #### **策略 1: 針對 Partition 強制套用 (Hard Limit)** 所有在該 partition 執行的 job 都會受到此 QOS 限制。 ```bash # 假設 partition 名稱為 compute scontrol update PartitionName=compute QOS=limit_3_jobs # 驗證設定 scontrol show partition compute | grep QOS # 或使用 sinfo -o "%P %l %D %N %Q" -p compute ``` **注意事項**: - 此方法會強制所有使用該 partition 的 user 都受到 QOS 限制 - 無法針對特定 user 做例外處理 --- #### **策略 2: 針對特定 Account/User 套用 (Soft/Specific Limit) ⭐推薦** 更靈活的方式，可以針對特定 account 或 user 套用 QOS。 ```bash # 方法 A: 針對特定 Account 在特定 Partition 套用 QOS sacctmgr modify account <account_name> \ set qos=limit_3_jobs \ where partition=<partition_name> # 實際範例 sacctmgr modify account default_account \ set qos=limit_3_jobs \ where partition=compute # 驗證 sacctmgr show assoc format=Account,Partition,QOS \ where partition=compute ``` ```bash # 方法 B: 針對特定 User 在特定 Partition 套用 QOS sacctmgr modify user <username> \ set qos=limit_3_jobs \ where account=<account_name> partition=<partition_name> # 實際範例 sacctmgr modify user john \ set qos=limit_3_jobs \ where account=default_account partition=compute # 驗證 sacctmgr show assoc format=User,Account,Partition,QOS \ where user=john partition=compute ``` ```bash # 方法 C: 批次套用到整個 Cluster 的 Account (所有 partition) sacctmgr modify account <account_name> \ set qos=limit_3_jobs # 實際範例 sacctmgr modify account default_account \ set qos=limit_3_jobs # 驗證 sacctmgr show assoc format=Account,Partition,QOS \ where account=default_account ``` **VIP User 例外處理範例**: ```bash # 為 VIP user 建立不受限制的 QOS sacctmgr add qos unlimited MaxJobsPerUser=-1 # 套用到特定 VIP user sacctmgr modify user vip_user \ set qos=unlimited \ where account=default_account partition=compute ``` --- - ### 完整設定流程範例假設需求: - Partition 名稱: `compute` - Account 名稱: `research_team` - 限制: 每位 user 最多同時執行 3 個 job - VIP user: `admin` 不受限制 ```bash # Step 1: 建立 QOS sacctmgr add qos limit_3_jobs MaxJobsPerUser=3 -i sacctmgr add qos unlimited MaxJobsPerUser=-1 -i # Step 2: 套用到 account (策略 2) sacctmgr modify account research_team \ set qos=limit_3_jobs \ where partition=compute -i # Step 3: 設定 VIP 例外 sacctmgr modify user admin \ set qos=unlimited \ where account=research_team partition=compute -i # Step 4: 驗證設定 sacctmgr show qos format=Name,MaxJobsPerUser sacctmgr show assoc format=Account,User,Partition,QOS \ where partition=compute # Step 5: 測試 (以一般 user 身份) srun -p compute --qos=limit_3_jobs hostname ``` --- - ### 驗證與測試指令 ```bash # 查看所有 QOS sacctmgr show qos # 查看特定 partition 的 association 和 QOS sacctmgr show assoc format=Cluster,Account,User,Partition,QOS \ where partition=compute # 查看 user 的有效 QOS sacctmgr show user <username> withassoc format=User,Account,Partition,QOS # 測試 job 提交 (應該受到 QOS 限制) for i in {1..5}; do sbatch -p compute --wrap="sleep 300" & done # 查看正在執行的 job 數量 squeue -u $USER -p compute -t RUNNING | wc -l # 應該不超過 3 個 ``` --- - ### 移除/修改 QOS 指令 ```bash # 移除 account 的 QOS sacctmgr modify account <account_name> \ set qos='' \ where partition=<partition_name> # 刪除 QOS sacctmgr delete qos limit_3_jobs # 修改 QOS 參數 sacctmgr modify qos limit_3_jobs set MaxJobsPerUser=5 ``` --- - ### 建議 **推薦使用策略 2 (針對 Account/User 套用)**，原因: 1. ✅ 靈活性高，可針對不同 user/account 設定不同限制 2. ✅ 可輕鬆設定 VIP user 例外 3. ✅ 不影響其他 partition 4. ✅ 符合多租戶環境的最佳實踐策略 1 (Partition 層級) 適用於: - 需要對所有 user 一視同仁的簡單環境 - 不需要例外處理的場景所有指令中的 `-i` 參數代表 immediate (立即執行不詢問確認)，生產環境建議移除此參數以進行人工確認。根據我對 Slurm 原始碼和文檔的分析，我已經整理出 QoS 最常用的參數。讓我為您整理這些參數，依使用頻率由高到低排列： ### WithRawQOSLevel 如何使用？ ``` $ sacctmgr modify user tj_tsai set QosLevel=+normal Modified user associations... C = slurm_slurm A = 9aa7d937-33ac-4620-a649-5cf93d55fc70 U = tj_tsai Would you like to commit changes? (You have 30 seconds to decide) (N/y): y $ sacctmgr show user tj_tsai --as format=user,Account%40,QOS,DefaultQOS User Account QOS Def QOS ---------- ---------------------------------------- -------------------- --------- tj_tsai 9aa7d937-33ac-4620-a649-5cf93d55fc70 frozen,normal frozen $ sacctmgr show user tj_tsai --as WithRawQOSLevel format=user,Account%40,QOS,DefaultQOS User Account QOS Def QOS ---------- ---------------------------------------- -------------------- --------- tj_tsai 9aa7d937-33ac-4620-a649-5cf93d55fc70 +normal,frozen frozen ``` - **結果**：多了 delta_qos 資訊 - `WithRawQOSLevel` 和 `format` 前後順序，不影響結果 --- ## Slurm QoS 最常用參數（依使用頻率排序） > by `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/01/21) ### **1. Priority（優先級）** - **用途**：設定 QoS 的優先權，影響 job 排程優先順序 - **範例**：`Priority=100` - **預設值**：未設定（無額外優先權） ### **2. MaxJobsPerUser（每使用者最大執行作業數）** - **用途**：限制單一使用者可同時執行的作業數量 - **範例**：`MaxJobsPerUser=3` - **別名**：`MaxJobsPU` ### **3. MaxSubmitJobsPerUser（每使用者最大提交作業數）** - **用途**：限制單一使用者可同時處於待執行或執行中的作業總數 - **範例**：`MaxSubmitJobsPerUser=10` - **別名**：`MaxSubmitJobsPU` ### **4. GrpTRES（群組資源總量限制）** - **用途**：限制此 QoS 所有執行中作業可使用的總資源量 - **範例**：`GrpTRES=cpu=24` 或 `GrpTRES=node=10,cpu=100,mem=500G` - **常用資源**：cpu, mem, node, gres/gpu ### **5. MaxTRESPerJob（每作業最大資源量）** - **用途**：限制單一作業可使用的最大資源量 - **範例**：`MaxTRESPerJob=cpu=16,mem=64G` - **別名**：`MaxTRES`, `MaxTRESPJ` ### **6. MaxWall（每作業最大執行時間）** - **用途**：限制單一作業的最長執行時間 - **範例**：`MaxWall=2:00:00`（2 小時）或 `MaxWall=7-00:00:00`（7 天） - **格式**：`<min>` 或 `<hr>:<min>:<sec>` 或 `<days>-<hr>:<min>:<sec>` - **別名**：`MaxWallDurationPerJob` ### **7. GrpJobs（群組最大執行作業數）** - **用途**：限制此 QoS 所有使用者可同時執行的作業總數 - **範例**：`GrpJobs=50` ### **8. GrpSubmitJobs（群組最大提交作業數）** - **用途**：限制此 QoS 所有作業（待執行+執行中）的總數 - **範例**：`GrpSubmitJobs=100` - **別名**：`GrpSubmit` ### **9. MaxTRESPerUser（每使用者最大資源量）** - **用途**：限制單一使用者可同時使用的總資源量 - **範例**：`MaxTRESPerUser=cpu=48,mem=256G` - **別名**：`MaxTRESPU` ### **10. GrpTRESRunMins（群組資源執行分鐘數限制）** - **用途**：限制執行中作業的資源時間總量（考慮 time limit） - **範例**：`GrpTRESRunMins=cpu=10000` - **說明**：達到限制時不會啟動新作業，直到有作業結束釋放時間 ### **11. MaxJobsPerAccount（每帳戶最大執行作業數）** - **用途**：限制單一帳戶可同時執行的作業數量 - **範例**：`MaxJobsPerAccount=20` - **別名**：`MaxJobsPA` ### **12. MaxSubmitJobsPerAccount（每帳戶最大提交作業數）** - **用途**：限制單一帳戶可同時處於待執行或執行中的作業總數 - **範例**：`MaxSubmitJobsPerAccount=50` - **別名**：`MaxSubmitJobsPA` ### **13. GrpWall（群組總執行時間限制）** - **用途**：限制所有執行中作業的總執行時間，達到限制會拒絕新提交並終止執行中作業 - **範例**：`GrpWall=1000:00:00` - **注意**：需啟用 Priority Multifactor plugin ### **14. MaxTRESPerNode（每節點最大資源量）** - **用途**：限制作業中每個節點可使用的資源量 - **範例**：`MaxTRESPerNode=cpu=32,mem=128G` - **別名**：`MaxTRESPN` ### **15. Flags（特殊標記）** - **用途**：設定特殊行為標記 - **範例**：`Flags=DenyOnLimit,OverPartQOS` - **常用標記**： - `DenyOnLimit`：超過限制時直接拒絕提交 - `OverPartQOS`：覆蓋 Partition QoS 限制 - `NoReserve`：不在 backfill 中保留資源 - `RequiresReservation`：必須指定 reservation ### **其他實用參數** - **GrpTRESMins**：歷史累積資源分鐘數限制（會隨時間衰減） - **MaxTRESMinsPerJob**：每作業最大資源分鐘數 - **Preempt**：可搶佔的其他 QoS 列表 - **PreemptMode**：搶佔模式（CANCEL, REQUEUE, SUSPEND） - **GraceTime**：被搶佔時的寬限時間 - **UsageFactor**：使用量計算因子（影響 fairshare） - **LimitFactor**：限制放大因子 ### **完整範例** ```bash # 建立一般使用者 QoS sacctmgr add qos normal \ Priority=50 \ MaxJobsPerUser=5 \ MaxSubmitJobsPerUser=20 \ MaxTRESPerJob=cpu=32,mem=128G \ MaxWall=24:00:00 # 建立高優先級 QoS（有限制） sacctmgr add qos high_priority \ Priority=200 \ MaxJobsPerUser=2 \ MaxSubmitJobsPerUser=5 \ GrpTRES=cpu=100,mem=500G \ MaxWall=12:00:00 \ Flags=DenyOnLimit # 建立測試用 QoS sacctmgr add qos testing \ Priority=10 \ MaxJobsPerUser=10 \ GrpJobs=50 \ MaxTRESPerJob=cpu=4,mem=16G \ MaxWall=1:00:00 \ Preempt=normal ``` 這份清單是根據 Slurm 測試套件中的使用頻率、文檔範例以及實際使用場景所整理。最常用的前五個參數（Priority, MaxJobsPerUser, MaxSubmitJobsPerUser, GrpTRES, MaxTRESPerJob）幾乎在所有 QoS 配置中都會使用。 --- ## QoS 表格資訊快覽 > by `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/01/21) ### Slurm QoS 最常用參數表（依使用頻率排序） | 排序 | 參數名稱 | 別名 | 用途說明 | 範例值 | 預設值 | |------|---------|------|---------|--------|--------| | 1 | **Priority** | - | 設定 QoS 優先權，影響作業排程順序 | `Priority=100` | 未設定 | | 2 | **MaxJobsPerUser** | MaxJobsPU | 限制單一使用者可同時執行的作業數 | `MaxJobsPerUser=3` | 無限制 | | 3 | **MaxSubmitJobsPerUser** | MaxSubmitJobsPU | 限制單一使用者可提交（待執行+執行中）的作業總數 | `MaxSubmitJobsPerUser=10` | 無限制 | | 4 | **GrpTRES** | - | 限制此 QoS 所有執行中作業的總資源量 | `GrpTRES=cpu=24,mem=128G` | 無限制 | | 5 | **MaxTRESPerJob** | MaxTRES, MaxTRESPJ | 限制單一作業可使用的最大資源量 | `MaxTRESPerJob=cpu=16,mem=64G` | 無限制 | | 6 | **MaxWall** | MaxWallDurationPerJob | 限制單一作業的最長執行時間 | `MaxWall=2:00:00` 或 `7-00:00:00` | 無限制 | | 7 | **GrpJobs** | - | 限制此 QoS 所有使用者可同時執行的作業總數 | `GrpJobs=50` | 無限制 | | 8 | **GrpSubmitJobs** | GrpSubmit | 限制此 QoS 所有作業（待執行+執行中）的總數 | `GrpSubmitJobs=100` | 無限制 | | 9 | **MaxTRESPerUser** | MaxTRESPU | 限制單一使用者可同時使用的總資源量 | `MaxTRESPerUser=cpu=48,mem=256G` | 無限制 | | 10 | **GrpTRESRunMins** | - | 限制執行中作業的資源時間總量（考慮 time limit） | `GrpTRESRunMins=cpu=10000` | 無限制 | | 11 | **MaxJobsPerAccount** | MaxJobsPA | 限制單一帳戶可同時執行的作業數量 | `MaxJobsPerAccount=20` | 無限制 | | 12 | **MaxSubmitJobsPerAccount** | MaxSubmitJobsPA | 限制單一帳戶可提交的作業總數 | `MaxSubmitJobsPerAccount=50` | 無限制 | | 13 | **GrpWall** | - | 限制所有執行中作業的總執行時間 | `GrpWall=1000:00:00` | 無限制 | | 14 | **MaxTRESPerNode** | MaxTRESPN | 限制作業中每個節點可使用的資源量 | `MaxTRESPerNode=cpu=32,mem=128G` | 無限制 | | 15 | **Flags** | - | 設定特殊行為標記 | `Flags=DenyOnLimit,OverPartQOS` | 無標記 | ### MaxWall 時間格式說明 | 格式 | 範例 | 說明 | |------|------|------| | `<min>` | `60` | 60 分鐘 | | `<hr>:<min>:<sec>` | `2:30:00` | 2 小時 30 分鐘 | | `<days>-<hr>:<min>:<sec>` | `7-12:00:00` | 7 天 12 小時 | ### 常用 Flags 標記 | 標記 | 功能說明 | |------|---------| | **DenyOnLimit** | 超過限制時直接拒絕作業提交（而非排隊等待） | | **OverPartQOS** | 此 QoS 設定會覆蓋 Partition QoS 的限制 | | **NoReserve** | 不在 backfill 排程中為此 QoS 作業保留資源 | | **RequiresReservation** | 使用此 QoS 的作業必須指定 reservation | | **PartitionMaxNodes** | 強制執行 partition 的 MaxNodes 限制 | | **PartitionMinNodes** | 強制執行 partition 的 MinNodes 限制 | | **PartitionTimeLimit** | 強制執行 partition 的 TimeLimit 限制 | ### 其他實用參數 | 參數名稱 | 用途說明 | 範例 | |---------|---------|------| | **GrpTRESMins** | 歷史累積資源分鐘數限制（會隨時間衰減） | `GrpTRESMins=cpu=100000` | | **MaxTRESMinsPerJob** | 單一作業最大資源分鐘數（資源量×時間） | `MaxTRESMinsPerJob=cpu=10000` | | **Preempt** | 可搶佔的其他 QoS 列表 | `Preempt=normal,low` | | **PreemptMode** | 搶佔模式 | `PreemptMode=REQUEUE` | | **GraceTime** | 被搶佔時的寬限時間 | `GraceTime=00:05:00` | | **UsageFactor** | 使用量計算因子（影響 fairshare） | `UsageFactor=2.0` | | **LimitFactor** | 限制放大因子 | `LimitFactor=1.5` | ### 常見使用情境範例 #### 情境 1：一般使用者 QoS ```bash sacctmgr add qos normal \ Priority=50 \ MaxJobsPerUser=5 \ MaxSubmitJobsPerUser=20 \ MaxTRESPerJob=cpu=32,mem=128G \ MaxWall=24:00:00 ``` #### 情境 2：高優先級 QoS（有資源限制） ```bash sacctmgr add qos high_priority \ Priority=200 \ MaxJobsPerUser=2 \ MaxSubmitJobsPerUser=5 \ GrpTRES=cpu=100,mem=500G \ MaxWall=12:00:00 \ Flags=DenyOnLimit,OverPartQOS ``` #### 情境 3：測試用 QoS（可被搶佔） ```bash sacctmgr add qos testing \ Priority=10 \ MaxJobsPerUser=10 \ GrpJobs=50 \ MaxTRESPerJob=cpu=4,mem=16G \ MaxWall=1:00:00 \ Preempt=normal ``` #### 情境 4：大型作業 QoS（需 Reservation） ```bash sacctmgr add qos large_jobs \ Priority=150 \ MaxJobsPerUser=1 \ MaxTRESPerJob=node=20,cpu=800 \ MaxWall=7-00:00:00 \ Flags=RequiresReservation ``` 這樣的表格格式讓參數對照更清楚明瞭！ --- --- ## 討論 ### Slurm QoS 用途為何？怎麼使用？ - ### gpt-5.2 (2026/01/06) 下面用「使用者視角 + 管理者視角」把 **Slurm QoS（Quality of Service，服務品質）**講清楚：它**用來把工作分級**，並把不同等級套用到**排程優先順序、搶佔（preemption）、資源/配額限制**三大類規則。([slurm.schedmd.com][20260106-A-1]) --- ### QoS 是什麼、解決什麼問題？ #### 核心概念 * 每個 job 都可以指定一個 QoS。([slurm.schedmd.com][20260106-A-1]) * QoS 由管理者在 **SlurmDB（透過 `sacctmgr`）** 定義，使用者在提交 job 時用 `--qos=` 來要求。([slurm.schedmd.com][20260106-A-1]) #### QoS 會影響 job 的三件事 Slurm 官方文件把 QoS 對 job 的影響歸納為三大項：([slurm.schedmd.com][20260106-A-1]) 1. **排程優先順序（priority）**：同樣資源需求下，高 QoS 可以排更前面。([slurm.schedmd.com][20260106-A-1]) 2. **搶佔（preemption）**：高 QoS 的排隊 job 可以把低 QoS 的執行中 job 暫停/重排/取消，釋放資源給自己。([slurm.schedmd.com][20260106-A-1]) 3. **資源限制（limits / quotas）**：例如限制每個 QoS 最多可用多少 CPU/GPU、最多跑多久、最多同時跑幾個 job、TRES-minutes 配額等；而且 QoS 的限制通常**優先於 association（帳務關聯）**的限制。([slurm.schedmd.com][20260106-A-1]) --- ### 沒有 QoS 會怎樣？視你「有沒有啟用 enforcement」而定： #### 1) 你不要求一定要指定 QoS（沒設 `AccountingStorageEnforce=qos`）那使用者通常就走預設策略：job 仍會依 partition/其他排程政策執行。官方 accounting 文件也提到：**不設定 AccountingStorageEnforce 時，job 會依每個 cluster 既有政策執行**。([slurm.schedmd.com][20260106-A-2]) > 這種情況下，QoS 可能只是「可選標籤」，不用也不會擋 job。 #### 2) 你要求一定要是有效 QoS（設 `AccountingStorageEnforce` 包含 `qos`）當你把 `AccountingStorageEnforce` 包含 `qos` 時，使用者會被限制只能用「自己 association 被允許的 QoS」。([slurm.schedmd.com][20260106-A-3]) > 沒指定、或指定了不允許/不存在的 QoS，就可能提交失敗或一直 pending（依你的設定與限制而定）。 --- ### QoS 怎麼用？ ### A. 使用者怎麼指定 QoS 常見三種指令都能指定： * `sbatch --qos=<qos>` * `salloc --qos=<qos>` * `srun --qos=<qos>`（`srun` 也有 `-q` 短參數）([slurm.schedmd.com][20260106-A-1]) 例：sbatch 腳本 ```bash #SBATCH --account=projA #SBATCH --partition=gpu #SBATCH --qos=high ``` `srun` 也可以一次給多個 QoS（逗號分隔，會按 QoS priority 排序，先用最高的）。([slurm.schedmd.com][20260106-A-3]) ```bash srun --qos=high,normal -G 1 python train.py ``` --- ### B. 管理者怎麼建立/配置 QoS（典型流程） > QoS/association 這套通常需要 SlurmDBD 與 accounting_storage/slurmdbd。官方 resource_limits 文件也說明：排程政策資訊需要存到 DB，並建議用 SlurmDBD。([slurm.schedmd.com][20260106-A-4]) 1. **建立 QoS（用 `sacctmgr`）** QoS 定義在資料庫中，用 `sacctmgr` 管。([slurm.schedmd.com][20260106-A-1]) （示意） ```bash # 建一個高優先 QoS sacctmgr add qos high priority=100 # 建一個低優先、可被搶佔的 QoS sacctmgr add qos low priority=10 ``` 2. **設定 QoS 的限制（limits/quotas）** 例如：每個 job 最長時間、每個 job 最多 GPU、群組總量上限（GrpTRES / GrpTRESMins…）等。QoS 的限制會套用到 job，且可優先於 association 限制。([slurm.schedmd.com][20260106-A-1]) 3. **（可選）設定搶佔規則** * 若要用 QoS 來決定搶佔，`slurm.conf` 的 `PreemptType` 需用 `preempt/qos`。([slurm.schedmd.com][20260106-A-1]) * 然後在 QoS 上設定它能搶佔哪些 QoS（qos.html 有描述此機制）。([slurm.schedmd.com][20260106-A-1]) 4. **把 QoS 掛到使用者/帳戶的 association（允許哪些 QoS）** 使用者是否能用某個 QoS，是由 association（user/cluster/account…）允許集合決定；並且當 `AccountingStorageEnforce` 包含 `qos` 時會被強制遵守。([slurm.schedmd.com][20260106-A-3]) 5. **（可選）要求所有人都必須用有效 QoS** 把 `AccountingStorageEnforce` 設定包含 `qos`。這能避免大家「隨便亂填 QoS」或繞過分級策略。([slurm.schedmd.com][20260106-A-3]) --- ### 常被忽略但很關鍵的細節 #### 1) Partition QoS ≠ Job QoS 你可以把 QoS 掛在 partition 上，變成「這個 partition 的限制模板」。但它**不會自動把 job 視為使用該 QoS**、也不給 job 那個 QoS 的 priority/搶佔特性；job 仍可再另外 `--qos=` 來拿 priority/搶佔特性。([slurm.schedmd.com][20260106-A-1]) #### 2) 限制的套用優先順序（誰蓋過誰）官方列的層級（簡化）：**Partition QoS → Job QoS → User association → Account association → … → Partition limit**。([slurm.schedmd.com][20260106-A-4]) > 這會影響你除錯：為什麼你在 QoS 設了限制卻看起來沒生效，常常是被更上層/更優先的地方蓋掉。 #### 3) QoS 的「優先順序」要真的影響排程，還要開權重 QoS priority 只有在使用 multifactor priority（`priority/multifactor`）且 `PriorityWeightQOS` 設為 >0 時，才會進入計算。([slurm.schedmd.com][20260106-A-1]) --- 如果你願意貼你目前的目標（例如：要做「高優先可搶佔低優先」、或「不同專案 GPU 配額」、或「互動/批次分級」），我可以直接給你一套 **QoS + association + AccountingStorageEnforce +（必要時）PreemptType** 的最小可行設定與 `sacctmgr` 指令範本。 [20260106-A-1]: https://slurm.schedmd.com/qos.html "Slurm Workload Manager - Quality of Service (QOS)" [20260106-A-2]: https://slurm.schedmd.com/accounting.html "Slurm Workload Manager - Accounting and Resource Limits" [20260106-A-3]: https://slurm.schedmd.com/srun.html "Slurm Workload Manager - srun" [20260106-A-4]: https://slurm.schedmd.com/resource_limits.html "Slurm Workload Manager - Resource Limits" --- ### GrpJobs / GrpSubmit / MaxJobs / MaxSubmit 差異 - ### `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/03/05) 根據 Slurm 官方文件，這四個欄位的差異如下： ### 主要差異說明 #### 作用範圍差異：**Grp** vs **Max** | 類型 | 作用範圍 | 說明 | |------|---------|------| | **Grp**（Group） | Association + 所有子帳戶 | 限制會套用到該 association 及其整個子樹（aggregate） | | **Max**（Maximum） | 單一 Association | 只限制該 association 本身，不包含子帳戶 | #### 任務狀態差異：**Jobs** vs **SubmitJobs** | 類型 | 包含狀態 | 說明 | |------|---------|------| | **Jobs** | Running（執行中） | 只計算正在執行的任務數量 | | **SubmitJobs**（Submit） | Pending + Running（等待中 + 執行中） | 計算所有已提交的任務（包含排隊和執行中） | ### 四個欄位的詳細說明 #### 1. **GrpJobs** - **限制對象**: Association 及其所有子帳戶 - **限制狀態**: 正在執行的任務（Running） - **說明**: 該 association 及其子帳戶能同時執行的任務總數 - **超過限制**: 新任務會被排隊，直到有任務完成才能執行 #### 2. **GrpSubmitJobs** (GrpSubmit) - **限制對象**: Association 及其所有子帳戶 - **限制狀態**: 所有提交的任務（Pending + Running） - **說明**: 該 association 及其子帳戶能同時擁有的任務總數（包含排隊和執行中） - **超過限制**: 新的提交請求會被直接拒絕 #### 3. **MaxJobs** - **限制對象**: 單一 Association（不包含子帳戶） - **限制狀態**: 正在執行的任務（Running） - **說明**: 該 association 本身能同時執行的任務數量 - **超過限制**: 新任務會被排隊，直到有任務完成才能執行 #### 4. **MaxSubmitJobs** (MaxSubmit) - **限制對象**: 單一 Association（不包含子帳戶） - **限制狀態**: 所有提交的任務（Pending + Running） - **說明**: 該 association 本身能同時擁有的任務總數（包含排隊和執行中） - **超過限制**: 新的提交請求會被直接拒絕 ### 實例說明假設有以下帳戶結構： ``` account: science (parent) ├─ chemistry (child) └─ physics (child) ``` 如果設定： - `science` 帳戶：`GrpJobs=20`, `GrpSubmitJobs=50` - `chemistry` 使用者：`MaxJobs=5`, `MaxSubmitJobs=10` 則限制為： - `science` 及其所有子帳戶（`chemistry` + `physics`）總共最多能同時執行 **20** 個任務 - `science` 及其所有子帳戶總共最多能提交 **50** 個任務（排隊 + 執行） - `chemistry` 單一使用者最多能同時執行 **5** 個任務 - `chemistry` 單一使用者最多能提交 **10** 個任務（排隊 + 執行） **參考文件**: `/tmp/mycodeagent/slurm-1772697812585/doc/html/resource_limits.shtml` - ### 指令 ```bash sacctmgr -i create account science sacctmgr list account sacctmgr list account --as sacctmgr -i create user chemistry account=science sacctmgr -i create user physics account=science sacctmgr list user sacctmgr list user --as # 設定 science 帳戶的群組限制 sacctmgr modify account science set GrpJobs=20 GrpSubmitJobs=50 # sacctmgr modify account where name=science set GrpJobs=20 GrpSubmitJobs=50 sacctmgr list account --as # 設定 chemistry 帳戶的單一使用者限制 sacctmgr modify user chemistry set MaxJobs=5 MaxSubmitJobs=10 sacctmgr list account --as # 設定 science 帳戶的群組限制，以及旗下所有使用者 sacctmgr modify account science set GrpJobs=20 GrpSubmitJobs=50 MaxJobs=5 MaxSubmitJobs=10 sacctmgr list account --as ``` --- ### normal QoS 是系統預設的嗎？ - ### Question ``` $ sacctmgr show qos normal Name Priority GraceTime Preempt PreemptExemptTime PreemptMode Flags UsageThres UsageFactor GrpTRES GrpTRESMins GrpTRESRunMin GrpJobs GrpSubmit GrpWall MaxTRES MaxTRESPerNode MaxTRESMins MaxWall MaxTRESPU MaxJobsPU MaxSubmitPU MaxTRESPA MaxTRESRunMinsPA MaxTRESRunMinsPU MaxJobsPA MaxSubmitPA MinTRES ---------- ---------- ---------- ---------- ------------------- ----------- ---------------------------------------- ---------- ----------- ------------- ------------- ------------- ------- --------- ----------- ------------- -------------- ------------- ----------- ------------- --------- ----------- ------------- ---------------------- ---------------------- --------- ----------- ------------- normal 0 00:00:00 cluster 1.000000 ``` normal QoS 是系統預設的嗎？ - ### `us.anthropic.claude-sonnet-4-5-20250929-v1:0` (2026/03/06) 根據 Slurm 的官方文檔和原始碼，**是的，`normal` QoS 是系統預設的 QoS**。 ### 證據來源 1. **官方文檔說明** > https://slurm.schedmd.com/qos.html#examples > By default when a cluster is added to the database a default qos named normal is created. 在 `/doc/html/qos.shtml` 的第 305-306 行明確指出： > **By default when a cluster is added to the database a default qos named normal is created.** 2. **原始碼實作** 在 `src/plugins/accounting_storage/mysql/accounting_storage_mysql.c` 的第 1022-1037 行，可以看到當 cluster 被加入到資料庫時，會自動執行以下 SQL： ```c query = xstrdup_printf( "insert into %s " "(creation_time, mod_time, name, description) " "values (%ld, %ld, 'normal', " "'Normal QOS default') " "on duplicate key update " "id=LAST_INSERT_ID(id), deleted=0;", qos_table, now, now); ``` 這段程式碼會自動創建名為 `'normal'` 的 QoS，並設定描述為 `'Normal QOS default'`。 ### 您輸出的資訊解讀 ```bash $ sacctmgr show qos normal Name Priority ... Flags UsageThres UsageFactor ... ---------- ---------- ... normal 0 ... 1.000000 ``` 這個 `normal` QoS 具有以下預設特性： - **Priority = 0**：預設優先權 - **UsageFactor = 1.0**：正常的使用計費係數（1 倍） - **Flags = cluster**：標記為 cluster 層級的 QoS - **無特殊限制**：所有資源限制欄位都是空的，表示沒有額外的限制 **總結**：`normal` QoS 是 Slurm 在創建 cluster 時自動生成的預設 QoS，用戶無需手動創建。 {%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.