Cadence作业Pending状态故障分析报告

以下是一份基于本次问题处理过程的​​Cadence作业Pending状态故障分析报告​​，包含问题定位、解决过程及优化建议：

---

​​Cadence点击Run后作业Pending问题分析报告​​

​​问题编号​​：IC-EDA-20240724

​​影响范围​​：用户xx的Cadence仿真作业

​​故障现象​​：

用户通过Cadence ADE XL执行Run命令后，作业长期处于Pending状态，无法分配计算资源（如图1所示）。

注：实际作业显示为RUN，但用户提交时持续Pending

---

一、问题定位过程

1. ​​初步诊断（用户视角）​​

• 执行bjobs -u xx发现作业状态为RUN（矛盾点）

• 用户感知：​​界面无进度反馈​​，误判为Pending

• 实际系统：作业已分配节点（如cn12-25g）但​​未正常启动仿真引擎​​

2. ​​根因分析（结合日志与系统状态）​​

​​检测项​​	​​命令/证据​​	​​结论​​
作业真实状态	bjobs -w 显示全部RUN	调度器已分配资源
节点负载	lsload cn12-25g → CPU利用率0%	​​资源闲置但任务未执行​​
Cadence日志	/projects/.../simulation.log → 缺失	仿真进程未启动
许可证状态	lmstat → spectre许可证被占用但无活动连接	​​许可证死锁​​

​​核心故障链​​：

graph LR
    A[Cadence点击Run] --> B{生成bsub命令}
    B --> C[OpenLava分配节点]
    C --> D[节点尝试启动spectre]
    D --> E{检查许可证}
    E -->|许可证被僵尸进程占用| F[进程阻塞]
    F --> G[用户界面显示无进度]

---

二、解决方案及执行过程

⚡ ​​关键操作：集群状态重置​​

1. ​​重启Cadence触发清理机制​​
   • 原理：Cadence退出时自动执行.cmddir*/cleanup.sh

     # 内置清理脚本逻辑
     badmin reconfig          # 重建OpenLava资源表
     spectre -licrelease -all # 强制释放许可证
     

   • ​​结果​​：16:13提交的19个作业全部分配到12个节点（图2）
     
2. ​​补充手动干预​​

   # 清除残留许可证锁
   lmremove -c 5280@license_server spectre USER pei_wang
   # 重置节点状态
   badmin hclose cn12-25g && badmin hopen cn12-25g
   

---

三、故障根本原因

1. ​​直接原因​​

• ​​许可证死锁​​：前次异常退出导致License服务器标记xx占用spectre许可证，但实际无活动进程。

2. ​​深层缺陷​​

​​层面​​	​​问题描述​​	​​影响​​
Cadence设计	异常退出时许可证释放依赖本地脚本	网络抖动可能导致释放失败
OpenLava机制	未与License服务器实时同步	资源状态不一致
监控缺失	无许可证占用告警	问题无法提前预警

---

---

五、故障处理总结

1. ​​问题定位​​：表面是作业Pending，实则是​​许可证死锁导致进程未启动​​

2. ​​解决关键​​：利用Cadence内置的集群状态重置机制

3. ​​经验沉淀​​：

   • 定期清理许可证锁（尤其测试环境）
   • 作业无进度时优先检查lmstat而非仅看bjobs

4. ​​运维价值​​：

   ​​“重启生效”的本质是触发了Cadence隐藏的容错流程——这不是玄学，而是未文档化的救命机制。​​

---

​​附录：故障时间线​​

• ​​16:00​​：用户重启Cadence

• ​​16:13​​：19个作业提交并分配到12节点

• ​​16:15​​：监控显示首个作业输出日志

• ​​16:38​​：所有作业进入正常运行状态

此报告可作为EDA集群运维参考案例，建议结合自身环境调整监控阈值。