Slurm多分区提交作业数组无法调度至空闲分区问题咨询

该异常现象与fair share策略无关，根因属于分区（队列）配置类问题，具体判断依据和排查方向如下：

• Slurm原生多分区提交逻辑说明：使用-p dev,dev1,dev2指定多个分区提交作业时，作业数组不会被自动拆分分发到所有指定分区，只会整体进入Slurm判定优先级最高的单个分区排队，其余分区不会承接该作业数组的任务，这是Slurm的默认调度逻辑，不属于异常。
• 单独向空闲的dev1、dev2分区提交作业仍持续排队的表现，完全不符合fair share策略的作用特征：fair share策略仅会调整同一分区内不同用户/作业的排队优先级，不会出现分区无任何运行作业、资源完全空闲时，新提交作业始终无法启动的情况。

常见配置错误排查步骤 #

可按以下顺序逐一核对配置，定位具体问题：

1. 核对分区访问权限
   执行命令scontrol show partition dev1查看分区配置，重点核对AllowAccounts、AllowGroups、AllowQos、DenyUsers字段，确认当前使用的账号/用户组在dev1、dev2分区的允许访问列表内。多数集群新建分区默认会限制仅特定用户组可提交作业，普通用户提交的作业会因权限问题被卡在排队状态，不会直接提示权限报错。
2. 核对分区节点可用状态
   执行命令sinfo -p dev1查看分区下所有节点的状态，如果节点处于drain、down、maint状态，哪怕分区统计层面显示有空闲资源，实际也没有可调度的计算节点，作业会持续等待资源。
3. 核对分区资源限制规则
   再次查看scontrol show partition dev1的输出，核对MaxCPUsPerJob、MaxNodesPerJob、MaxTime字段，如果提交的作业申请的CPU核数、节点数、运行时长超过分区设置的上限，作业也会一直排队无法调度。
4. 核对绑定QOS的限制规则
   如果dev1、dev2分区绑定了专属QOS，执行sacctmgr show qos format=Name,MaxJobsPerUser,MaxCPUsPerUser查看对应QOS的限制，确认账号没有触发单用户最大作业数、单用户最大可用核数的阈值。

大规模作业数组多分区利用方案 #

若需要让大规模作业数组充分利用dev、dev1、dev2多个分区的资源，不要依赖Slurm多分区参数自动分发。可以在提交逻辑中手动将作业数组拆分为多个批次，每个批次单独指定一个空闲分区提交，即可实现跨分区的资源利用。

异常复现命令与输出 #

srun -p dev1 echo "hello world"
srun: job 5037027 queued and waiting for resources. 

# slurm does not distribute the job to empty partition.

内容的提问来源于stack exchange，提问作者Matthew Ha