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

我一次又一次地阅读文档，但我无法弄清楚我做错了什么... 为什么我有上述情况？我应该如何更改配置才能使其正常工作？

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

修改

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

  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为什么要求核心？这是我的reference document。

编辑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 manpage部分中有关节点定义的ThreadsPerCore部分。

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

1 个答案: