slurm 工作正在等待中，但资源可用

Question

根据我的理解，我在资源分配方面遇到了一些麻烦 文档并将其应用到配置文件中，我期待一些不会发生的行为。

以下是配置文件的相关摘录：

 60 SchedulerType=sched/backfill                                                                                            
 61 SchedulerParameters=bf_continue,bf_interval=45,bf_resolution=90,max_array_tasks=1000                                    
 62 #SchedulerAuth=                                                                                                         
 63 #SchedulerPort=                                                                                                         
 64 #SchedulerRootFilter=                                                                                                   
 65 SelectType=select/cons_res                                                                                              
 66 SelectTypeParameters=CR_CPU_Memory                                                                                      
 67 FastSchedule=1
...     
 102 NodeName=cn_burebista Sockets=2 CoresPerSocket=14 ThreadsPerCore=2 RealMemory=256000  State=UNKNOWN                      
 103 PartitionName=main_compute Nodes=cn_burebista Shared=YES Default=YES MaxTime=76:00:00 State=UP

根据上面的内容，我启用了回填调度程序，并将 CPU 和内存配置为 资源。我的资源池中有 56 个 CPU 和 256GB RAM。我希望他能回填 调度程序尝试分配资源，以便尽可能多地填充内核（如果有） 多个进程请求的资源多于可用资源。就我而言，我有以下队列：

 JOBID PARTITION     NAME     USER      ST       TIME  NODES NODELIST(REASON)
 2361 main_comp     training   mc       PD       0:00      1           (Resources)
 2356 main_comp     skrf_ori   jh       R        58:41      1          cn_burebista
 2357 main_comp     skrf_ori   jh       R        44:13      1          cn_burebista

作业 2356 和 2357 各需要 16 个 CPU，作业 2361 需要 20 个 CPU，这意味着总共 52 个 CPU 从上面可以看出，作业 2361（由不同用户启动）由于缺乏资源而被标记为待处理，尽管有大量可用的 CPU 和内存。 “scontrol show Nodes cn_burebista”给了我以下内容：

NodeName=cn_burebista Arch=x86_64 CoresPerSocket=14
   CPUAlloc=32 CPUErr=0 CPUTot=56 CPULoad=21.65
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=cn_burebista NodeHostName=cn_burebista Version=16.05
   OS=Linux RealMemory=256000 AllocMem=64000 FreeMem=178166 Sockets=2 Boards=1
   State=MIXED ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   BootTime=2018-03-09T12:04:52 SlurmdStartTime=2018-03-20T10:35:50
   CapWatts=n/a
   CurrentWatts=0 LowestJoules=0 ConsumedJoules=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s

我一遍又一遍地查看文档，但我无法弄清楚我做错了什么...... 为什么我会出现以上的情况呢？我应该对我的配置进行哪些更改才能使其正常工作？

类似（不一样的情况）问题问这里但没有答案

编辑：

这是我的任务脚本的一部分：

  3 # job parameters                                                                                                         
  4 #SBATCH --job-name=training_carlib                                                                                       
  5 #SBATCH --output=training_job_%j.out                                                                                     
  6                                                                                                                          
  7 # needed resources                                                                                                       
  8 #SBATCH --ntasks=1                                                                                                       
  9 #SBATCH --cpus-per-task=20                                                                                               
 10 #SBATCH --export=ALL       

 17 export OMP_NUM_THREADS=20                                                                                                
 18 srun ./super_awesome_app

可以看出，每个节点请求 1 个任务，每个任务 20 个 CPU。由于调度程序被配置为将 CPU 视为资源而不是核心，并且我在脚本中明确询问 CPU，为什么作业会要求核心？这是我的参考文档。

编辑2：

这是建议命令的输出：

JobId=2383 JobName=training_carlib
   UserId=mcetateanu(1000) GroupId=mcetateanu(1001) MCS_label=N/A
   Priority=4294901726 Nice=0 Account=(null) QOS=(null)
   JobState=PENDING Reason=Resources Dependency=(null)
   Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
   RunTime=00:00:00 TimeLimit=3-04:00:00 TimeMin=N/A
   SubmitTime=2018-03-27T10:30:38 EligibleTime=2018-03-27T10:30:38
   StartTime=2018-03-28T10:27:36 EndTime=2018-03-31T14:27:36 Deadline=N/A
   PreemptTime=None SuspendTime=None SecsPreSuspend=0
   Partition=main_compute AllocNode:Sid=zalmoxis:23690
   ReqNodeList=(null) ExcNodeList=(null)
   NodeList=(null) SchedNodeList=cn_burebista
   NumNodes=1 NumCPUs=20 NumTasks=1 CPUs/Task=20 ReqB:S:C:T=0:0:*:*
   TRES=cpu=20,node=1
   Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
   MinCPUsNode=20 MinMemoryNode=0 MinTmpDiskNode=0
   Features=(null) Gres=(null) Reservation=(null)
   OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
   Command=/home/mcetateanu/workspace/CarLib/src/_outputs/linux-xeon_e5v4-icc17.0/bin/classifier/train_classifier.sh
   WorkDir=/home/mcetateanu/workspace/CarLib/src/_outputs/linux-xeon_e5v4-icc17.0/bin/classifier
   StdErr=/home/mcetateanu/workspace/CarLib/src/_outputs/linux-xeon_e5v4-icc17.0/bin/classifier/training_job_2383.out
   StdIn=/dev/null
   StdOut=/home/mcetateanu/workspace/CarLib/src/_outputs/linux-xeon_e5v4-icc17.0/bin/classifier/training_job_2383.out
   Power=

Answer 1

在您的配置中，Slurm 无法在同一核心的两个硬件线程上分配两个作业。在您的示例中，Slurm 需要至少 10 个完全空闲的核心才能开始您的工作。 此外，如果使用默认的

block:cyclic

任务亲和性配置，Slurm 会循环通过套接字在节点中分发任务。

所以我相信正在发生的事情如下：

• 作业 2356 已提交，由于默认任务分配，分配了 16 个物理核
• 作业 2357 已提交，在 8 个物理内核上分配了 2 个硬件线程，覆盖默认任务分配以使作业运行
• 作业 2361 已提交，等待至少 10 个物理核心可用。

您可以使用

获取分配给作业的准确CPU编号

scontrol show -dd job <jobid>

要以一种将硬件线程视为核心线程的方式配置 Slurm，您确实需要定义

SelectTypeParameters=CR_CPU_Memory 

但是你还需要直接在节点定义中指定

CPUs

NodeName=cn_burebista CPUs=56 RealMemory=256000  State=UNKNOWN  

并且不要让 Slurm 从

CPUs

、

Sockets

和

CoresPerSocket

计算

ThreadsPerCore

。

请参阅 slurm.conf 手册页中关于 ThreadsPerCore 的部分有关节点定义的部分。