SWB 第 11 章：调度器

来源：swb_ug.pdf 第 11 章（W-2024.09）
说明：本章按 2024 版原章结构重写，重点整理 SWB 支持的调度器、队列配置文件、工具与队列关联，以及集群环境中的常见使用与排障要点。

本章目录

调度系统概览
支持的调度器
LSF 调度器
SGE 调度器
TM 调度器
Altair Accelerator 调度器
配置调度系统
全局队列配置文件
Local 队列
LSF 队列
SGE 队列
TM 队列
Altair Accelerator 队列
站点级队列配置
用户级与项目级队列配置
工具关联与节点级约束
扩展调度日志
在集群上以交互作业方式启动 SWB

本章讨论 Sentaurus Workbench 如何接入不同的后端调度系统。对使用者来说，SWB 暴露的是统一的队列与工具关联接口；对管理员来说，真正的关键是把 gqueues.dat、工具数据库（tool database）、站点环境变量和集群本身的命令链路配置正确。

调度系统概览

多参数参数扫描和 DoE 项目通常会产生大量相互独立或弱依赖的仿真任务，因此非常适合运行在工作站网络或集群环境里。SWB 的目标不是自己实现一个调度系统，而是在本地执行与外部调度器之间提供统一入口。

强调了两个现实点：

分布式调度系统的安装和初始化通常很复杂，对网络环境要求高。
分布式系统的排障难度明显高于普通单机应用。

从 SWB 的视角看，用户只需要把节点提交到“队列”。这些队列可以定义在：

全局队列配置文件
站点队列配置文件
用户队列配置文件
项目队列配置文件

每个节点最终都可以被分配到这些文件中定义的任一队列。

支持的调度器

W-2024.09 中列出的后端执行引擎包括：

LSF
Oracle / Univa Grid Engine (SGE)
TORQUE Resource Manager (TM)
Altair Accelerator
Local

其中 Local 不需要专门的调度环境，按顺序在本机执行任务，适合短任务、调试或前期搭建流程。
而 LSF、SGE、TM、Altair Accelerator 都依赖一个共享文件命名空间，因此必须满足几条共通前提：

所有参与主机都能访问 Synopsys TCAD 安装，且 STROOT 绝对路径一致。
用户项目空间对所有主机可见，且 STDB 路径一致。
管理员已经准备好全局 queue 定义文件，必要时还有 site queue 文件。

LSF 调度器

SWB 通过 bsub、bjobs、bkill 与 LSF 交互：

bsub：提交作业
bjobs：查询状态
bkill：终止作业

要让 LSF 能工作，至少需要满足：

启动 SWB 和 gsub 的主机本身是 LSF client 或 server。
本地 PATH 中可以找到 LSF 可执行文件，也就是通常要把 $LSF/bin 加进来。
所有 LSF server 主机都能访问 Synopsys TCAD。
项目目录对所有 LSF server 都以相同绝对路径可见。

手册建议用下面两个命令做基本自检：

bash

lsid
bqueues

SWB 提交到 LSF 时，真正执行节点的不是直接的工具命令，而是 gjob 这个包装程序（wrapper）。gjob 负责更新作业状态，并在本地执行工具数据库中定义的 prologue / epilogue。

手册还补充了一层实现细节：究竟调用哪个 bsub、bjobs、lsid，也由工具数据库控制，对应键是：

tcl

WB_binaries(tool,bsub)
WB_binaries(tool,bjobs)
WB_binaries(tool,lsid)

如果企业环境里对这些命令做了包装脚本或二次封装，通常就是通过这组键接入。

LSF 的项目名与作业名选项

说明，LSF 默认通过 -P 绑定 LSF project name；也可以切换成 -J，让提交结果更偏向 job name 维度。

切换方式是：

打开 Edit > Preferences
展开 Scheduler > LSF Jobs
将 Project Name Command-Line Option 设为 -J
点击 Apply

如果你的 LSF 运维或排障习惯更依赖 job name，而不是 project name，这个切换会更顺手。

LSF 的资源字符串

可以在工具数据库里给特定工具定义 LSF 资源要求：

tcl

set WB_tool(<tool_name>,LSF,resource) {<resource_string>}

例如：

tcl

set WB_tool(sprocess,LSF,resource) {rusage[sprocess_all=1,sprocess3d_all=1]}
set WB_tool(sdevice,LSF,resource) {mem>5000 rusage[sdevice_all=1]}

特别说明：

不要自己写 -R
SWB 会自动补上 -R
工具数据库里的资源字符串会覆盖队列配置文件中对应队列的资源字符串

LSF 常见问题

LSF 部分给了两个典型问题：

节点已经提交但迟迟不执行
常见于忙碌或较慢的 LSF 集群。原因是 SWB 第一次调用 bjobs 时，LSF 还没完成真正提交。
可调的两个地方是：
- WB_tool(bjobs,delay)：首次查询前的延迟，单位秒，默认 15 s
- Scheduler > LSF Jobs > Job Polling Interval (sec)：两次 bjobs 之间的轮询间隔
节点不执行，日志里抱怨 bjobs 输出格式不对
这通常是因为被调用的不是标准 bjobs，或者输出被别的脚本包装过。
解决方式是自定义解析函数：

tcl

proc ::glsf::ParseBjobsOutput { text } {
  ...
}

这个函数需要返回 {jobID status execution_host} 三元组列表。支持的状态包括：

DONE
EXIT
PEND
RUN
PSUSP
USUSP
SSUSP

SGE 调度器

SWB 把 SGE 作为 LSF 之外的另一条主要企业级队列链路。它通过：

qsub：提交作业
qstat：查询状态
gdel：终止作业

使用前的前提条件与 LSF 类似：

SGE 环境脚本或环境变量配置正确，特别是 PATH 中能找到 SGE binaries。
本地主机是 SGE submit/admin host。
所有 SGE hosts 能访问 Synopsys TCAD。
项目空间对所有 SGE hosts 具有相同绝对路径。

推荐的自检命令是：

bash

qconf -sconf global

如果当前主机不具备 submit/admin 权限，典型报错会类似：

text

denied: host "myhostname" is neither submit nor admin host

SGE 资源描述

SGE 的工具级资源描述写法是：

tcl

set WB_tool(<tool_name>,SGE,resource) {<resource_description>}

例如：

tcl

set WB_tool(sprocess,SGE,resource) {arch=glinux,kernel_version=2.6.9,num_proc=4,mem_inst=2G}
set WB_tool(tsuprem4,SGE,resource) {arch=glinux,kernel_version=2.4.21}

同样强调：

不要自己写 -l
SWB 会自动加 -l
工具数据库里的资源描述会覆盖队列配置文件中对应 SGE queue 的全局设置

在真正写入队列配置文件或工具数据库之前，手册建议先用下面这些命令确认资源描述是否有效：

bash

qhost -l <resource_descriptor>
qhost
qaccess
qconf -sc
qconf -se <SGE_hostname>

SGE 常见问题

SGE 部分的典型问题是 qstat 查询过于频繁。解决方式比较直接：

调大 Scheduler > SGE Jobs > Job Polling Interval (sec)

默认值是 1 s，对繁忙集群来说可能过于激进。

TM 调度器

TM 指的是 TORQUE Resource Manager。它同样通过 PBS 风格命令工作，SWB 使用：

qsub：提交
qstat：查询
qdel：终止

使用前需要满足：

TM 环境配置正确，相关 binaries 在 PATH 中。
本地主机是 TM submit/admin host。
所有 TM hosts 可访问 Synopsys TCAD。
项目空间在所有 TM hosts 上路径一致。

建议用下面命令做基本连通性测试：

bash

qstat -u non_existing_user

TM 的工具级资源设置写法与 SGE 很像：

tcl

set WB_tool(<tool_name>,TM,resource) {<resource_description>}

同样不应该自己写 -l，因为 SWB 会自动添加。工具数据库中的描述会覆盖队列配置文件中 TM queue 的资源描述。

TM 常见问题

和 SGE 一样，TM 主要问题也是 qstat 查询太频繁。可以通过：

Scheduler > TM Jobs > Job Polling Interval (sec)

来降低轮询频率。

Altair Accelerator 调度器

SWB 对 Altair Accelerator 的接口使用的是 nc 命令族：

nc run：提交作业
nc list：查询状态
nc stop：终止作业
nc forget：清理已完成作业，避免继续出现在状态列表里

使用条件与前面几类集群调度器基本一致：

Altair Accelerator 环境配置正确，相关 binaries 在 PATH 中。
本地主机是 submit/admin host。
所有 Altair Accelerator hosts 可以访问 Synopsys TCAD。
项目目录在所有节点路径一致。

推荐的基本检测命令是：

bash

vovarch

Altair 的资源描述

Altair 的工具级资源设置写法略有不同：

tcl

set WB_tool(<tool_name>,RTDA,resource) {<resource_description>}

例如：

tcl

set WB_tool(sprocess,RTDA,resource) {-r+ CPUS/4 -r- linux64 -r+ RAM/500}

和 LSF/SGE/TM 不同，Altair 的工具数据库资源描述不会覆盖队列配置文件中的描述，而是追加到队列定义中的资源串后面。

Altair 常见问题

典型问题仍然是状态轮询太密。对应参数是：

Scheduler > Altair Accelerator Jobs > Job Polling Interval (sec)

用于调节两次 nc list 之间的间隔。

配置调度系统

除了集群本身安装正确外，SWB 还需要 queue configuration file，也就是 gqueues.dat。这份文件通常由管理员在全局或站点级提供，用户和项目级可以继续追加自己的队列和关联。

从逻辑看，配置调度系统实际上分成两块：

定义有哪些 queue 可供选择
定义 tool 默认应该走哪个 queue

全局队列配置文件

gqueues.dat 是 SWB 的统一队列描述文件。它把所有可访问资源都组织成 SWB 可识别的 queue 定义。基本格式是：

text

queue <scheduler>:<queue_name> "<options>"

手册中的示例覆盖了所有主要后端：

text

#local queues
queue local:default "19"
queue local:priority "10"

#lsf queues
queue lsf:normal "bsub"
queue lsf:mylsfqueue "bsub -R \"swp > 5 && mem > 10\" -q normal"

#sge queues
queue sge:normal "qsub"
queue sge:normal64 "qsub -V -cwd -now n -P bnormal -l arch=glinux"

#tm queues
queue tm:normal "qsub"
queue tm:mt4 "qsub -l nodes=1:ppn=4"

#Altair Accelerator queues
queue rtda:normal "nc run -C swb"

SWB 查找全局队列配置文件的顺序是：

$STROOT/queues/gqueues.dat
$STROOT/tcad/$STRELEASE/lib/gqueues.dat
$STROOT/tcad/$STRELEASE/lib/glib2/gqueues.dat

最低要求是：文件里至少要有一个 local 队列，否则无法本地运行 SWB 作业。

此外，手册特别提到，除了 GUI 之外，gsub 和 genopt 这类命令行工具也会读取同一套 queue 定义，所以 gqueues.dat 实际上是整套 SWB 调度入口的公共配置。

Local 队列

Local queue 的格式最简单：

text

queue local:<queue_name> "<nice_level>"

例如：

text

queue local:priority "10"

手册给出的默认本地队列是：

text

queue local:default "19"
queue local:priority "0"

一个非常容易忽略的点是：某个项目一旦开始运行，它的“local machine”就固定为启动该项目执行的那台机器。即使你随后在另一台机器上打开同一项目并继续运行“本地队列”，新节点仍会提交到最初那台机器上。

LSF 队列

LSF queue 的格式是：

text

queue lsf:<lsf_queue_name> "bsub <constraint_options>"

例如：

text

queue lsf:mylsfqueue "bsub -R \"linux && mem>1000\""

特别提醒，LSF 的资源字符串里双引号需要用反斜杠转义，否则 Tcl 展开后会丢失引号，导致 bsub 语法错误。

SWB 还允许 queue alias，也就是多个 SWB 队列名最终都映射到同一个真实 LSF queue，只是资源约束不同。

举的 queue alias 场景很实用：多个 lsf:refqueue* 可以都指向同一个真实 LSF queue，例如 normal，只是每个 alias 附带不同资源约束。这样管理员不需要在 LSF 侧新增真实 queue，也能在 SWB 里暴露多种“逻辑入口”。

如果使用 lsf:default 作为 SWB 队列名，还要求你在约束串里显式写出真实的 LSF queue，例如：

text

queue lsf:default "bsub -R \"linux && mem>1000\" -q mylsfqueue"

SGE 队列

SGE queue 的格式是：

text

queue sge:<sge_queue_name> "qsub <arguments>"

最核心的参数通常是 -P，它指定所属 SGE project，也就间接决定了可用的主机组。示例：

text

queue sge:mylsfqueue "qsub -P bnormal -l arch=glinux,kernel_version=2.6.9"

SWB 会把真正的 gjob 调用包进一个 shell 脚本，再交给 qsub 提交。

给出的完整提交流程也说明了一点：SGE queue 定义只是最终 qsub 命令的一部分。SWB 会在其上补齐日志路径、错误文件、项目名和封装后的 shell script。

TM 队列

TM queue 的语法与 SGE 十分相似：

text

queue tm:<queue_name> "qsub <arguments>"

虽然语法形式像，但 qsub 的具体参数语义仍以 TORQUE 文档为准，不能直接照搬 SGE。

Altair Accelerator 队列

Altair queue 的格式是：

text

queue rtda:<queue_name> "nc run <options>"

例如：

text

queue rtda:mt4 "nc run -C swb -r+ CPUS/4 -r+ RAM/500 -r+ linux64"

SWB 最终会在这个定义基础上补充日志文件、作业名和运行目录等参数。

站点级队列配置

如果同一家公司不同站点的资源环境不同，可以准备站点级 gqueues.dat：

把站点专用配置写进 gqueues.dat
存到任意目录
设置环境变量：

bash

setenv SWB_SITE_SETTINGS_DIR <path_to_site_directory>

和站点工具数据库不同，站点队列配置文件会完整替换全局队列配置文件，而不是简单叠加。

这意味着一旦启用了站点级 gqueues.dat，就不能再默认依赖全局队列配置文件里的定义还在。站点文件需要自己包含你仍然想暴露给用户的所有队列。

用户级与项目级队列配置

用户和项目都可以再增加自己的 queue 定义。它们会附加到 global/site 队列之上，一起出现在 Run 对话框里。

但有一个限制：SWB 不允许在低层级重新定义高层级已经存在的 queue 名称。同名时，低层级定义会被忽略。

所以更合理的做法通常是：

global / site 级负责定义 queue 本身
user / project 级主要负责选择和覆写 tool-to-queue association

工具关联与节点级约束

除了 queue 本身，SWB 还需要知道“哪个工具默认走哪个 queue”。格式如下：

text

tool <tool_name> "options" <scheduler:queue_name>

例如：

text

tool sprocess "" lsf:normal
tool default "" sge:mt4

这里的 default 可以表示所有工具的默认关联。

手册还列出了 SWB 自带的默认 global tool associations：

text

tool inspect "" local:default
tool svisual "" local:default
tool bridge "" local:default
tool default "" local:default

这意味着像 Inspect、Sentaurus Visual 这类偏交互式工具，默认会被拉回本地执行，而不是跟随远程集群 queue。

user / project tool association 的存储位置

user 级：$STDB/gqueues_<username>.dat
project 级：项目目录下的 gqueues.dat

还补充了 options 字段的语义：

对 local scheduler，options 表示 nice level
对其他 schedulers，options 表示资源字符串或资源描述的重定义

工具关联支持四个层级：

global
user
project
node

其中 node 级约束在运行时按表达式展开，格式为：

text

node "gexpr" <queue:name> "options"

例如：

text

node "all:{ @P1@ > 2.0 }" local:default "11"

这意味着所有满足表达式条件的节点都会按 node 级约束重新指定队列和选项。

还强调了覆盖顺序：

global/site 先加载
然后 user 覆盖
最后 project 再覆盖

所以真正生效的是最近一层的设置。

更准确地说，是“后加载的同类定义覆盖前面层级的定义”，因此 project 级通常拥有最后解释权。

扩展调度日志

如果要调试调度相关问题，可以开启扩展日志：

text

GSUB_ADVANCED_LOG 1

开启后，SWB 会把更多调度信息写入：

项目日志 glog.txt
节点作业文件 n<nkey>_<acr>.job

默认是关闭状态。手册提醒，这个功能会显著增加日志量，应谨慎使用。

如果你正在排查以下问题，这个日志通常很有价值：

节点提交后没有真正进入队列
状态轮询和集群真实状态不一致
node-specific constraints 看起来没有生效
项目在 scheduler 上结束了，但 SWB 没及时识别

在集群上以交互作业方式启动 SWB

很多公司会把图形界面应用也跑在集群的 interactive job 上。手册给出两个例子：

bash

# LSF
bsub -q <iqueue> -I xterm

# SGE
qsh -cwd -P <iproject>

这里需要保证 DISPLAY 配置正确，或者在命令行里显式指定 X display。

特别强调，SWB 本身虽然是串行进程，但它背后还会拉起一批后台进程，同样会占用这份交互式槽位（interactive slot）的 CPU：

swblm
gsub
gjob + 实际仿真进程

对这些后台进程还有更细的说明：

swblm 是同一用户下所有 SWB 进程之间通信的守护进程。通常资源消耗很小，但在大型 DoE 且仿真速度很快的场景里，最多可能并行到 20 个线程。
gsub 每运行一个项目就会对应一个 gsub。它虽然是串行进程，但在大 DoE 项目中也可能占据显著 CPU 时间。
gjob + simulation 如果 Inspect 或 Sentaurus Visual 仍默认本地执行，那么它们和对应的 gjob 也会占用同一个交互式槽位的 CPU 资源。

调度问题的快速排查顺序

如果节点迟迟不运行，按下面顺序排查通常最快：

先确认 Scheduler 标签页里节点究竟处于 submitted、pending 还是 running。
再检查项目日志 glog.txt 与节点作业文件 n<nkey>_<acr>.job，确认提交命令是否真的发出。
用对应调度器原生命令复核状态，例如 LSF 用 bjobs，SGE/TM 用 qstat，Altair 用 nc hosts / nc cmd qstat。
最后再回头核对 gqueues.dat、工具数据库和工具关联，确认节点是否被送进了错误队列，或被节点级约束重新改写。

这套顺序的好处是：先区分“SWB 没提交”“调度器没接单”“队列策略不匹配”三类问题，再决定应该看 GUI、日志还是集群配置。

在大 DoE 项目中，swblm 最多可能并行使用到 20 个线程，而 gsub 与 gjob 在预处理和调度阶段也可能消耗明显 CPU。因此，如果你在集群上跑交互式 SWB，默认只分配 1 个 CPU core 往往不够。

手册建议，如果遇到性能问题：

先和 IT 确认 interactive job 默认分到多少 CPU 资源。
尝试显式申请更多 CPU。

例如：

bash

# LSF
bsub -q <iqueue> -R "span[hosts=1]" -n 4 -I xterm

# SGE
qsh -cwd -P <iproject> -pe mt 4

如果只是开几个中小项目，1 个核心通常够用；但如果在同一个 SWB 实例里同时跑多个大 DoE 项目，就应当适当增加核心数。

Sentaurus™ Workbench User Guide W-2024.09 第 11 章

SWB 第 11 章：调度器 ​

调度系统概览 ​

支持的调度器 ​

LSF 调度器 ​

LSF 的项目名与作业名选项 ​

LSF 的资源字符串 ​

LSF 常见问题 ​

SGE 调度器 ​

SGE 资源描述 ​

SGE 常见问题 ​

TM 调度器 ​

TM 常见问题 ​

Altair Accelerator 调度器 ​

Altair 的资源描述 ​

Altair 常见问题 ​

配置调度系统 ​

全局队列配置文件 ​

Local 队列 ​

LSF 队列 ​

SGE 队列 ​

TM 队列 ​

Altair Accelerator 队列 ​

站点级队列配置 ​

用户级与项目级队列配置 ​

工具关联与节点级约束 ​

user / project tool association 的存储位置 ​

扩展调度日志 ​

在集群上以交互作业方式启动 SWB ​

调度问题的快速排查顺序 ​

SWB 第 11 章：调度器

调度系统概览

支持的调度器

LSF 调度器

LSF 的项目名与作业名选项

LSF 的资源字符串

LSF 常见问题

SGE 调度器

SGE 资源描述

SGE 常见问题

TM 调度器

TM 常见问题

Altair Accelerator 调度器

Altair 的资源描述

Altair 常见问题

配置调度系统

全局队列配置文件

Local 队列

LSF 队列

SGE 队列

TM 队列

Altair Accelerator 队列

站点级队列配置

用户级与项目级队列配置

工具关联与节点级约束

user / project tool association 的存储位置

扩展调度日志

在集群上以交互作业方式启动 SWB

调度问题的快速排查顺序