★ FEATURED ARTICLE 简介Torque 6.1.1.1 是开源的集群资源管理与作业调度系统源码包面向HPC集群管理员、运维工程师及需要二次开发的科研人员用于搭建并管理由 pbs_server 服务端与 pbs_mom 计算节点组成的 Torque 集群环境。压缩包内共2000个文件以C源码、C头文件、Makefile编译脚本、配置文件模板及日志文件为主体并包含少量辅助脚本与文档整体体积仅13.45MB适合快速下载与编译。目前已有835人学习或下载可作为上手 Torque 队列系统的实际参考。通过源码可深入理解作业提交、调度、执行及节点状态监控的核心流程包内还提供安装配置样例、平台适配说明和排错辅助文件便于在实践中完成集群部署、参数调优与问题定位。1. TORQUE 6.1.1.1 是什么不是普通压缩包而是一套集群作业调度器拿到 torque-6.1.1.1.tar.gz 这个文件别把它当成普通源码包解压玩玩就完事。TORQUE 是一套脱胎于 PBS 的开源集群作业调度器这个 6.1.1.1 版本是 6.x 系列里的补丁版解决过 mom 重连、调度器内存增长这类实际毛病。它的核心价值一句话当多台机器、多个用户、多个计算任务混在一起时由它决定每个任务去哪台机器、占几个核、跑多久、谁排队谁先跑还能把资源消耗记录留下来。如果你手头有五台以上 Linux 服务器要跑仿真、数据处理或者批量计算人工分配已经乱到不可维护那这个包值得你花一个下午编译起来。本文按我平时搭集群的路线走先讲组件模型和编译选型再给一套最小可复现的安装启动命令然后把队列配置和五个高频翻车现场摊开最后落到可验证的进阶技巧上。2. 装它之前TORQUE 6 的组件模型和编译环境准备2.1 pbs_server、pbs_mom、pbs_sched一个调度器的三个零件TORQUE 在架构上是典型的主从模型核心进程有三个。pbs_server 是中心节点维护所有作业状态、队列定义、节点清单所有 qsub、qstat、qmgr 命令都是先连到它pbs_sched 是调度器按照队列属性和资源占用决定哪个作业被分配到哪个节点pbs_mom 跑在每台计算节点上接收 server 下发的作业替用户拉起脚本进程再回传状态和资源数据。常见做法里还有第四个进程 trqauthd它是认证守护进程在配置了 munge 认证时才必须跑纯 host 认证环境可以不管它。理解这三个零件的关系比背一百条命令都重要。装完系统后你看到进程列表就能定位问题只有 pbs_server 起来了qsub 不报错但作业永远停在 Q因为没人做调度只有 pbs_mom 起来了pbsnodes -a 里所有节点全是 downpbs_sched 异常退出最典型的表现是队列里有作业、节点空闲但调度器就是不动。所以排查的第一步永远是先看这三个进程在不在而不是去翻队列配置。这三个进程的启动顺序也有讲究。pbs_server 是老大pbs_sched 和 pbs_mom 都依赖它pbs_server 重启时所有 mom 会断连过一段时间自动重连这个期间节点显示 down 是正常的。我见过有人一看到 down 就手动重启所有 mom反而把重连状态搞乱。正确做法是给 mom 几分钟自动重连时间再看 pbsnodes -a 的 state 列。2.2 环境依赖清单gcc、openssl-devel 与 boost 一个都不能少源码编译第一步是装全依赖这一步省了后面 configure 会一遍一遍退出非常消耗耐心。TORQUE 6.1.1.1 编译常见的依赖有这些gcc、g、make 是编译器基础openssl-devel 提供加密库libxml2-devel 是 XML 解析库boost-devel 是 C 库TORQUE 6 的调度器代码对 boost 有硬依赖。服务器上如果只装了运行库没装 -devel 开发包configure 一样会失败因为缺的是头文件而不是运行库。包管理器命令按发行版替换写法一般是yum install -y gcc gcc-c make openssl-devel libxml2-devel boost-devel # Debian/Ubuntu 系对应包名不同常见是 gcc g make libssl-dev libxml2-dev libboost-all-dev这条命令里每个包都有明确用途gcc 和 gcc-c 负责编译 C 和 C 代码openssl-devel 提供认证相关的加密接口libxml2-devel 用于解析集群配置里的 XML 片段boost-devel 给调度器提供智能指针和线程工具。如果机器内存很小并行编译会顶不住建议关掉 -j 参数后面第 3 章会展开。configure 脚本对缺失库的处理方式很直接打印一行错误就退出。所以不要在一长串输出里找原因直接看最后几行。通常它会明确告诉你缺的是哪个头文件比如找不到 boost 相关头文件就是 boost-devel 没装。装完再跑一次 configure 即可不需要重新解压。2.3 configure 的三个关键选择prefix、server-home 与认证方式configure 参数决定了整个集群的数据根目录装完再改非常麻烦我一般会在这一步停下来想清楚。三个最关键的选项--prefix 指定二进制安装位置默认是 /usr/local直接装在系统目录里也可以但后续升级想换版本时独立的 prefix 目录会干净很多--with-server-home 指定调度数据目录包括节点清单、作业日志、记账文件默认是 /var/spool/torque--disable-gui 关闭 TCL/TK 图形客户端 qmon 的编译服务器上完全用命令行管理集群这个选项可以减少依赖。认证方式是在 configure 阶段另一个影响很大的决策。TORQUE 支持 host 认证和 munge 认证两种常见模式host 认证是默认行为原理是直接校验客户端的来源主机名是否在节点清单里内网互信环境下最简单munge 认证会为每个请求签发临时票据需要额外部署 munge 服务并保证所有节点上的 munge key 一致。初次搭建不推荐 munge因为一旦 key 不同步所有节点都认证失败排查起来比编译问题更隐蔽。我逐渐形成的习惯是先 host 认证跑通全流程再考虑要不要换 munge。常见的 configure 组合写法如下./configure --prefix/usr/local/torque \ --with-server-home/var/spool/torque \ --disable-gui--with-server-home 这个参数容易被忽略源码包里既有的默认值。它影响的不只是服务器目录m 节点日志路径、作业 spool 目录、记账文件全都在这个根路径下派生。后续所有日志路径的排查比如 server_logs、mom_logs都是跟着这个根路径走的所以务必在 configure 时定下来不要中途改。3. 从 tar.gz 到三个进程在跑TORQUE 编译安装与最小集群启动3.1 解压、configure、make、make install 的最小命令序列拿到 torque-6.1.1.1.tar.gz 后第一步是解压进入源码树。整个编译安装的最小序列可以写成下面这样按顺序执行即可tar zxvf torque-6.1.1.1.tar.gz cd torque-6.1.1.1 ./configure --prefix/usr/local/torque \ --with-server-home/var/spool/torque \ --disable-gui make -j4 make install这几条命令的逻辑很清楚tar 解压得到源码目录configure 根据第 2 章的参数生成 Makefilemake -j4 用 4 个并行任务编译并行度要根据机器内存调整内存小于 2GB 时建议直接 makemake install 把二进制、脚本、配置文件模板装到 /usr/local/torque 目录下。安装完成后安装目录下的 bin 和 sbin 子目录里有全部管理命令包括 pbs_server、pbs_mom、qsub、qmgr、pbsnodes。编译失败时的信息要分阶段看。configure 阶段失败基本是缺依赖头文件按 2.2 补包make 阶段失败常见的是内存不足导致编译器进程被杀或者 boost 库版本太老。如果是并行编译内存不足改成单线程 make 通常能绕过。安装路径不要放在带空格的目录里TORQUE 的脚本对路径空格处理得并不优雅这个习惯能避免不少莫名其妙的问题。make install 完成后安装目录下会生成一个环境脚本常见做法是把它 source 进当前 shell或者在用户主目录的 .bashrc 里加一行把 bin 和 sbin 目录写进 PATH。不 source 也能用但要写全路径调用命令排查问题时反而容易因为 PATH 顺序跑了系统里另一个版本的客户端产生错觉。3.2 配置 server_priv/nodes 与 /etc/hosts让 server 认识每台节点TORQUE 调度集群之前pbs_server 必须知道有哪些计算节点、每台节点提供多少 CPU 槽位。这个信息写在 server-home 目录下的 server_priv/nodes 文件里。我一般先建目录再写文件mkdir -p /var/spool/torque/server_priv cat /var/spool/torque/server_priv/nodes EOF node01 np8 node02 np8 node03 np4 node_propertyhighmem EOF每行格式是节点名加属性np8 是关键属性表示这台节点向调度器提供 8 个可分配的 CPU 槽位。调度器做资源匹配时依据的就是这个数字而不是操作系统实际核数所以 np 值设错会导致节点长期显示 busy 或过载。node_propertyhighmem 是自定义标签后面作业可以通过 #PBS -l nodes1:highmem 来请求这类节点实现简单分组调度。集群里每个节点的主机名解析是另一个容易翻车的点。pbs_server 和 pbs_mom 之间通信靠主机名互相识别DNS 不健全的内网环境必须把所有节点短名和 IP 写进 /etc/hosts。配置 server_name 文件指向管理节点短名这一步也常被漏掉echo mgmt01 /var/spool/torque/server_nameserver_name 文件的作用是让 qsub、qmgr 这些客户端工具知道去连接哪台机器。如果这个文件没写客户端会默认使用本机主机名在多节点环境里直接连不上服务器。注意文件里写短名不要写完整域名否则后续认证阶段主机名比对会不一致这是节点 down 的一大隐藏原因。3.3 启动 pbs_server、pbs_mom、pbs_sched 并用 qstat 验证节点清单和主机名解析就绪后开始启动三个核心进程。首次启动 pbs_server 需要带上 -t create 参数创建服务器数据库后续启动则不需要。启动顺序固定为 server 先行export PATH/usr/local/torque/bin:/usr/local/torque/sbin:$PATH pbs_server -t create pbs_sched pbs_mom加环境变量的目的是让 qsub、pbsnodes 这些客户端命令在当前 shell 可用。pbs_server -t create 只在 /var/spool/torque 下还没有 server_db 时执行如果数据库文件已存在命令会报错退出不会覆盖旧数据。pbs_sched 启动后没有任何前台输出这是正常现象pbs_mom 同样也是 daemon 方式运行进程列表里能看到才说明真的起来了。启动完成后的验证命令我每次搭完集群都会输入一遍pbsnodes -a输出里每一台节点的 state 列如果是 down说明 mom 还没注册成功如果显示 free 或 job-exclusive说明节点状态正常。刚启动的头几十秒显示 down 不用紧张mom 在和 server 做第一次握手。另一个验证命令是 qstat -q此时队列还没建输出为空属正常第 4 章会创建队列。到这里最小集群的骨架已经立住了。4. 建队列配节点qmgr 九个命令把调度真正跑起来4.1 队列的创建与启停属性queue_type、enabled、started进程都起了但此时还没有队列任何作业都投不进去。TORQUE 里的队列是作业的入口容器。队列分 execution 和 routing 两种类型execution 队列直接运行作业routing 队列只做转发把作业按规则导到其他队列。小型集群通常只建一个 execution 队列就够了。创建和启停队列用的是 qmgr 命令一连串配置可以写成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 qmgr -c set server default_queue batch qmgr -c set server scheduling True这六条命令前四条定义队列本身后两条定义服务器级调度行为。enabled 属性控制队列是否接受新作业提交started 属性控制队列里的作业是否真正开始执行。这两个属性是独立的初学阶段最常踩的坑就是只设了 enabled 忘了 started结果是 qsub 能提交、qstat 能看到作业但作业永远停在 Q 状态不跑。scheduling True 是服务器级的开关如果它被关掉整个调度器都不会分配作业即使队列属性完全正常。配置完成后用 qmgr -c print queue batch 查看队列属性逐项核对 enabled、started、queue_type 三个字段。这套命令的另一个优点是幂等重复执行教材命令不会报错所以很多人会把 qmgr 配置写成 shell 脚本保存下来每次重装集群直接跑一遍这就是后面章节说的后悔药。4.2 资源限制与节点分配参数walltime、ncpus 与 properties队列建好只是开始真正的调度行为由一批 resources 前缀的参数控制。这些参数主要分三类resources_max 是单作业上限resources_default 是作业未声明资源时的兜底值还有一批服务器级参数控制用户维度的限制。我每搭一个新集群都会先把下面这些设一遍qmgr -c set queue batch resources_max.walltime 72:00:00 qmgr -c set queue batch resources_max.ncpus 16 qmgr -c set queue batch resources_default.walltime 01:00:00 qmgr -c set queue batch resources_default.ncpus 1 qmgr -c set server max_user_run 10walltime 的格式是 HH:MM:SSresources_max.walltime 限制单个作业最长运行 72 小时超过这个值的作业在 qsub 阶段就会被拒绝。resources_max.ncpus 限制单作业最多请求核数对防止有人一个作业占光全集群很有用。resources_default 的作用容易被低估用户提交作业时不写 #PBS -l 资源请求调度器就按默认值分配不设默认 walltime 的话可能导致作业被赋予极小或极大的时间片。max_user_run 10 是限制单个用户同时运行的作业数资源不足时后续作业排队等待。节点属性在调度匹配中的作用我在这里单独说明一下。作业脚本里写 #PBS -l nodes2:highmem 时调度器只会从带 highmem 属性的节点里挑选。如果集群里没有这样的节点作业会一直停在 Q 状态而且 qstat -f 里看不到任何报错只能通过对比属性和请求来判断。这个问题的隐蔽性很高适合在出问题章节收藏。常见的关键资源参数汇总如下参数名作用域示例值说明resources_max.walltimequeue72:00:00单作业最长墙钟时间resources_max.ncpusqueue16单作业最大核数resources_default.walltimequeue01:00:00未声明时的默认时长max_user_runserver10单用户并行业务数schedulingserverTrue调度器总开关default_queueserverbatch未指定队列时的去向4.3 提交第一个作业并用 qstat 验证调度结果队列和资源参数就绪可以提交第一个作业做端到端验证。TORQUE 的作业是一个脚本文件头部用 #PBS 前缀写资源请求后面的内容是实际要执行的命令。常见的最小作业脚本#!/bin/bash #PBS -N firstjob #PBS -q batch #PBS -l nodes1:ppn2,walltime00:30:00 sleep 60 echo job done脚本前三行是作业声明#PBS -N 给作业起名#PBS -q 指定队列#PBS -l 指定资源请求nodes1:ppn2 表示要 1 个节点、每个节点 2 个 CPU 槽位walltime 指定运行时长上限。提交和验证的命令组合如下qsub -V firstjob.pbs qstat -a qstat -f job_id-V 参数会把当前 shell 的环境变量带进作业进程便于作业脚本访问用户在终端里导出的路径配置qstat -a 以简表形式列出所有作业状态列 Q 表示排队、R 表示运行、E 表示结束qstat -f 查看作业完整属性重点关注 state 字段和 exec_host 字段后者能看到作业实际被分配到哪个节点。作业运行结束时标准输出会写到作业目录下的 firstjob.ojob_id 文件标准错误写到 firstjob.ejob_id。如果作业秒跑完且输出为空先检查这两个文件。从提交到 R 状态通常只需要几秒。如果作业停在 Q 状态就去对照 2.2 节提到的那几个属性queue started 是否为 True、scheduling 是否为 True、资源请求是否超过队列上限、是否有节点带对应属性。把这一条链路追下来TORQUE 的基本调度模型就通透了。5. TORQUE 6 避坑五个常见的调度器翻车现场5.1 节点一直 down作业永远排队这个现象排在第一位因为它最打击新人信心。表象是 pbsnodes -a 显示节点 state 为 down作业提交后永远停在 Q 状态qstat 里看不到任何调度动作。原因排查按三句话来主机名解析、认证匹配、mom 日志。先把 /etc/hosts 打开看所有节点短名是否和实际主机名一致。server_name 文件里的名字也必须和 pbs_server 所在机器的主机名完全一致不能写别名。如果 hosts 和 server_name 都没问题下一站是 mom 日志路径位于 server-home 目录下的 mom_priv/mom_logs按日期命名的文件里搜索 error 或 cannot connect 关键字。常见做法是grep -i cannot connect\|error /var/spool/torque/mom_priv/mom_logs/$(date %Y%m%d) | tail -20如果是认证失败日志里会明确提示主机名不匹配。解决方法是统一所有节点的主机短名并在 server 端重新读取节点列表。如果节点状态只是脏标记可以用 pbsnodes -c 清理这个操作会重置节点的错误状态但前提是 mom 本身运行正常。清理完再 pbsnodes -a 确认 state 是否回到 free。5.2 作业卡在 Q 或 H 状态不进入 R现象是作业提交成功qstat 里能看到但几十个小时过去了状态还是 Q。这类问题有一个分水岭必须搞清 Q 和 H 的区别。Q 是排队等待调度H 是被人为挂起两种状态的处置方式完全不同。Q 状态的根源按优先级排查队列 started 属性是否为 False、服务器 scheduling 是否为 False、作业请求的资源是否超过队列上限、请求的节点属性是否存在。这四个原因里前两个是配置检查项用 qmgr -c print queue batch 和 qmgr -c print server 一眼能看出后两个要求对比作业脚本里的 #PBS -l 和队列资源上限以及 pbsnodes -a 里的节点属性。注释里 qstat -f job_id 的 comment 字段有时会给出原因但很多时候它不写需要人工核对。H 状态则是另一个故事。常见的触发原因是作业墙钟时间请求了半天、队列资源上限只有 1 小时这类作业在 qsub 阶段就被拒收了还有一种是用户主动 qhold 挂起。处置方式是找作业持有者确认跑 qrls job_id 释放挂起状态。注意释放挂起前先确认资源是否满足否则释放后还是会回到 Q。这块的经验是遇到卡住的作业先 qstat -f 看状态字母和注释字段再对照队列配置做判断不要直接重启服务重启只能让问题更难定位。5.3 qsub 报 cannot connect to server现象是任何客户端命令包括 qstat、qsub、qmgr都报无法连接服务器。这个错误的迷惑之处在于服务器看起来一切正常进程在跑、端口在监听但客户端就是连不上。原因排查顺序也有讲究。第一是 client 端的环境变量和 PATH 是否指向正确的安装目录如果机器上曾经装过其他版本PATH 顺序会导致跑错二进制报错信息还往往完全一样。第二是 server_name 文件是否存在、是否写了正确的服务器短名这个文件位置在 /var/spool/torque/server_name。第三才是检查 pbs_server 是否真的在运行看完后用 ps aux | grep pbs_server 确认。注意排查时带上完整路径调用命令比如 /usr/local/torque/bin/qstat避免 PATH 干扰。解决路径也很直接echo mgmt01 /var/spool/torque/server_name 重新写 server_name再 source 一下环境脚本把 PATH 理顺。如果是为了排查而临时手动起了 pbs_server记得当前 shell 里 export PBS_SERVER 环境变量的值要保持一致这个变量优先级高于 server_name 文件两者冲突会蛮奇怪地连不上。5.4 时钟不同步让节点记录错乱这是一个隐蔽问题。现象是节点明明没有作业在跑pbsnodes -a 却显示 busy作业明明运行了 10 分钟记账文件里却是 0 秒。排查到最后才发现管理节点和计算节点的系统时钟存在几十秒偏差。TORQUE 各组件之间通过心跳和数据包的时间戳来维护状态时钟偏差一旦超过阈值server 会认为 mom 的下发作业执行状态过期产生资源占用还没有被回收的假象。另一个连带伤害是作业的 walltime 计算错乱可能让调度器认为作业超时触发强制终止。解决方法是让全集群走同一时间源常见做法是配置 chrony 或 NTP 服务管理节点向外部时间源同步计算节点向管理节点同步并确认 timedatectl 状态里 NTP 为 active。临时没时间搭时间同步的话先用 date 命令手动校准各节点再重启 pbs_server 让状态重新收敛。注意顺序先校时、再重启顺序搞反了重启后还是一样乱。这块也算调度器搭建里最接近玄学的部分时钟问题一旦排除很多怪象自然消失。5.5 重装和重启后的两个后悔药救场操作现象一pbs_server -t create 时报数据库已存在无法创建现象二机器重启后pbs_mom 注册不上节点一直 down。这两个现象在重装集群和断电恢复时频繁出现本质都是对 TORQUE 状态文件生命周期理解不深。第一个问题的出路是认清 server_db 目录的性质。pbs_server -t create 只在数据库从未初始化时才能执行一旦已存在重复执行只会报错。如果确认集群不需要保留旧作业记录可以先把 server_priv 目录整体备份再清理 server_db 后重建如果还想保留历史作业信息不能用 -t create而是要正常启动 pbs_server。第二个问题的出路是认清启动顺序重启后 pbs_server 需要时间恢复数据库pbs_mom 在这期间疯狂重试表面上看起来像卡死给足两分钟一般能自动连上。如果两分钟还不行手动重启一次 mom再观察 pbsnodes -a。把 qmgr 配置写成脚本保存下来的习惯我在 4.1 节提过一次这里再强调一遍这个脚本就是重装后的后悔药重建集群时跑一遍脚本队列和资源参数全部恢复不用再手工敲几十条 qmgr 命令。我现在的习惯是配置脚本入库谁改过队列规则一目了然。希望这一节的五个场景能帮你少走一半弯路。6. 让调度结果可验证作业数组与日志排查技巧集群跑通后日常干活的基本操作是批量提交相似任务。TORQUE 对这类场景有原生支持作业数组。提交格式不复杂在作业脚本里加一行 #PBS -t 0-9一次提交就生成 10 个独立作业每个作业里的 $PBS_ARRAYID 变量用于区分序号#!/bin/bash #PBS -N arrayjob #PBS -q batch #PBS -t 0-9 #PBS -l nodes1:ppn1,walltime00:10:00 echo task $PBS_ARRAYID start sleep 10 echo task $PBS_ARRAYID end验证这批作业是否全部按预期跑完除了 qstat -a 看总数更可靠的方式是 qstat -f job_id 看单个作业的 resources_used.walltime 和 exit_status 字段。作业数组的另一个价值是单任务失败不影响其他任务排查效率比写一个串行 for 循环高得多。我会在提醒习惯里同步一条遇到结论异常的作业状态先翻日志再动手。server 日志在 /var/spool/torque/server_logs/ 下按日期存放快速过滤常见错误的命令grep -i error\|denied\|cannot /var/spool/torque/server_logs/$(date %Y%m%d) | tail -50日志排查的意义在于调度器会把很多无法通过 qstat 表面字段看出的原因写在日志里包括认证失败、节点通信异常、调度器内部错误。我自己的习惯是第一次搭集群时把所有配置命令存成 shell 脚本入库之后线上行为异常绝不凭感觉重启服务而是先看 server_logs 和 mom_logs再决定是清理节点状态还是调整队列属性。这套验证和排查的组合拳让我在后续维护中没有再被调度状态反复折腾过。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
