深度排查Slurm 任务提交触发 Socket 超时与 TCP 全连接队列溢出实战问题现象在高性能计算HPC集群中用户在提交任务或任务链自动跳转时频繁遇到以下报错终端/sbatch 报错 sbatch: error: Batch job submission failed: Socket timed out on send/recv operationSlurm 控制节点 (slurmctld.log) 报错[2026-03-18T06:52:21.334] JobId9942 InitPrio10000 usec1719 [2026-03-18T06:52:21.334] error: slurm_send_node_msg: [socket:[979361678]] slurm_bufs_sendto(msg_typeRESPONSE_SUBMIT_BATCH_JOB) failed: Unexpected missing socket error更棘手的是虽然生成了 JobID如 9942但由于前序任务如 7842 FAILED的 DependencyNeverSatisfied 状态导致整个任务链陷入死锁。用户频繁重试、管理员疲于排查问题持续恶化。问题深度原因分析经过对系统内核及网络状态的深入采样我们发现了问题的根本原因TCP 全连接队列Accept Queue溢出。2.1 关键监控数据通过 netstat -s 发现内核丢包计数严重异常[rootmaster ~]# netstat -s | grep -i listen 5304 times the listen queue of a socket overflowed 5307 SYNs to LISTEN sockets dropped这两个数字在短时间内急剧增长清晰地表明 TCP 监听队列已经不堪重负。2.2 逻辑拆解问题的根源在于 Slurm 的 net.core.somaxconn 监听队列被塞满让我们一步步拆解整个过程直接原因Slurm 控制守护进程slurmctld的 TCP 全连接队列长度达到上限默认 128新到达的连接请求被内核直接丢弃。间接原因业务逻辑集群启用了 job_submit 自定义插件进行权限校验如 smlg_jobcheck该插件执行需耗时约 2 秒。在任务提交高峰期大量作业并发涌入每个连接都需要经过插件处理才能完成 accept()。木桶效应当同时等待处理的连接数超过 128 时内核开始无情地丢弃Drop新连接导致客户端报错 Unexpected missing socket。这就像一个繁忙的餐厅接待台只能同时服务 128 位顾客超过这个数量就只能让新来的顾客离开。关键字段与配置含义说明在排查和修复过程中我们涉及了以下核心参数理解它们的含义至关重要参数 所属层面 含义net.core.somaxconn Linux 内核 定义了系统中每一个端口监听队列的最大长度上限默认值为 128HPC 场景下明显不足MessageTimeout Slurm 配置 Slurm 组件之间通讯的数据传输超时时间建议在高负载集群设为 30-180sTcpTimeout Slurm 配置 建立 TCP 连接本身的超时时间Send-Q (ss 命令) 网络状态 在 LISTEN 状态下表示该端口当前支持的最大全连接队列深度Recv-Q (ss 命令) 网络状态 表示当前正在队列中等待程序 accept() 的连接数如果持续 0 且接近 Send-Q说明队列正在积压排查命令示例查看 Slurm 主端口的监听队列状态ss -lntp | grep 6817输出示例LISTEN 0 128 *:6817 *:* users:((slurmctld,pid12345,fd12))其中 128 就是当前的 Send-Q最大队列深度解决方法与实施步骤第一步调大内核 TCP 监听上限在管理节点修改内核参数将大门放宽临时生效sysctl -w net.core.somaxconn2048 sysctl -w net.core.netdev_max_backlog5000永久生效编辑 /etc/sysctl.confecho net.core.somaxconn 2048 /etc/sysctl.conf echo net.core.netdev_max_backlog 5000 /etc/sysctl.conf参数说明somaxconn2048将监听队列上限从 128 提升到 2048netdev_max_backlog5000增加网卡接收队列长度防止丢包第二步同步更新 Slurm 全局配置在 slurm.conf 中增加超时容错防止因插件响应慢导致的断连编辑 /etc/slurm/slurm.conf增加通讯耐心MessageTimeout180 TcpTimeout10这两个参数的调整让 Slurm 组件之间更有耐心等待对方响应。第三步重启服务使应用层认账关键提示 修改 somaxconn 后必须重启 slurmctld 进程程序才会重新向内核申请更大的 Send-Q 空间。systemctl restart slurmctld验证结果ss -lntp | grep 6817此时 Send-Q 应该从 128 变为了你设置的内核上限如 2048验证示例输出LISTEN 0 2048 *:6817 *:* users:((slurmctld,pid12345,fd12))第四步业务脚本增加容错最佳实践即使后端再稳健瞬时峰值仍可能存在。建议在任务提交脚本中加入重试机制bash#!/bin/bash监控队列溢出计数是否停止增长watch -n 5 netstat -s | grep -i listen监控当前队列深度watch -n 5 ss -lntp | grep 68175.1 排查思路要点Socket 超时问题不能只看应用层需要从整个链路去排查128 是 Linux 默认的保守设置完全不适合 HPC 高并发场景重启进程是让内核修改在应用层生效的必要步骤这一步经常被忽略监控 netstat -s 是判断网络溢出的最直观手段应该作为常规监控指标
【slurm提交作业超时深度解析】sbatch: error: Batch job submission failed: Socket timed out on send/recv operation
深度排查Slurm 任务提交触发 Socket 超时与 TCP 全连接队列溢出实战问题现象在高性能计算HPC集群中用户在提交任务或任务链自动跳转时频繁遇到以下报错终端/sbatch 报错 sbatch: error: Batch job submission failed: Socket timed out on send/recv operationSlurm 控制节点 (slurmctld.log) 报错[2026-03-18T06:52:21.334] JobId9942 InitPrio10000 usec1719 [2026-03-18T06:52:21.334] error: slurm_send_node_msg: [socket:[979361678]] slurm_bufs_sendto(msg_typeRESPONSE_SUBMIT_BATCH_JOB) failed: Unexpected missing socket error更棘手的是虽然生成了 JobID如 9942但由于前序任务如 7842 FAILED的 DependencyNeverSatisfied 状态导致整个任务链陷入死锁。用户频繁重试、管理员疲于排查问题持续恶化。问题深度原因分析经过对系统内核及网络状态的深入采样我们发现了问题的根本原因TCP 全连接队列Accept Queue溢出。2.1 关键监控数据通过 netstat -s 发现内核丢包计数严重异常[rootmaster ~]# netstat -s | grep -i listen 5304 times the listen queue of a socket overflowed 5307 SYNs to LISTEN sockets dropped这两个数字在短时间内急剧增长清晰地表明 TCP 监听队列已经不堪重负。2.2 逻辑拆解问题的根源在于 Slurm 的 net.core.somaxconn 监听队列被塞满让我们一步步拆解整个过程直接原因Slurm 控制守护进程slurmctld的 TCP 全连接队列长度达到上限默认 128新到达的连接请求被内核直接丢弃。间接原因业务逻辑集群启用了 job_submit 自定义插件进行权限校验如 smlg_jobcheck该插件执行需耗时约 2 秒。在任务提交高峰期大量作业并发涌入每个连接都需要经过插件处理才能完成 accept()。木桶效应当同时等待处理的连接数超过 128 时内核开始无情地丢弃Drop新连接导致客户端报错 Unexpected missing socket。这就像一个繁忙的餐厅接待台只能同时服务 128 位顾客超过这个数量就只能让新来的顾客离开。关键字段与配置含义说明在排查和修复过程中我们涉及了以下核心参数理解它们的含义至关重要参数 所属层面 含义net.core.somaxconn Linux 内核 定义了系统中每一个端口监听队列的最大长度上限默认值为 128HPC 场景下明显不足MessageTimeout Slurm 配置 Slurm 组件之间通讯的数据传输超时时间建议在高负载集群设为 30-180sTcpTimeout Slurm 配置 建立 TCP 连接本身的超时时间Send-Q (ss 命令) 网络状态 在 LISTEN 状态下表示该端口当前支持的最大全连接队列深度Recv-Q (ss 命令) 网络状态 表示当前正在队列中等待程序 accept() 的连接数如果持续 0 且接近 Send-Q说明队列正在积压排查命令示例查看 Slurm 主端口的监听队列状态ss -lntp | grep 6817输出示例LISTEN 0 128 *:6817 *:* users:((slurmctld,pid12345,fd12))其中 128 就是当前的 Send-Q最大队列深度解决方法与实施步骤第一步调大内核 TCP 监听上限在管理节点修改内核参数将大门放宽临时生效sysctl -w net.core.somaxconn2048 sysctl -w net.core.netdev_max_backlog5000永久生效编辑 /etc/sysctl.confecho net.core.somaxconn 2048 /etc/sysctl.conf echo net.core.netdev_max_backlog 5000 /etc/sysctl.conf参数说明somaxconn2048将监听队列上限从 128 提升到 2048netdev_max_backlog5000增加网卡接收队列长度防止丢包第二步同步更新 Slurm 全局配置在 slurm.conf 中增加超时容错防止因插件响应慢导致的断连编辑 /etc/slurm/slurm.conf增加通讯耐心MessageTimeout180 TcpTimeout10这两个参数的调整让 Slurm 组件之间更有耐心等待对方响应。第三步重启服务使应用层认账关键提示 修改 somaxconn 后必须重启 slurmctld 进程程序才会重新向内核申请更大的 Send-Q 空间。systemctl restart slurmctld验证结果ss -lntp | grep 6817此时 Send-Q 应该从 128 变为了你设置的内核上限如 2048验证示例输出LISTEN 0 2048 *:6817 *:* users:((slurmctld,pid12345,fd12))第四步业务脚本增加容错最佳实践即使后端再稳健瞬时峰值仍可能存在。建议在任务提交脚本中加入重试机制bash#!/bin/bash监控队列溢出计数是否停止增长watch -n 5 netstat -s | grep -i listen监控当前队列深度watch -n 5 ss -lntp | grep 68175.1 排查思路要点Socket 超时问题不能只看应用层需要从整个链路去排查128 是 Linux 默认的保守设置完全不适合 HPC 高并发场景重启进程是让内核修改在应用层生效的必要步骤这一步经常被忽略监控 netstat -s 是判断网络溢出的最直观手段应该作为常规监控指标
