高吞吐量计算管理指南

本文件包含了 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 守护进程的内存中。
  • PriorityType： priority/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_user、bf_resolution 和 bf_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_max 和 sysctl net.core.somaxconn。建议启用 sysctl net.ipv4.tcp_syncookies=1，以允许内核更好地管理较大的传入套接字突发。当修改此参数时，您应监控 sdiag 输出中的相对变化。Remote Procedure Call statistics 下的 ave_time 字段部分应特别关注，因为其变化可能对整体响应时间产生重大影响。过度增加 conmgr_max_connections 可能导致 内存不足 事件，从而导致 slurmctld 崩溃，可能会丢失作业和会计。建议站点在更改 conmgr_max_connections 参数之前尝试更改 MessageTimeout 和 TCPTimeout。
    • 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： 更详细的日志记录将降低系统吞吐量。对于高吞吐量工作负载的常规操作，将其设置为 error 或 info。
  • SlurmctldPort： 建议将 slurmctld 守护进程配置为在多个端口上接受传入消息，以避免由于超过上述 SOMAXCONN 限制而导致的传入消息被操作系统丢弃。在需要支持大量同时请求时，建议使用两个到十个端口。
  • SlurmdDebug： 更详细的日志记录将降低系统吞吐量。对于高吞吐量工作负载的常规操作，将其设置为 error 或 info。
  • 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 日