TORQUE 6.1.1.1集群作业调度器部署与配置实战

简介Torque 6.1.1.1集群作业管理系统的源码压缩包面向高性能计算集群管理员与分布式调度系统研究人员。Torque由管理节点和计算节点构成管理节点运行pbs_server负责作业调度与队列管理计算节点运行pbs_mom负责作业执行与资源监控客户端命令可部署在任意主机上完成提交、查询与删除等操作覆盖作业全生命周期。包内共2000个文件以C源码1328个、头文件、Makefile及自动化构建脚本为主辅以翻译文件po、日志样例及configure配置脚本压缩后仅13.45MB编排清晰。从核心C实现文件的组织结构可见资源覆盖资源管理、作业执行、请求处理等关键模块梳理这些源代码可还原作业从提交、排队、分发到执行反馈的完整路径同时借助Makefile与configure还能研究跨平台编译和安装流程。已有835人学习浏览适合需要阅读真实调度系统代码、进行二次开发或优化集群运维的中高级技术人员。1. torque-6.1.1.1.tar.gz一个让集群排队干活的老牌调度器把torque-6.1.1.1.tar.gz丢进搜索引擎多半是集群快被抢资源的人。TORQUE 是一款开源的集群作业调度器常见做法是把几十台服务器的 CPU、GPU、内存统一管起来让任务排队、按规则分配资源而不是谁手快谁占机器。这个 tar.gz 是它的源码包不是编译好的二进制拿到手要先自己构建。它适合实验室、小公司和私有云场景里被“抢CPU、占用不释放、半夜还得手动跑脚本”折磨的运维人员和计算用户。6.1.1.1 这个版本号不算新但它稳定、轻量、命令生态与 PBS 兼容今天依然有一批存量集群在跑它。2. 为什么还在用 TORQUE调度器选型与 6.1.1.1 的版本定位2.1 作业调度器到底在管什么调度器的角色可以理解为集群的操作员。用户提交一个作业要 4 核、2 张卡、跑 3 小时。调度器需要判断“现在哪有空位”把作业塞进去跟踪它的状态跑完回收资源。没有调度器时用户各自 SSH 登录节点抢资源通常的结果是有人把 64 核机器占满只跑单线程程序有人半夜起来手动重投作业还有人在群里 管理员问“谁把我的任务挤掉了”。TORQUE 的服务端组件有三个pbs_server负责管理作业队列和调度决策pbs_sched是调度策略模块pbs_mom运行在每个计算节点上真正执行作业并上报资源状态。用户侧的命令是qsub提交、qstat查看、qdel删除。这套命令体验和 PBS 几乎一致是很多老牌集群沿用它的直接原因。调度器的存在还解决了一个隐蔽问题公平性。多个用户抢占机器时如果没有配额和优先级概念资源的分配就是“谁脚本写得猛谁赢”。TORQUE 用队列和 ACl访问控制列表把用户分组、限定资源上限避免单一用户拖垮整个集群。这一点对计算资源要分摊成本的团队尤其重要。2.2 TORQUE、Slurm、PBS 三者的关系与选型边界“TORQUE 是 PBS 的开源分支”这个说法不完全准确它继承了 PBS 的管理理念提供了几乎兼容的命令和配置文件格式。理解三者的关系选择就变得容易维度TORQUESlurm商用 PBS血缘PBS 思想的轻量开源实现独立设计的现代调度器商业产品或其开源变体命令qsub/qstat/qdelPBS 风格sbatch/squeue/scancel自带风格qsub/qstatPBS 风格资源管控插件制需额外配cgroup 内建精细度高企业级支持完善上手成本较低配置集中在少量文件中等需要理解分区与任务步进较低文档齐全典型场景几十台规模、Linux 集群大规模 HPC、GPU 集群需要商业支持的企业集群小规模集群选型时我一般会先问三个问题团队是否已经写过大量qsub脚本节点数是否在五十台以内是否需要 GPU 细粒度切分如果前两个回答“是”第三个回答“否”TORQUE 就是一个合理的存量方案。如果是从零搭建、且未来三年内大概率要扩展到 GPU 大规模混部Slurm 更值得投入。这不代表 TORQUE 落后它只是把问题范围限定在“排队、分配、执行”这三件核心事上不给多余的心智负担。2.3 6.1.1.1 这个版本号里有什么信息torque-6.1.1.1.tar.gz这个文件名本身传递了几个信息。6.1.x 系列大致对应随 Debian、Ubuntu、CentOS 老版本一起分发的那一代6.1.1.1 在主版本线上做过三次修正通常意味着修复了编译问题、Mom 的稳定性问题或调度器的小概率崩溃。看版本号还有一个更实用的角度包的依赖表态。TORQUE 6.x 的源码构建依赖libxml2-devel、openssl-devel、libtool这些在旧系统上基本是标配。如果之前有人装了 6.0 再升级到 6.1.1.1核心要检查的是配置文件server_priv/*和数据库目录能否被新版本兼容。常见做法是保留下面的account、nodes等状态文件替换二进制再重启服务而不是删干净重来。3. 从 tar.gz 到可用集群编译安装 TORQUE 全流程3.1 环境准备与依赖检查在动手之前先确认目标机器是干净的环境。TORQUE 的编译比现代 CMake 项目直观但依赖不全会中途翻车。我一般先跑一遍检查cat /etc/os-release # 确认系统版本和架构 ldconfig -p | grep xml2 # 是否有 libxml2 ldconfig -p | grep ssl # 是否有 openssl which gcc make libtool # 编译工具链输出里如果缺失libxml2或libssl先装对应开发包。以 CentOS 系为例yum install -y gcc make libtool libxml2-devel openssl-devellibxml2-devel是 TORQUE 编译时用于读取配置 XML 的依赖openssl-devel用于认证和通信加密。这两项漏掉configure阶段不会立刻报错但到了make中段才出现头文件缺失的错误反而更浪费时间。检查网络、DNS、/etc/hosts能否解析本机主机名也很关键。TORQUE 在启动时会把主机名写入 server 数据库如果/etc/hosts里把主机名解析到 127.0.0.1后续客户端连接极容易出现“无法认证”的错误。建议先把机器的短主机名和 IP 写进/etc/hosts。3.2 编译安装与常见配置选项解压源码包并进入目录tar -zxvf torque-6.1.1.1.tar.gz cd torque-6.1.1.1 ./configure --prefix/usr --with-server-home/var/spool/torque--prefix/usr表示二进制安装到/usr/bin、库文件到/usr/lib这是最常见的选择能让qsub等命令直接进 PATH。--with-server-home/var/spool/torque指明调度器的运行数据和日志目录这个路径后面排错时会频繁用到。如果机器上同时装了多版本 TORQUE或者不想覆盖系统原有文件可以用./configure --prefix/opt/torque --with-server-home/var/spool/torque但这样需要手动把/opt/torque/bin加入 PATH踩坑概率更高。我的习惯是单实例直接装/usr多实例用/opt/torque并在.bashrc里 export。配置完成后编译make -j$(nproc) make installmake install执行略慢输出很长。关注有没有“install 之后需要手动创建”的提示。TORQUE 安装完毕不会自动初始化服务需要执行make packages # 生成 init.d 脚本和配置样本可选 ./torque.setup root # 初始化 server 数据库./torque.setup root这一句很容易被跳过。它负责创建/var/spool/torque下的server_priv、mom_priv等目录并生成初始配置。跳过它的结果是启动时报 “无法打开 server 数据库文件”。3.3 头节点与计算节点的最小配置TORQUE 的架构是“头节点跑 server 和 sched计算节点跑 mom”。在一台机器上先完成最小验证再把架构扩展到多节点。初始化 server 后首先注册本机为计算节点killall pbs_server pbs_mom pbs_sched # 确保没有残留实例 pbs_server -t create # 首次创建 server 数据库 qmgr -c set server scheduling True qmgr -c set server keep_completed 300 qmgr -c set server query_other_jobs True qmgr -c set server default_queue batch qmgr -c create queue batch qmgr -c set queue batch queue_type Execution qmgr -c set queue batch enabled True qmgr -c set queue batch started True这段命令做了四件事打开调度开关、保存已完成作业记录、允许查看其他作业、创建名为batch的执行队列。没有startedTrue的队列不会接收新作业这常常是“作业一直排队”的原因。注册计算节点用pbsnodespbsnodes -a node01输出中state free、np 32、ncpus 32说明 mom 已上报资源。如果 state 是down先检查节点上的pbs_mom进程和防火墙放行 15001 端口。最后启动调度服务service pbs_server start service pbs_sched start service pbs_mom startTORQUE 6.x 在make install之后会安装 init 脚本但不保证开机自启。确认无报错后再考虑写入chkconfig或 systemd 单元。4. 队列与资源TORQUE 的调度参数怎么设4.1 队列管理命令 qmgr 的基本操作qmgr -c是所有调度参数的入口它的语法是“set/get/create/delete 对象”。对象可分为三类server 级、queue 级、node 级。最常见的误用是把 queue 级的enabled属性设置到 server 上命令会直接报错。查看当前配置qmgr -c print server qmgr -c print queue batchprint server返回的内容很多重点看几项scheduling是否 True、default_queue是否指向存在的队列、resources_default是否配好默认核数。print queue batch看queue_type、enabled、started、resources_max、acl_user_enable。排错场景里最常用的一条qmgr -c set queue batch enabled True qmgr -c set queue batch started True如果作业全部处于Q状态且队列显示未启用多半就是这两项被改掉。enabled表示队列是否允许接受新作业started表示是否允许调度器把作业分配给节点执行。两个都必须是 True 才会正常运行。4.2 调度参数与队列属性对照参数类目配置示例作用说明全局调度set server scheduling True调度器主开关False 时作业全部排队不执行默认资源set server resources_default.nodes 1作业未声明 nodes 时的兜底值保持记录set server keep_completed 300作业完成后记录保留时间单位秒队列类型set queue batch queue_type Execution执行队列作业真正运行的队列队列开关set queue batch enabled True队列是否收作业队列启动set queue batch started True队列是否允许调度执行用户 ACLset queue batch acl_user_enable True开启队列用户白名单节点数上限set queue batch resources_max.nodes 8单作业最多占用节点数acl_user_enable True开启后必须通过qmgr -c set queue batch acl_users user01逐用户添加否则所有用户都会被拒绝提交。项目里常见做法是先在原用户上添加完毕再打开 ACL避免操作中途把整个队列锁死。4.3 作业投递脚本 qsub 的关键参数qsub命令的参数可以在命令行写也可以写成脚本头部的#PBS注释。脚本形式更易管理。#!/bin/bash #PBS -N demo_job #PBS -q batch #PBS -l nodes1:ppn4 #PBS -l walltime02:00:00 #PBS -o /home/user/logs/demo.out #PBS -e /home/user/logs/demo.err cd $PBS_O_WORKDIR echo Job started at $(date) mpirun -np 4 ./my_solver echo Job finished at $(date)#PBS -l nodes1:ppn4表示申请 1 个节点上的 4 个核这是 TORQUE 最常见的 CPU 分配粒度。walltime02:00:00是作业最大运行时长到了这个时间会被强制终止适合防止失控任务占住节点。$PBS_O_WORKDIR是提交作业时的当前目录。如果不 cd 到该目录作业会在 mom 默认目录执行可能找不到输入文件。#PBS -o后面必须写绝对路径且目标目录需要存在否则作业不会失败但输出文件会悄悄消失。命令行投递可变参数更灵活qsub -l nodes2:ppn8 -q gpu submit.sh这里nodes2:ppn8申请 2 个节点各 8 核适合跨节点 MPI 作业。若节点类型还区分了 GPU需要配合节点属性来精确匹配。5. TORQUE 6.1.1.1 避坑指南安装与调度中的 5 个典型问题5.1 节点一直显示 down作业无法被调度现象pbsnodes -a显示state downqsub提交作业后一直排队。原因一是节点上的pbs_mom没有启动或启动即崩溃二是 head 节点到计算节点的 15001 端口通信失败三是 mom 系统时间与 server 相差过大导致心跳超时。解决先看节点侧ps -ef | grep pbs_mom service pbs_mom start tail -f /var/spool/torque/mom_priv/mom_logs/*.log日志是主要线索。常见报错是“cannot connect to server”说明反向连接出了问题。检查/var/spool/torque/mom_priv/config确认$pbsserver指向正确的头节点 IP再确认计算节点能 ping 通头节点、防火墙放行了 15001 端口。如果 mom 进程在但状态还是 down可以尝试pbsnodes -c node01这个命令清除节点上的通信错误计数常能在网络闪断后快速恢复节点状态。5.2 qsub 报错无法连接或认证失败现象qsub执行后提示 “cannot connect to server” 或 “authentication failed”。原因/etc/hosts解析混乱、server 名与server_name文件不一致、时钟偏差。TORQUE 的认证依赖主机名和端口配对任何一方偏差都会导致失败。解决先手动指定 server 地址来定位。qsub -M server01 /path/job.sh如果指定 IP 或正确主机名后能提交说明是解析问题。检查/var/spool/torque/server_name这个文件里保存的就是 server 名内容应该与pbs_server启动时解析到的完全一致。在 client 机器的/etc/hosts中把该主机名指向头节点 IP不要用 127.0.0.1 映射。5.3 作业永远处于 Q 状态队列看起来是启用的现象qstat -a显示作业状态为Qqmgr -c print queue batch显示enabled True、started True但作业不动。原因pbs_sched进程未启动或崩溃。TORQUE 缺了调度器时仍然能接作业但不做任何调度决策作业排队属于正常表象。解决ps -ef | grep pbs_sched service pbs_sched start调度器崩溃还会在/var/spool/torque/server_logs/里留下痕迹。常见诱因是scheduling False需要确认qmgr -c set server scheduling True另有一种隐蔽原因作业申请的节点数与队列resources_max.nodes冲突导致调度器无法满足资源。查队列上限并放宽qmgr -c set queue batch resources_max.nodes 85.4 手动 kill 掉任务后CPU 还是被占满现象qdel删除作业后进程树还在跑CPU 占用不降。原因TORQUE 的pbs_mom在作业结束后负责清理进程组。如果 mom 与作业启动方式不同例如作业通过 shell 嵌套启动子进程可能留下孤儿进程。解决在作业脚本中写入进程组退出逻辑管得最多。trap pkill -P $$; exit 0 TERM INT对于存量孤儿进程在计算节点上手动清理ps -ef | grep -i mpirun kill -9 PID更彻底的做法是给 mom 配置$job_cleanup_time让它在作业结束后主动扫描残留进程组。这个参数在mom_priv/config里设置单位秒我一般写 30。5.5 升级旧版本后作业历史与队列全丢现象从 6.0 或更早版本升级到 6.1.1.1 后qstat -a看不到旧作业节点列表也不在了。原因版本升级时configure --with-server-home与旧安装不一致server 数据库路径被包含或覆盖。解决升级前先备份cp -r /var/spool/torque /var/spool/torque.bak新版本安装完成后先停止服务再把旧备份中的server_priv和mom_priv覆盖回去最后启动service pbs_server stop cp -r /var/spool/torque.bak/server_priv /var/spool/torque/ cp -r /var/spool/torque.bak/mom_priv /var/spool/torque/ service pbs_server start注意备份恢复只适合同系列版本迁移跨大版本时配置格式可能有差异恢复后需要逐个检查队列定义。6. 进阶让 TORQUE 干得漂亮——队列拆分与验证清单6.1 多队列拆分配置示例一个常用的做法是把 GPU 节点与 CPU 节点拆成独立队列避免 CPU 作业占住 GPU 节点的主机资源。在头节点执行qmgr -c create queue gpu qmgr -c set queue gpu queue_type Execution qmgr -c set queue gpu enabled True qmgr -c set queue gpu started True qmgr -c set queue gpu resources_default.nodes 1 qmgr -c set queue gpu resources_max.file_size 100gb qmgr -c set queue gpu acl_user_enable True qmgr -c set queue gpu acl_users user01然后给 GPU 节点打上标志pbsnodes -a node-gpu01 qmgr -c set node node-gpu01 properties gpu有 GPU 属性的作业提交时这样指定qsub -q gpu -l nodes1:ppn8:gpu -l walltime24:00:00 run_train.shnodes1:ppn8:gpu中的:gpu是属性标签TORQUE 会匹配拥有该属性的节点。用属性而不是静态 IP 来管理资源后续扩机器只需要新增节点时声明同样的properties。6.2 一套自检命令验证集群可用装好 TORQUE 之后与其反复“试试提交一个作业”不如跑一遍我在每个新集群都会执行的验证清单ps -ef | grep pbs_server # 头节点 server 存活 ps -ef | grep pbs_mom # 计算节点 mom 全部存活 pbsnodes -a # state 全部 free/occupied无 down qstat -f server # 查看 system 状态 qmgr -c print queue # 确认队列 enabledstarted qsub -q batch echo_test.sh # 投递最小作业 sleep 3 qstat # 确认作业进入 R 状态如果第 3 步出现down节点优先检查那个节点的 mom 日志如果第 7 步作业仍是Q按上一章的排查顺序来。另一件值得做的是记录作业平均排队时长确认没有异常堆积。TORQUE 不自带这样的报表我会写一个简单的 cron 每小时调qstat -a并统计等待数超过阈值就发邮件提醒。老集群迁移到 TORQUE 时我吃过一次亏只验证了“能提交、能运行”没验证节点故障后的自动迁移。后来用一个测试脚本模拟节点宕机才发现pbs_server要等两个心跳周期才能把作业重派到备用节点。这个周期在server_priv/server_config里通过$heartbeat_rate_sec调默认 20 秒容错场景下建议调成 10 秒代价是心跳流量稍大。每一条参数背后都对应一次生产事故这类调度器不像 Web 服务错误往往藏在排队和超时里多做一轮故障演练比多写一个功能脚本更值。希望帮到你。本文还有配套的精品资源点击获取