☰

SLURM 允许使用比请求更多的 CPU 的作业启动

tag-icon • tag-icon bash scheduled-tasks queue job-control queue-management
SLURM 允许使用比请求更多的 CPU 的作业启动

我使用 SLURM 时遇到的问题可以总结如下。考虑一个test.sh请求 8 个 CPU 但实际上使用 10 个 CPU 启动作业的 bash 脚本：

#!/bin/sh
#SBATCH --ntasks=8
stress -c 10

在具有 32 个 CPU 的服务器上，如果我使用 启动此脚本 5 次sbatch test.sh，其中 4 次将立即开始运行，最后一个显示为待处理，如下squeue命令所示：

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
    5      main  test.sh     jack PD       0:00      1 (Resources)
    1      main  test.sh     jack  R       0:08      1 server
    2      main  test.sh     jack  R       0:08      1 server
    3      main  test.sh     jack  R       0:05      1 server
    4      main  test.sh     jack  R       0:05      1 server

问题是这 4 个作业实际上使用了 40 个 CPU，导致系统超载。相反，我希望 SLURM 要么不启动实际使用的资源多于用户请求的作业，要么将它们搁置，直到有足够的资源来启动它们。

关于我的文件的一些有用详细信息slurm.conf：

# SCHEDULING                                                                       
#DefMemPerCPU=0                                                                    
FastSchedule=1                                                                     
#MaxMemPerCPU=0                                                                    
SchedulerType=sched/backfill                                                       
SchedulerPort=7321                                                                 
SelectType=select/cons_res                                                         
SelectTypeParameters=CR_CPU
# COMPUTE NODES                                                                 
NodeName=server CPUs=32 RealMemory=10000 State=UNKNOWN                   
# PARTITIONS                                                                    
PartitionName=main Nodes=server Default=YES Shared=YES MaxTime=INFINITE State=UP

我刚刚开始使用 SLURM，我对这种行为感到困惑。我如何确保我的服务器用户不会启动使用过多 CPU 的作业？我阅读了手册，花了很多时间在论坛上寻找信息，但不幸的是，我没有找到任何有用的信息。

在此先非常感谢您的帮助！

答案1

Slurm 无法知道脚本将创建多少个进程/线程。它只能依靠请求的资源，因此它用它来安排作业。

这里最好的方法是使用 Slurm 中的任何亲和力插件来防止作业使用超过请求的资源。此插件将作业绑定到请求的 CPU。（亲和性文档）

显然，您无法控制用户在其脚本中启动了多少个进程/线程，但限制作业可以使用的核心数量将减少不受控制的用户对其他用户作业造成的影响。

这不会阻止您的系统出现超载现象，但“坏”用户只会影响他们自己。

答案2

下列的我们在 SO 上的讨论我一直在尝试使用--exclusive参数来实现这一点。我的架构与您的不同（我有 7 个处理器可用于 slurm），但我所做的如下：

#!/bin/sh
#SBATCH --ntasks=2    
srun -n 2 --exclusive stress -c 1

然后运行

sbatch test.sh ; sbatch test.sh ; sbatch test.sh ; sbatch test.sh

给了我6个stress流程：

15050 tom       20   0    7308    212    108 R 100.0  0.0   1:47.46 stress                                                                                                              
15054 tom       20   0    7308    208    108 R 100.0  0.0   1:47.47 stress                                                                                                              
15063 tom       20   0    7308    208    108 R 100.0  0.0   1:47.47 stress                                                                                                              
15064 tom       20   0    7308    212    108 R 100.0  0.0   1:47.47 stress                                                                                                              
15080 tom       20   0    7308    208    108 R 100.0  0.0   1:47.46 stress                                                                                                            
15076 tom       20   0    7308    212    108 R  99.7  0.0   1:47.45 stress

最后一个在队列中等待：

     JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
      2368       Tom  test.sh      tom PD       0:00      1 (Resources)
      2365       Tom  test.sh      tom  R       5:03      1 Tom
      2366       Tom  test.sh      tom  R       5:03      1 Tom
      2367       Tom  test.sh      tom  R       5:03      1 Tom

因此，在这种情况下，使用srun -n 2会导致同一进程启动两次。如果我使用，也会发生同样的事情

#!/bin/sh
#SBATCH --ntasks=2
srun -n 1 --exclusive stress -c 1 &
srun -n 1 --exclusive stress -c 1 &
srun -n 1 --exclusive stress -c 1 &
wait

即 SLURM 知道这个批处理脚本有两个任务，所以它会让两个任务同时运行；第三个任务必须“等待轮到它”。

另一方面

#!/bin/sh
#SBATCH --ntasks=1
srun -n 1 --exclusive stress -c 2

给我你在问题中描述的行为。

不确定这是否能完全回答你的问题但也许有一点帮助。

相关内容