高吞吐量计算管理指南

本文件包含了 Slurm 管理员关于高吞吐量计算的相关信息,即执行许多短作业。为了获得高吞吐量计算的最佳性能,确实需要进行一些调整,本文件应能帮助您顺利开始。对 Slurm 的基本了解应被视为学习本材料的前提。

性能结果

Slurm 也已被验证可以持续执行每秒 500 个简单的批处理作业,并在短时间内达到更高的活动水平。实际性能取决于要执行的作业以及所使用的硬件和配置。

系统配置

为了支持大量打开的文件和 TCP 连接以及大量消息的突发,可能需要修改多个系统配置参数。可以使用 /etc/rc.d/rc.local/etc/sysctl.conf 脚本进行更改,以在重启后保留更改。在这两种情况下,您可以直接将值写入这些文件 (例如 "echo 32832 > /proc/sys/fs/file-max")。

  • /proc/sys/fs/file-max: 同时打开的文件的最大数量。我们建议限制至少为 32,832。
  • /proc/sys/net/ipv4/tcp_max_syn_backlog: 在内存中保留的 SYN 请求的最大数量,这些请求尚未收到来自三次握手的第三个数据包。对于内存超过 128Mb 的系统,默认值为 1024,对于低内存机器,默认值为 128。如果服务器出现过载,请尝试增加此数字。
  • /proc/sys/net/ipv4/tcp_syncookies: 当特定套接字的内核 SYN 队列溢出时,用于向主机发送 syncookies。默认值为 0,禁用此功能。将值设置为 1。
  • /proc/sys/net/ipv4/tcp_synack_retries: 对 SYN 请求重传 SYN,ACK 回复的次数。换句话说,这告诉系统尝试建立由另一台主机发起的被动 TCP 连接的次数。此变量取整数值,但在任何情况下都不应大于 255。每次重传大约需要 30 到 40 秒。默认值为 5,这导致被动 TCP 连接的超时约为 180 秒,通常是令人满意的。
  • /proc/sys/net/core/somaxconn: 套接字 listen() 队列的限制,在用户空间称为 SOMAXCONN。默认值为 128。该值应大幅提高以支持请求的突发。例如,要支持 1024 个请求的突发,将 somaxconn 设置为 1024。
  • /proc/sys/net/ipv4/ip_local_port_range: 识别可用的临时端口,这些端口用于许多 Slurm 通信。可以提高该值以支持大量通信。例如,将值 "32768 65535" 写入 ip_local_port_range 文件,以使该范围的端口可用。

传输队列长度 (txqueuelen) 也可能需要使用 ifconfig 命令进行修改。对于一个拥有非常大集群的站点,发现 4096 的值效果很好 (例如 "ifconfig txqueuelen 4096")。

Munge 配置

默认情况下,Munge 守护进程运行两个线程,但更高的线程数可以提高其吞吐量。我们建议为高吞吐量支持启动十个线程的 Munge 守护进程(例如 "munged --num-threads 10")。

用户限制

slurmctld 守护进程的 ulimit 值应设置得相当高,以支持内存大小、打开文件数量和堆栈大小。

Slurm 配置

几个 Slurm 配置参数应调整以反映高吞吐量计算的需求。以下描述的更改在所有环境中可能无法实现,但这些是您可能希望考虑以提高吞吐量的配置选项。

  • AccountingStorageType: 通过不设置此插件来禁用存储会计记录。关闭会计提供的性能提升很小。如果使用 SlurmDBD,通过在 slurmdbd.conf 中设置 CommitDelay 选项可以实现更快的速度。
  • JobAcctGatherType: 禁用作业会计信息的收集将提高作业吞吐量。通过使用 jobacct_gather/none 插件禁用会计收集。
  • JobCompType: 禁用作业完成信息的记录将提高作业吞吐量。通过使用 jobcomp/none 插件禁用作业完成信息的记录。
  • JobSubmitPlugins: 不建议使用 lua 作业提交插件。slurmctld 在持有内部锁时运行此脚本,并且一次只能运行一个副本。这会阻塞 slurmctld 中的大多数并发。因此,我们不建议在高吞吐量环境中使用它。
  • MaxJobCount: 控制在任何时间点 slurmctld 守护进程记录中可以存在多少作业(待处理、运行、挂起或完成[暂时])。默认值为 10,000。
  • MessageTimeout: 控制等待消息响应的时间。默认值为 10 秒。虽然 slurmctld 守护进程具有高度线程化,但其响应能力依赖于负载。此值可能需要稍微增加。
  • MinJobAge: 控制完成作业的记录可以从 slurmctld 内存中清除的时间,因此在使用 squeue 命令时不可见。运行的作业记录将保留在会计记录和日志中。默认值为 300 秒。如果可能,应该将该值减少到几秒钟。使用旧作业的会计记录可以提高作业吞吐率,相比于将旧作业保留在 slurmctld 守护进程的内存中。
  • PriorityTypepriority/basic 比其他选项快得多,但仅按先进先出(FIFO)方式调度作业。
  • PrologSlurmctld/EpilogSlurmctld: 在高吞吐量环境中不推荐使用这两者。当启用时,每个作业启动(或作业数组的任务)都必须创建一个单独的 slurmctld 线程。当前架构要求在每个线程中获取作业写锁,这是一个代价高昂的操作,严重限制了调度器的吞吐量。
  • SchedulerParameters: 有许多调度参数可用。
    • 设置选项 batch_sched_delay 将控制批处理作业的调度可以延迟多长时间。这仅影响批处理作业。例如,如果每秒提交许多作业,则尝试调度每个作业的开销将对作业提交速率产生不利影响。默认值为 3 秒。
    • 设置选项 defer 将避免在作业提交时尝试单独调度每个作业,而是将其推迟到稍后的时间,以便可以同时调度多个作业。此选项可以提高系统响应能力,当大量作业(数百个)同时提交时,但会延迟单个作业的启动时间。
    • 设置 defer_batch 选项类似于上述 defer 选项。不同之处在于 defer_batch 将允许交互式作业立即启动,但使用 sbatch 提交的作业将被推迟,以允许多个作业积累并同时调度。
    • sched_min_interval 是另一个配置参数,用于控制调度逻辑运行的频率。它仍然可以在每个作业提交、作业终止或其他可能允许新作业启动的状态变化时触发。然而,该触发不会导致调度逻辑立即启动,而仅在配置的 sched_interval 内部启动。例如,如果 sched_min_interval=2000000(微秒)并且在 2 秒的时间窗口内提交了 100 个作业,则调度逻辑将执行一次,而不是如果 sched_min_interval 设置为 0(无延迟)时的 100 次。
    • 除了控制调度逻辑执行的频率外,default_queue_depth 配置参数控制在每次调度器迭代中考虑启动多少作业。default_queue_depth 的默认值为 100(作业),在大多数情况下应该是可以的。
    • sched/backfill 插件如果与大量作业一起使用则开销相对较高。将 bf_max_job_test 配置为适中的大小(例如 100 个作业或更少)和 bf_interval 配置为 30 秒或更长时间,将限制回填调度的开销(注意:这两个参数的默认值都很好)。其他可用于调整回填调度的回填选项包括 bf_max_job_userbf_resolutionbf_window。有关详细信息,请参阅 slurm.conf 手册页。
    • 以下是一组当前用于在一个集群上持续运行数百个作业的调度参数。请注意,每个环境都是不同的,这组参数在每种情况下可能效果不佳,但可能作为一个良好的起点。
      • batch_sched_delay=20
      • bf_continue
      • bf_interval=300
      • bf_min_age_reserve=10800
      • bf_resolution=600
      • bf_yield_interval=1000000
      • partition_job_depth=500
      • sched_max_job_start=200
      • sched_min_interval=2000000
  • SlurmctldParameters: 许多 slurmctld 守护进程参数可用。
    • 增加 conmgr_max_connections 将允许 slurmctld 同时接受更多连接,以避免在高负载期间出现 connect() 超时,但不一定会避免读或写超时。权衡是 slurmctld 将使用更多内存,因为每个连接保留内存以缓冲入站和出站数据以及连接状态。conmgr_max_connections 至少应为可用硬件 CPU 线程的数量,但应小于 sysctl net.nf_conntrack_maxsysctl net.core.somaxconn。建议启用 sysctl net.ipv4.tcp_syncookies=1,以允许内核更好地管理较大的传入套接字突发。当修改此参数时,您应监控 sdiag 输出中的相对变化。Remote Procedure Call statistics 下的 ave_time 字段部分应特别关注,因为其变化可能对整体响应时间产生重大影响。过度增加 conmgr_max_connections 可能导致 内存不足 事件,从而导致 slurmctld 崩溃,可能会丢失作业和会计。建议站点在更改 conmgr_max_connections 参数之前尝试更改 MessageTimeoutTCPTimeout
    • conmgr_threads 选项控制用于处理通信的线程池的大小。根据需要使用线程来处理 I/O 或处理传入的 RPC 并生成回复。权衡是 slurmctld 将为每个额外线程使用更多内存。当线程数超过可用硬件 CPU 时,增加线程数还会导致内核调度程序争用增加,从而增加线程饥饿的潜在性。在处理传入的 RPC 请求时,slurmctld 通常需要获取一个或多个全局 slurmctld 锁。每个尝试获取锁的线程都可能导致与调度线程的争用增加。锁争用将导致作业调度程序运行得更慢或出现不可忽视的延迟。希望获得更多 RPC 吞吐量的站点可以增加 conmgr_threads 的默认值,而希望优先考虑调度线程的站点可以减少线程数。建议站点在更改此参数时监控 sdiag 的作业启动统计信息。conmgr_threads 至少应为可用的硬件 CPU 线程数的 2-4 倍,因为大多数 RPC 处理需要等待全局锁。过度增加 conmgr_threads 可能导致 内存不足 事件,从而导致 slurmctld 崩溃,可能会丢失作业和会计。
  • SchedulerType: 如果大多数作业是短暂的,则建议使用 sched/builtin 插件。它按先进先出(FIFO)方式管理作业队列,并消除了按优先级对队列进行排序的逻辑。
  • SlurmctldDebug: 更详细的日志记录将降低系统吞吐量。对于高吞吐量工作负载的常规操作,将其设置为 errorinfo
  • SlurmctldPort: 建议将 slurmctld 守护进程配置为在多个端口上接受传入消息,以避免由于超过上述 SOMAXCONN 限制而导致的传入消息被操作系统丢弃。在需要支持大量同时请求时,建议使用两个到十个端口。
  • SlurmdDebug: 更详细的日志记录将降低系统吞吐量。对于高吞吐量工作负载的常规操作,将其设置为 errorinfo
  • SlurmdLogFile: 建议写入本地存储。
  • rl_bucket_size 定义最大令牌数,通过 rl_refill_rate 定义新令牌添加的速率,通过 rl_refill_period 定义令牌的补充频率,通过 rl_table_size 定义要跟踪的实体数量。通过 rl_enable 启用。
  • 其他:将日志记录、会计和其他开销配置为适合您环境的最低值。

SlurmDBD 配置

关闭会计提供的性能提升很小。如果使用 SlurmDBD,通过在 slurmdbd.conf 中设置 CommitDelay 选项,可以在 slurmdbd 接收到来自 slurmctld 的连接和提交信息到数据库之间引入延迟。这允许多个请求被累积,并减少提交到数据库的请求数量。

您还可以考虑在 slurmdbd.conf 中设置 'Purge*' 选项以清除旧数据。典型配置如下所示...

  • PurgeEventAfter=12个月
  • PurgeJobAfter=12个月
  • PurgeResvAfter=2个月
  • PurgeStepAfter=2个月
  • PurgeSuspendAfter=1个月
  • PurgeTXNAfter=12个月
  • PurgeUsageAfter=12个月

最后修改于 2025 年 3 月 13 日