Slurm配置中Dask节点、Worker与计算节点区别及配置问题咨询

您好，我目前仍在学习相关技术，若术语使用存在混淆或错误还请谅解。我正在为支持Slurm调度的自适应Dask集群编写配置。

超算compute分区基础配置 #

• 分区规则：单作业最大可申请512节点，作业最长运行时长8小时，无同时使用资源总量上限，节点不支持多作业共享，分配给作业的计算节点由作业独占
• 硬件配置：共部署2659台AMD EPYC 7763 Milan计算节点，专为并行科学计算场景设计；单节点配备64个物理CPU核心，支持128线程
• 内存规则：官方文档标注每CPU默认分配内存1920MB、最大可分配8000MB，实际scontrol show partition查询到的分区配置如下：

PartitionName=compute
   AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
   AllocNodes=ALL Default=NO QoS=N/A
   DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO GraceTime=0 Hidden=NO
   MaxNodes=512 MaxTime=08:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
   Nodes=l[10000-10058,10061-10062,10064-10065,10067-10068,10070-10083,10090-10095,10100-10158,10160-10183,10190-10195,10200-10258,10260-10283,10290-10295,10300-10357,10359-10383,10390-10395,10400-10483,10490-10495,10500-10583,10590-10595,10600-10683,10690-10695,10700-10783,10790-10795,20000-20059,20061-20062,20064-20065,20067-20068,20070-20083,20090-20095,20100-20183,20190-20195,20200-20223,20225-20283,20290-20295,20300-20383,20390-20395,20400-20483,20490-20495,20500-20583,20590-20595,20600-20683,20690-20695,30000-30059,30061-30062,30064-30083,30090-30095,30100-30183,30190-30195,30200-30230,30232-30283,30290-30295,30300-30383,30390-30395,30400-30483,30490-30495,30500-30583,30590-30595,30600-30683,30690-30695,30700-30760,30762-30783,30790-30795,40000-40026,40028-40029,40031-40032,40034-40035,40037-40038,40040-40083,40090-40095,40101-40102,40104-40105,40107-40108,40110-40111,40113-40183,40190-40195,40200-40283,40287-40295,40300-40359,40400-40483,40490-40495,40500-40583,40587-40595,40600-40683,40687-40695,50200-50259,50269-50271,50300-50359,50369-50371]
   PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=EXCLUSIVE
   OverTimeLimit=NONE PreemptMode=OFF
   State=UP TotalCPUs=711168 TotalNodes=2778 SelectTypeParameters=NONE
   JobDefaults=(null)
   DefMemPerCPU=960 MaxMemPerCPU=3840

注意：实际查询到的配置为每CPU默认分配960MB、最大可分配3840MB，和公开文档标注不符，配置时以实际scontrol输出为准。

当前编写的SLURMCluster初始化代码 #

cluster = SLURMCluster(
    name='dask-cluster', 
    processes=32,
    cores=64,
    memory=f"{8000 * 64 * 0.90} MB",
    project="ab0995",
    queue="compute",
    interface='ib0',
    walltime='08:00:00',
    asynchronous=0,
    # job_extra=["--ntasks-per-node=50",],
)

初始配置思路 #

• 文档提到的节点指Slurm管理的物理计算服务器节点，并非Dask层面的节点，猜测Dask节点实际指Dask Worker，需要明确术语定义；按文档标注的每核最大8000MB内存，总内存按8000*64乘以0.9安全系数设置，避免资源申请超限。
• 单节点64核对应cores参数设为64，计划为每个Python进程分配2个CPU核心，因此processes设为32，后续可能调整为每个进程分配4核，但不确定参数调优方法。
• 作业walltime设为分区允许的最大值8小时，相比反复提交作业排队，独占单节点运行即使有部分资源闲置，整体效率更高。

自动生成的作业脚本 #

配置完成后打印自动生成的作业脚本如下：

#!/usr/bin/env bash

#SBATCH -J dask-worker
#SBATCH -p compute
#SBATCH -A ab0995
#SBATCH -n 1
#SBATCH --cpus-per-task=64
#SBATCH --mem=430G
#SBATCH -t 08:00:00

/work/ab0995/AWIsoft/miniconda/NextGEMS/.conda/bin/python -m distributed.cli.dask_worker tcp://136.172.120.121:36449 --nthreads 2 --nprocs 32 --memory-limit 13.41GiB --name dummy-name --nanny --death-timeout 60 --interface ib0 --protocol tcp://

具体问题解答 #

1. 内存计算值与生成脚本--mem参数值偏差原因 #

数值偏差来自两个层面的计算逻辑：

• 单位换算差异：你传入的内存值按十进制单位计算（1GB=1000MB），但Dask和Slurm默认使用二进制单位计算内存（1GiB=1024MiB），你计算的460800MB（十进制）换算为二进制单位约为450GiB。
• 预留内存开销：Dask会默认从总申请内存中划出约5%的余量，留给系统进程、Worker守护进程（nanny）使用，避免Worker进程触碰到Slurm的内存阈值被OOM杀死，最终向下取整得到430G的数值。
  额外提醒：按scontrol实际输出的MaxMemPerCPU=3840MB计算，单节点最大可申请内存仅为240GiB，你当前配置的430G已经超出分区限制，会直接被Slurm调度器拒绝，需要下调内存配置。

2. dask_worker启动参数含义与计算逻辑 #

三个参数直接对应你传入的SLURMCluster配置，具体逻辑如下：

• --nprocs 32：指单个Slurm作业（即单台物理计算节点）上启动的Dask Worker进程总数，取值直接等于你设置的processes=32参数。每个Worker是独立的Python解释器，有独立的GIL锁，可以规避Python单进程多线程的GIL性能限制。
• --nthreads 2：指每个Worker进程内部启动的工作线程数，计算逻辑为总核心数/总进程数=64/32=2。同一进程内的线程共享内存空间，适合执行IO密集型任务、以及底层释放GIL的数值计算任务（如numpy、pandas的C实现操作）。
• --memory-limit 13.41GiB：指单个Worker进程可使用的内存上限，计算逻辑为总申请内存/总进程数=430G/32≈13.41GiB。当Worker内存使用超过该阈值时，Dask会自动触发溢出处理逻辑，比如将冷数据转存到磁盘、重启异常Worker，避免进程被系统强制杀死。

3. 三个核心概念的定义与区别 #

• Slurm计算节点：是Slurm管理的硬件实体，即机房中实际部署的物理服务器，配备独立的CPU、内存资源，是Slurm调度资源的最小硬件单元。你所用集群的节点为独占模式，一个作业分配到节点后，其他作业无法使用该节点上的任何资源。
• Dask节点：是Dask集群拓扑中的逻辑概念，泛指所有加入Dask集群的运行实体，既包括运行调度逻辑的Scheduler节点，也包括执行计算任务的Worker节点，没有固定的硬件绑定关系。日常交流中很多人会把Dask Worker俗称为Dask节点，属于不严谨的简称。
• Dask Worker：是Dask中实际执行计算任务的工作进程，是Dask调度的最小计算单元。每个Worker会主动向Scheduler上报自身持有的CPU、内存资源，接收Scheduler分配的任务执行并返回结果。你当前的配置下，一台Slurm物理计算节点上会启动32个独立的Dask Worker进程。

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