极客工场

Appearance

共 2,556 字预计阅读约 9 分钟

Calibre 运行卡死/超时：DRC/LVS/PEX 挂住不跑完速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre 最磨人的故障不是直接报错，而是「不退出也不出结果」：calibre -drc 挂在那里几小时，transcript 停在某一行，作业到底在算、在等 license、还是在等你键盘上的一个回车？本篇分诊运行期卡死与跑批超时；启动期签不到 license 会直接报错退出，那类问题见 Calibre license checkout failed 排错速查，综合侧的同款分诊思路可对照 Design Compiler 卡死超时速查，流程背景见 Calibre 物理验证实操，排错总入口见 开源 EDA 报错排错中心。

本文要回答的问题 ​

  • calibre 进程挂了几小时，怎么先分清是真死、排队，还是正常地慢？
  • transcript 停在 license queued、停在某条规则、停在 PEX 阶段，各意味着什么？
  • 后台作业没有 tty，为什么会自己挂住等输入？
  • LSF 里作业跑着跑着消失，除了崩溃还有哪几种被杀法？
  • 大版图跑得奇慢，怎么确认是内存颠簸还是 NFS 慢盘？

一、现象与真实输出 ​

Calibre 卡死时现场通常只剩四样东西：进程状态、transcript 尾行、调度系统记录、系统调用现场。以下为典型形态，作业名与主机均已占位。

1. 看似 hang，实际在 license 队列里安静排队：

text
MGLS: All licenses for "CALIBRE-PEX" are currently in use.
Your request has been queued.  Queue position: 2

进程不退出、不报 fatal、CPU 为 0，只在席位空出后才继续。这类「卡死」在 PEX 高峰最常见，且 Calibre 可能运行到 PEX 阶段才签出对应特性，启动时一切正常。

2. 后台作业挂在一次交互提问上：

text
// Information: The output directory <run>/drc_results already exists.
// Overwrite existing results?  (y/n)

命令行直接跑、或经 LSF/nohup 提交却没有重定向标准输入时，runset 里的提问会永远等下去。ps 看进程在睡，wchan 停在等输入上：

bash
ps -o pid,stat,%cpu,rss,wchan:24,cmd -p <pid>
#  12345 Ss  0.0 128400 n_tty_read_ ...   calibre -drc -hier rule.svrf

3. 跑批被杀，LSF 只留一封邮件：

text
TERM_OWNER: job <456789> has been killed by LSF:
job has exceeded its defined RUNLIMIT (4:00 hour(s)).

作业不是自己卡死，而是撞到队列的运行时长墙。同类杀法还有内存超限（MEMLIMIT）和抢占（preempt），区分点全在 bhist -l <jobid> 的事件记录里。

二、现象 → 区分点 → 处置速查表 ​

现象区分点 / 最常见原因处置
CPU 0%，transcript 停在 queued 行license 队列等待；lmstat -a 看席位全 issued排队、错峰，或找管理员回收僵尸席位
CPU 0%，wchan 为 n_tty_read / pipe_wait交互提示等输入；后台作业无 tty所有输入显式 </dev/null，runset 关掉提问或加自动应答
CPU 0%，wchan 为 pipe_wait管道下游（tee/grep/分页程序）退出或不读去掉多余管道，或 stdbuf/拆成重定向到文件
CPU 低、load 高、RES 逼近物理内存大版图层次展开导致 swap 颠簸降并发、加内存，或加大 flat/hier 切分粒度重跑
CPU 0%、进程 STAT 为 D，停在 read结果库/GDS 在 NFS 上，存储抖动数据与写盘目录挪本地盘，NFS 只做归档
CPU 100% 单核、日志零新增SVRF 宏递归/正则退化等规则侧死循环二分注释规则文件，定位宏后改写法
跑批固定时长被杀LSF RUNLIMIT/MEMLIMIT 或被抢占bhist -l 看死因，申请更长限额或拆段提交
-turbo 多线程反而更慢线程数超过许可席位或核数，互相排队-turbo N 与 feature 席位、机器核数对齐

三、排查决策树 ​

分诊只问一个问题：CPU 到底在不在跑？ 答案替你把现场切成「在等待」和「在计算」两条通道。

eda/ts-calibre-timeout-hang.md D2 示意图

读这张图抓住一条分叉：CPU 0% 走「等待通道」，嫌疑只有三个——license、输入/管道、IO/内存；CPU 高位走「计算通道」，问题要么是正常长跑，要么是规则文件陷入病态循环。 红色是入口现象，蓝色是排查动作，绿色分支表示它其实在干活，橙色是命中根因后的修复，紫色收敛节点负责把「盯人观察」变成「超时与分段」的工程动作。不要一上来就杀作业重排——那会把排队两小时即将拿到席位的作业和真死循环一视同仁地扔掉。

四、逐条排查展开 ​

license 排队和真 hang 的分叉：transcript 尾行 + lmstat 两边对。 尾行停在 queued 且 lmstat -a -c <port>@<license_server> 里该特性 issued 等于 total，就是排队，不是故障；席位里若有 kill -9 残留的僵尸会话，找管理员 lmremove 回收。尾行没有任何 queued 字样、进程却 0% CPU，才进入下一层排查。license 链路细节（端口、mgcld、错误码）见 Calibre license checkout failed 排错速查。

strace 直接报出等待点。 不用猜它在等什么：

bash
strace -p <pid> 2>&1 | head -20

停在 read/openat 且路径在 NFS 挂载点下，是 IO 等；停在 futex/poll 多是 license 心跳或内部锁；停在 read(fd=0) 就是等标准输入。配合 ps 的 STAT 列：D 是内核态 IO 死等（查存储），S 是可中断睡眠（多半等 license 或输入）。

交互提示是后台作业的隐形杀手。 人在终端前跑时按一个 y 就过去的提问，在 LSF/nohup 环境里没人应答，作业能挂一整夜。纪律很简单：提交命令一律 calibre -drc rule.svrf </dev/null >run.log 2>&1，需要覆盖旧结果时在 runset 里预先写好自动确认，不把任何需要键盘的环节留给跑批。管道同理：下游接 tee/grep 时若下游异常退出，上游写满管道缓冲区后会睡在 pipe_wait，跑批优先用重定向落盘，少串管道。

慢到像死：内存颠簸与 NFS 各有体征。 swap 颠簸时 top 里 RES 贴着物理内存、系统 load 很高但 calibre 自身 CPU 不高、整机发卡；大版图 hierarchical 展开临时撑爆内存是典型诱因，处置是降同机并发、换大内存机器，或调整层次切分让单次展开规模变小。NFS 慢盘则表现为 STAT D、strace 停在 read，把 GDS、规则 include 文件和输出结果库放到计算节点本地盘即可立判——挪过去就快，石锤是存储问题。

CPU 100% 但零推进，查规则文件本身。 SVRF 宏写成递归（宏展开里又引用自己）、或灾难性回溯的文本匹配，会让 calibre 单核跑满且 transcript 长时间没有新规则行。用二分法注释规则文件、按区域分块跑版图，把问题面缩到某条宏或某块图形；这类问题复制性极强，缩到最小 deck 后留作回归用例。

作业在 LSF 里消失，先翻尸检记录再重排。 bhist -l <jobid> 的事件行写得很直白：撞 RUNLIMIT 是被运行时长墙杀掉，撞 MEMLIMIT 是内存超限，被抢占则是队列优先级让位。三种死法的重跑姿势不同——超时类申请更长限额或把 DRC 按 layer/区域拆成多段提交，内存类只能降规格或换大内存队列，盲目原命令重排只会在同一堵墙上再死一次。

把「卡死」改造成「带现场的超时失败」。 交互式排查靠人盯，跑批必须自动收口：作业外套 timeout（如 timeout 6h calibre -drc ...），LSF 队列设合理 RUNLIMIT 并在脚本内分段打时间戳日志，哪一段超时一看尾行即知。多线程与 -turbo N 还要对齐两件事：机器物理核数和本单位 feature 的多线程席位约定，线程开得比席位多，calibre 会在内部排队，表现为「开了 turbo 反而更慢」。

五、预防与纪律 ​

  • 跑批输入输出全部显式化：</dev/null 加日志重定向是提交模板的固定部分，提问一律在 runset 内预先回答。
  • 数据近节点：GDS、include 规则、结果库放本地盘，NFS 只做提交归档，不把跑批性能押在网络存储上。
  • 内存预算先于提交：按版图规模估层次展开峰值，同机并发留出余量，撞过 swap 的 deck 记录在案。
  • 超时与分段日志成对出现：timeout/RUNLIMIT 兜底，关键阶段之间打时间戳，超时留下可定位的尾行。
  • 规则文件防递归：公共宏加注释标明禁止自引用，新规则先在小 deck 上验证再进主流片 deck。

这一篇在知识体系里的位置 ​

本篇是 EDA 排错速查簇中「运行期卡死」节点的 FAQ 页：启动期 license 直接报错退出见 Calibre license checkout failed 排错速查，综合侧同款分诊见 Design Compiler 卡死超时速查，物理验证的正常流程与 runset 写法见 Calibre 物理验证实操，更多 EDA 报错主题从 开源 EDA 报错排错中心 进入。

一句话总结 ​

Calibre 运行卡死/超时的分诊起点是 ps/top 看 CPU：0% 走等待通道，用 transcript 尾行、lmstat 和 strace -p 在 license 排队、交互提示/管道阻塞、NFS 慢盘三者间对号入座；CPU 高位走计算通道，时间戳比对确认在推进就放行，单核跑满零推进则二分规则文件查递归宏；RES 贴内存是 swap 颠簸、LSF 作业消失先看 bhist -l 的 RUNLIMIT/MEMLIMIT，根治靠输入重定向、数据本地化、内存预算、timeout 分段日志四条跑批纪律。