皆さん、こんにちは！
HPC環境において、Slurmは計算資源の管理に欠かせないツールですが、ジョブの投入が無秩序に行われると、システムの効率性や利用者間の公平性が損なわれることがあります。
今回は、このような問題を解消し、Slurmクラスターを最大限に活用するために非常に重要なQoS (Quality of Service)設定、特にPriority（優先度）とMaxWall（最大実行時間）の制限についてご紹介します。
QoS設定をしない場合に起こりうる問題点
PriorityやMaxWallといったQoS設定を行わない場合、以下のような問題が発生する可能性があります。
1. Priority（優先度）を設定しない場合
全アカウントのジョブが同一優先度となり、資源が競合した際に「誰のジョブを先に流すか」の明確な基準がなくなります。
プロジェクトの重要度や利用目的（例: 本番研究用 vs. 学習・テスト用）が区別されず、結果的に小規模で重要な計算が、大規模で重要度の低い計算に押しのけられて遅延するといった非効率や不公平が発生する可能性があります。
2. MaxWall（最大実行時間）を設定しない場合
利用者が非常に長いwalltime（例: 数週間）を指定してジョブを投入できてしまうことがあります。
そのジョブが計算資源を長時間占有すると、後続ジョブが長時間待たされることになり（資源の“フラグメンテーション”）、スケジューラが「いつリソースが空くか」予測できず、効率的なバックフィルが困難になります。
実際の計算は短時間で終わるのに長いwalltimeを申請されると、リソースの隙間が有効に使えず、クラスター全体の利用効率が低下します。
QoSを設定するメリット
これらの問題を解決するために、PriorityとMaxWallを設定することには多くのメリットがあります。
1. Priority（優先度）を設定するメリット
アカウントごとの優先度調整が可能になり、重要度の高いプロジェクトを優先して資源を割り当てることができます。
限られた資源を公平かつ戦略的に配分できるため（例: 共同研究・産学連携案件を優先）、管理者側で明確なルール化が可能となり、利用者間の不満を減らせます。
2. MaxWall（最大実行時間）を設定するメリット
極端に長いジョブ投入を防止し、スケジューリング効率を維持できます。
長時間ジョブを本当に必要とする場合は、特別なQoSを付与して管理者承認制にするなど、柔軟な運用が可能になります（例: 通常は48時間まで、長時間ジョブは専用QoSを申請）。
では、具体的な設定例と動作を見ていきましょう。
Priority（優先度）によるジョブの優先順位
まず、デフォルトのQoS「normal」にPriority=200を設定し、追加のQoS「high」にPriority=300を設定します。
# sacctmgr list qos format=Name,Priority,MaxWall
Name Priority MaxWall
---------- ---------- -----------
normal 200 1-00:00:00
high 300 01:00:00
💡 ポイント:
QoS「normal」は明示的に--qos=normalと指定した場合のほか、QoSを何も指定しない場合にも使用されます。
同時実行数2ジョブの計算ノードへ、まずQoS「normal」のジョブを連続で5回投入します。
abe@control1:~$ sbatch --job-name=normal --job-name=normal --partition=cpu-L testjob.sh
Submitted batch job 67109895
投入直後のジョブキューの状況です。2つのジョブが実行中（R）、3つのジョブが保留中（PD）です。保留中のジョブには(Priority)と表示され、優先度制限により実行が保留されていることが示唆されます。
abe@control1:~$ squeue -o "%.10i %.10P %.10j %.10u %.2t %.10M %.5D %.20R %.10q %.10Q %.10p"
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) QOS PRIORITY PRIORITY
67109899 cpu-L normal abe PD 0:00 1 (Priority) normal 50000 0.00001164
67109898 cpu-L normal abe PD 0:00 1 (Priority) normal 50000 0.00001164
67109897 cpu-L normal abe PD 0:00 1 (Resources) normal 50000 0.00001164
67109896 cpu-L normal abe R 0:04 1 control1 normal 50000 0.00001164
67109895 cpu-L normal abe R 0:05 1 control1 normal 50000 0.00001164
次に、別のユーザーでQoS「high」のジョブを連続で5回投入してみます。
ueda@control1:~$ sbatch --qos=high --job-name=high --partition=cpu-L testjob.sh
Submitted batch job 67109900
既に実行中のQoS「normal」ジョブ（67109895、67109896）はそのまま実行されますが、投入されたQoS「high」ジョブは、QoS:normalジョブよりも高いPRIORITY値が設定されていることが分かります。
abe@control1:~$ squeue -o "%.10i %.10P %.10j %.10u %.2t %.10M %.5D %.20R %.10q %.10Q %.10p"
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) QOS PRIORITY PRIORITY
67109904 cpu-L high ueda PD 0:00 1 (Priority) high 75000 0.00001746
67109903 cpu-L high ueda PD 0:00 1 (Priority) high 75000 0.00001746
67109902 cpu-L high ueda PD 0:00 1 (Priority) high 75000 0.00001746
67109901 cpu-L high ueda PD 0:00 1 (Priority) high 75000 0.00001746
67109900 cpu-L high ueda PD 0:00 1 (Resources) high 75000 0.00001746
67109899 cpu-L normal abe PD 0:00 1 (Priority) normal 50000 0.00001164
67109898 cpu-L normal abe PD 0:00 1 (Priority) normal 50000 0.00001164
67109897 cpu-L normal abe PD 0:00 1 (Priority) normal 50000 0.00001164
67109896 cpu-L normal abe R 0:04 1 control1 normal 50000 0.00001164
67109895 cpu-L normal abe R 0:05 1 control1 normal 50000 0.00001164
実行中のジョブが終了すると、先にキューインしていたQoS「normal」のジョブではなく、後からキューインしたQoS「high」のジョブが先に実行されることが確認できます。
# QoS:highのジョブが実行される例
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) QOS PRIORITY PRIORITY
...
67109901 cpu-L high ueda R 0:04 1 control1 high 75000 0.00001746
67109900 cpu-L high ueda R 0:05 1 control1 high 75000 0.00001746
...
QoS「high」のジョブがすべてキューからなくなると、ようやくQoS「normal」のジョブが実行されます。
# QoS:normalのジョブが実行される例
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) QOS PRIORITY PRIORITY
...
67109899 cpu-L normal abe R 0:05 1 control1 normal 50000 0.00001164
67109898 cpu-L normal abe R 0:05 1 control1 normal 50000 0.00001164
MaxWall（最大実行時間）によるジョブの最長時間設定
次に、MaxWallによるジョブの最長時間設定を見てみましょう。 デフォルトのQoS「normal」にMaxWall=1日を設定し、追加のQoS「high」にMaxWall=1時間を設定します。
# sacctmgr list qos format=Name,Priority,MaxWall
Name Priority MaxWall
---------- ---------- -----------
normal 200 1-00:00:00
high 300 01:00:00
長時間実行するジョブ（maxtime.sh）をQoS「normal」とQoS「high」で同時に投入します。
$ sbatch --qos=normal --job-name=normal --partition=cpu-H maxtime.sh
$ sbatch --qos=quick --job-name=high --partition=cpu-H maxtime.sh
投入直後のsqueueでは両方のジョブが実行中として表示されます。
abe@control1:~$ squeue -o "%.10i %.10P %.10j %.10u %.2t %.10M %.5D %.20R %.10q %.10Q %.10p"
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) QOS PRIORITY PRIORITY
67110017 cpu-H high abe R 0:11 1 com1 high 75000 0.00001746
67110015 cpu-H normal abe R 0:20 1 com1 normal 50000 0.00001164
一定時間後にsacctコマンドでジョブの終了状況を確認すると、QoS「high」のジョブは設定された1時間後にTIMEOUTで終了し、QoS「normal」のジョブは設定された1日後にTIMEOUTで終了していることが分かります。
abe@control1:~$ sacct -S 2025-07-20 -E 2025-07-30 -o JobID,Partition,JobName,User,Start,End,State
JobID Partition JobName User Start End State
----------- ----------- ---------- ---------- ------------------- ------------------- ----------
67110015 cpu-H normal abe 2025-07-28T18:27:09 2025-07-29T18:27:18 TIMEOUT
67110015.ba+ batch abe 2025-07-28T18:27:09 2025-07-29T18:27:19 CANCELLED
67110017 cpu-H high abe 2025-07-28T18:27:18 2025-07-28T19:27:31 TIMEOUT
67110017.ba+ batch abe 2025-07-28T18:27:18 2025-07-28T19:27:32 CANCELLED
まとめ
今回は、Slurm環境におけるQoS (PriorityとMaxWall) の設定が、システムの効率性確保と利用者間の公平な資源配分にいかに重要かをご紹介しました。
これらの設定を適切に行うことで、ジョブの優先順位を明確にし、極端に長いジョブによる資源占有を防ぎ、クラスター運用をよりスムーズに、そして効率的に行うことができます。
私たちライフマティックス株式会社では、このようなSlurmの複雑な設定や運用でお困りのお客様向けに、Slurmの保守サービスをご提供しております。
お客様の計算環境を最大限に活用できるよう、専門のエンジニアが強力にサポートいたしますので、ぜひお気軽にご相談ください。
このブログ記事が、皆さんの研究や開発を加速させる一助となれば幸いです！
