大型集群管理指南
本文件包含了专门针对包含 1,024 个节点或更多的集群的 Slurm 管理员信息。 目前由 Slurm 管理的一些大型系统示例包括:
- 位于橡树岭国家实验室(ORNL)的 Frontier,拥有 8,699,904 个核心。
- 位于中国国防科技大学的天河-2,拥有 4,981,760 个核心。
- 位于国家能源研究科学计算中心(NERSC)的 Perlmutter,拥有 761,856 个核心。
性能
以下时间是执行一个打印“Hello world”并退出的 MPI 程序的时间,包括处理输出的时间。您的性能可能因硬件、软件和配置的不同而有所变化。
- 在 122,880 个 BlueGene/Q 计算节点上运行 1,966,080 个任务:322 秒
- 在 15,000 个 Linux 集群计算节点上运行 30,000 个任务:30 秒
系统配置
必须设置三个系统配置参数,以支持大量打开的文件和 TCP 连接,并处理大量消息的突发。可以使用 /etc/rc.d/rc.local 或 /etc/sysctl.conf 脚本进行更改,以在重启后保留更改。在这两种情况下,您可以直接将值写入这些文件 (例如 "echo 388067 > /proc/sys/fs/file-max")。
- /proc/sys/fs/file-max: 同时打开的文件的最大数量。适当的数量高度依赖于系统规格和工作负载。我们建议至少从 388067 或您操作系统的默认值开始,以较大者为准。根据您的需求,这个值可能需要向上调整。
- /proc/sys/net/ipv4/tcp_max_syn_backlog: 最大未收到连接客户端确认的连接请求数。 对于内存超过 128Mb 的系统,默认值为 1024,对于低内存机器,默认值为 128。如果服务器出现过载,尝试增加此数字。
- /proc/sys/net/core/somaxconn: socket listen() backlog 的限制,在用户空间称为 SOMAXCONN。默认值为 128。该值应大幅提高以支持请求的突发。 例如,为了支持 1024 个请求的突发,将 somaxconn 设置为 1024。
传输队列长度(txqueuelen)也可能需要使用 ifconfig 命令进行修改。对于一个拥有非常大集群的站点,发现 4096 的值效果很好
(例如 "ifconfig
线程/进程限制
在 SLES 12 SP2 中引入了一个新的限制(用于 Cray 系统,搭载 CLE 6.0UP04,将于 2017 年中发布)。 随 SLES 12 SP2 一起发布的 systemd 版本支持 PIDs cgroup 控制器。 在新的 systemd 版本下,每个 init 脚本或 systemd 服务默认限制为 512 个线程/进程。 这可能会导致在大型集群或高作业吞吐率的系统上出现 slurmctld 和 slurmd 守护进程的问题。 要将限制提高到默认值以上:
- 如果使用 systemd 服务文件:在 [Service] 部分添加 TasksMax=N。N 可以是一个特定数字,或特殊值 infinity。
- 如果使用 init 脚本:创建文件
/etc/systemd/system/<init script name>.service.d/override.conf
内容如下:[Service] TasksMax=N
注意:不支持 PIDs cgroup 控制器的早期版本的 systemd 会简单地忽略 TasksMax 设置。
用户限制
对于 slurmctld 守护进程生效的 ulimit 值应设置得相当高,以便于内存大小、打开文件计数和堆栈大小。
节点选择插件(SelectType)
虽然在节点内分配单个处理器对于较小的集群很有用,但跟踪每个节点内的单个处理器和内存的开销会增加显著的负担。 为了获得最佳的可扩展性,使用 select/linear 分配整个节点,避免使用 select/cons_tres。
作业计费收集插件(JobAcctGatherType)
作业计费依赖于每个计算节点上的 slurmstepd 守护进程定期采样数据。 此数据收集将占用计算周期,导致所谓的 系统噪声。 对于大型并行应用程序,这种系统噪声可能会影响应用程序的可扩展性。 为了获得最佳的应用程序性能,最好禁用作业计费(jobacct_gather/none)。 考虑使用作业完成记录(JobCompType)进行计费,因为这会涉及更少的开销。 如果需要作业计费,请将采样间隔配置为相对较大的值(例如 JobAcctGatherFrequency=task=300)。 可能需要进行一些实验以处理数据传输中的冲突。
节点配置
虽然 Slurm 可以跟踪每个计算节点上实际找到的内存和磁盘空间,并将其用于调度目的,但这会带来额外的开销。 通过使用可用参数(RealMemory、CPUs 和 TmpDisk)指定预期配置来优化性能。 如果发现节点的资源少于配置的资源,它将被标记为 DOWN 并不被使用。 虽然 Slurm 可以轻松处理异构集群,但使用 slurm.conf 中的最少行数配置节点将使管理更容易且性能更好。
定时器
EioTimeout 配置参数控制 srun 命令在用户应用程序终止时等待 slurmstepd 关闭用于转发数据的 TCP/IP 连接的时间。默认值为 60 秒。较大的系统和/或较慢的网络可能需要更高的值。
如果预计会有大量作业(即大量作业具有短暂的执行时间),则将 MinJobAge 配置为您环境中可行的最小间隔。MinJobAge 指定终止作业在 Slurm 控制守护进程中保留的最小秒数,然后才会被清除。在此时间之后,关于终止作业的信息将仅通过计费记录可用。
配置参数 SlurmdTimeout 确定 slurmctld 定期与 slurmd 通信的间隔。 通信发生在 SlurmdTimeout 值的一半。 这样做的目的是确定计算节点何时失败,因此不应分配工作。 较长的间隔会减少计算节点上的系统噪声(我们确实在集群中同步这些请求,但会对应用程序产生一些影响)。 对于真正大型的集群,SlurmdTimeout 值为 120 秒或更长是合理的。
如果使用 MPICH-2,srun 命令将管理用于引导应用程序的密钥对。 根据处理器的速度和架构,密钥对信息的通信可能需要额外的时间。 这可以通过在执行 srun 启动任务之前设置环境变量 PMI_TIME 来完成。 PMI_TIME 的默认值为 500,这是分配给传输每个密钥对的微秒数。 我们已经执行了最多 16,000 个任务,PMI_TIME=4000。
计算节点上的各个 slurmd 守护进程仅在启动时或作业的 epilog 完成时向 slurmctld 守护进程发送消息。当一个作业分配了大量节点并完成时,可能会导致这些节点上的 slurmd 守护进程同时向 slurmctld 守护进程发送大量消息。为了将这些消息流量分散到时间上并避免消息丢失,可以使用 EpilogMsgTime 参数。请注意,即使消息丢失,它们也会被重新传输,但这将导致重新分配资源到新作业的延迟。
其他
Slurm 在 slurmd 守护进程之间使用分层通信,以增加并行性并提高性能。 TreeWidth 配置参数控制消息的分支因子。 默认值为 16,这意味着每个 slurmd 守护进程可以与最多 16 个其他 slurmd 守护进程通信,并且可以通过三次消息跳跃联系到 4368 个节点。 默认值对于大多数集群效果良好。 如果将 TreeWidth 设置为集群中节点数量的立方根,通常可以实现最佳的系统性能。
srun 命令会自动将其打开文件限制提高到硬限制,以处理所有标准输入和输出连接到启动的任务。建议您在整个集群中将打开文件的硬限制设置为 8192。
最后修改于 2024 年 10 月 2 日