KnowHow

技術的なメモを中心にまとめます。
検索にて調べることができます。

SLURMユーザによるSumibt数制限方法

登録日 ：2025/12/14 17:40
カテゴリ ：SLURM

SLURMユーザで、Submit可能なジョブ数を制限する

事前の設定（slurm.conf)

# Resorce Settings
AccountingStorageEnforce=limits

SLURMのアカウント、グループIDを登録する

sacctmgr add account <nis group>
sacctmgr list account

sacctmgr add user <nis user> account=<nis group>
sacctmgr list user

ユーザにジョブ数の制限を行う

sacctmgr modify user testuser account=root set MaxJobs=2 MaxSubmitJobs=10
sacctmgr show association format=User,MaxJobs,MaxSubmitJobs

実行例
ユーザでの制限

[root@headnode settings]# sacctmgr modify user 1000 account=1000 set MaxJobs=1 MaxSubmitJobs=2
 Modified user associations...
  C = rockylinux8 A = 1000                 U = 1000
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y
[root@headnode settings]#
[root@headnode settings]#
[root@headnode settings]# sacctmgr show association format=User,MaxJobs,MaxSubmitJobs
      User MaxJobs MaxSubmit
---------- ------- ---------

      root

      1000       1         2
[root@headnode settings]#

user01で実行した場合、３つ目のsubmitができないことを確認

[user01@headnode 01]$ sbatch job.sh
Submitted batch job 132
[user01@headnode 01]$ sbatch job.sh
Submitted batch job 133
[user01@headnode 01]$ sbatch job.sh
sbatch: error: AssocMaxSubmitJobLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)
[user01@headnode 01]$ sbatch job.sh
sbatch: error: AssocMaxSubmitJobLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)
[user01@headnode 01]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               132     part1     test   user01  R       0:05      1 compute01
               133     part1     test   user01  R       0:02      1 compute02
[user01@headnode 01]$
[user01@headnode 01]$
[user01@headnode 01]$ sbatch job.sh
sbatch: error: AssocMaxSubmitJobLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)
[user01@headnode 01]$
[user01@headnode 01]$
Appendix メモ

PartitionName=handson Nodes=compute0[1-2] Default=YES MaxTime=INFINITE State=UP QOS=handsonqosの設定下で、
QOSのMaxJobs=5とUser AssociationのMaxJobs=10を設定すると、AND条件（両方適用）で制限されます。​

SLURM制限の適用優先順位
SLURMは以下の順序で制限を適用し、上位の制限が厳しい値で勝ちます。

1. Partition QOS limit  ← handsonqos (MaxJobs=5)
2. Job QOS limit
3. User association     ← testuser (MaxJobs=10)
4. Account association
5. Root/Cluster association
6. Partition limit

handsonパーティションのPartition QOS（優先順位1位）が最も優先されるため、MaxJobs=5が適用され、ユーザーは最大5ジョブしか実行できません。
summary

# 1. Associationでユーザー制限（管理側のみ）
sacctmgr modify user testuser set MaxJobs=2 MaxSubmitJobsPU=10

# 2. Partition QOSでパーティション制限（自動適用）
PartitionName=handson QOS=handsonqos MaxJobs=5

# 結果: 2 AND 5 = 最大2ジョブ（どちらも自動）

Remark

PartitionにQoSを設定していると、それが優先される模様

[root@headnode settings]# sacctmgr show qos format="Name,MaxWall,MaxTRESPerUser%30,MaxJob,MaxSubmit,Priority,Preempt"
      Name     MaxWall                      MaxTRESPU MaxJobs MaxSubmit   Priority    Preempt
---------- ----------- ------------------------------ ------- --------- ---------- ----------
    normal                                                                       0
handsonqos                                                  5                    0
[root@headnode settings]#

PartitionのQoSの上限と、Userの上限設定のバランスを調整した検討が必要そう。
テスト環境は、ノード数が少ないので、これ以上のテストができていない
User上限が働けば、以下のようになる

[user01@headnode 01]$ sbatch job.sh
Submitted batch job 144
[user01@headnode 01]$ sbatch job.sh
Submitted batch job 145
[user01@headnode 01]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               145     part1     test   user01 PD       0:00      1 (AssocMaxJobsLimit)
               144     part1     test   user01  R       0:02      1 compute01
[user01@headnode 01]$

別のパーティションにジョブを投入したときには、PartitionのQoSがあるので、どうしてもそれが有効になるみたい。Partition毎は５つまで、全体では１０ジョブまでという制御は難しいそう。

[user01@headnode 01]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               146     part1     test   user01  R       1:33      1 compute01
[user01@headnode 01]$ sbatch -p debug job.py
Submitted batch job 147
[user01@headnode 01]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               147     debug   job.py   user01  R       0:01      1 headnode
               146     part1     test   user01  R       1:39      1 compute01
[user01@headnode 01]$

結論

SLURM制限の絶対優先順位

1. Partition QOS ← handsonqos MaxJobs=5 (最強!)
2. Job QOS
3. User Association ← MaxJobsPU=10 (無力化)
Partition QOSが存在するとUser制限は100%無視されます。これがSLURMの仕様です。

「パーティション5 + 全体10」が不可能な理由

part1 QOS=handsonqos MaxJobs=5   → part1で5ジョブOK
User MaxJobsPU=10               → **効かない**（優先順位3位）
→ 結果: part1で5ジョブ + 他パーティションで無制限

実現可能な代替案

1. パーティションQOSなし + User制限のみ
# slurm.conf で QOS=handsonqos を削除
PartitionName=part1 Nodes=compute0[1-2] Default=NO MaxTime=30:00 State=UP
# → User MaxJobsPU=10 が効く（現在成功中）
2. 複数パーティションで分散制御
part1 QOS=handsonqos MaxJobsPU=5
part2 QOS=normal     MaxJobsPU=5  
User=user01 MaxJobsPU=10  ← 効かないので諦め
3. Job提出時QOS指定（上級）
sbatch --qos=handsonqos:OverPartQOS job.sh  # User制限優先
ユーザー操作が必要で管理側制御不可。

結論
「パーティション別制限 + 全体制限」はSLURM仕様上不可能です。

現実解:

パーティションQOS削除 → User MaxJobsPU=10のみ（推奨）

またはパーティションQOSのみ受け入れる

現在成功中の「QOSなし + User制限」が最も管理しやすい運用です。


戻る