阵列作业的 SLURM 速度很慢

Question

我有一个包含节点 A、B、C 和 D 的小集群。每个节点有 80GB RAM 和 32 个 CPU。我正在使用 Slurm 17.11.7。

我执行了以下基准测试：

• 如果我直接在节点 A 上的终端上运行特定的 Java 命令，我会在 2 分钟内得到结果。
• 如果我使用"单个"数组作业(#SBATCH --array=1-1(运行相同的命令，我会在 2 分钟内再次获得结果。
• 如果我仅在节点 A 上的 slurm 上使用数组作业使用相同的参数运行相同的命令，则我以 8mininutes 为单位获得输出，也就是说，它慢了四倍。在这里，我当然同时运行其他 31 个具有不同参数的 Java 命令。

我已经尝试了 SelectTypeParameters=CR_CPU_Memory 和 SelectTypeParameters=CR_Core 的结果相同。

为什么我的阵列作业慢了 4 倍？感谢您的帮助！

我提交的数组作业的标头如下所示：

#!/bin/bash -l
#SBATCH --array=1-42
#SBATCH --job-name exp
#SBATCH --output logs/output_%A_%a.txt
#SBATCH --error logs/error_%A_%a.txt
#SBATCH --time=20:00
#SBATCH --mem=2048
#SBATCH --cpus-per-task=1
#SBATCH -w <NodeA>

slurm.conf 文件如下所示：

ControlMachine=<NodeA>
ControlAddr=<IPNodeA>
MpiDefault=none
ProctrackType=proctrack/cgroup
ReturnToService=1
SlurmctldPidFile=/var/run/slurmctld.pid
SlurmdPidFile=/var/run/slurmd.pid
SlurmdSpoolDir=/var/spool/slurmd
SlurmUser=<test_user_123>
StateSaveLocation=/var/spool/slurmctld
SwitchType=switch/none
TaskPlugin=task/affinity
MaxJobCount=100000
MaxArraySize=15000
MinJobAge=300
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
SelectType=select/cons_res
SelectTypeParameters=CR_CPU_Memory
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=Cluster
JobAcctGatherType=jobacct_gather/none
SlurmctldLogFile=/var/log/slurmctld.log
SlurmdLogFile=/var/log/slurmd.log
# COMPUTE NODES
#NodeName=NameA-D> State=UNKNOWN
NodeName=<NameA> NodeAddr=<IPNodeA> State=UNKNOWN CPUs=32 RealMemory=70363
NodeName=<NameB> NodeAddr=<IPNodeB> State=UNKNOWN CPUs=32 RealMemory=70363
NodeName=<NameC> NodeAddr=<IPNodeC> State=UNKNOWN CPUs=32 RealMemory=70363
NodeName=<NameD> NodeAddr=<IPNodeD> State=UNKNOWN CPUs=32 RealMemory=70363
PartitionName=debug Nodes=<NodeA-D> Default=YES MaxTime=INFINITE State=UP

Answer 1

如果运行时间不依赖于 Java 应用程序中参数的值，则有两种可能的解释：

要么您的cgroup配置不限制您的作业，要么您的 Java 代码是多线程的。在这种情况下，如果仅运行一个作业，或者直接在节点上运行，则单个任务将并行使用多个 CPU。如果运行使节点饱和的作业阵列，则每个任务只能使用单个 CPU。

或者，您的节点配置了超线程。在这种情况下，如果仅运行一个作业，或者直接在节点上运行，则单个任务可以使用完整的 CPU。如果运行使节点饱和的作业阵列，则每个任务必须与另一个任务共享一个物理 CPU。