Palladium / ZeBu 仿真服务器运维：资源占用、主机巡检与故障定位
Palladium、ZeBu 这种仿真器是 EDA 里最贵、最娇气的设备，一台机器出问题，几个项目一起等。运维要盯三样东西：资源占用、主机状态、版本一致性。这篇讲仿真服务器的日常运维和故障定位。
一、资源占用怎么看
仿真器的板卡是抢的，谁先拿到谁跑，拿不到就排队。每天先看谁占了什么：Palladium 用 test_server 查资源占用和排队情况，ZeBu 也有对应的资源查询命令。重点是分清两种状态：板子被别人占着（等），和板子本身不在线（修）。前者是调度问题，后者是硬件问题，处理方式完全不同。
# Palladium：看当前资源占用和排队
test_server
# 看某块板子的状态和占用者
test_server -board 0
# ZeBu：查运行时资源
zUtils -sysstat $ZEBU_SYSTEM_DIR资源紧张时先别急着加机器：看一眼是不是有人跑完了没释放，或者低优先级长任务占着不放。长期看占用率曲线，持续在 90% 以上再谈扩容。
二、主机巡检
- 磁盘：仿真 run 目录涨得很快，
df -h每天看，85% 告警，留够一次完整 run 的空间。 - 内存：xmsim 这类进程吃内存是常态，看的是有没有泄漏趋势，不是瞬时值。
- 时间同步：license 和分布式编译都依赖时间，NTP 漂了先修时间再查别的。
- daemon 进程：license daemon、编译服务、运行时服务，一个都不能悄悄死掉。
- 网络：仿真主机和 license 服务器、存储之间的连通性，丢包比断网更难查。
三、版本一致性：头号故障源
仿真器运维里最多的故障不是硬件坏了，是版本对不上：设计用新版工具编译，跑在旧版运行时上，或者反过来。典型报错像 Invalid NameDb version: expected 20191128, got 20210917，意思就是编译数据库的版本比运行环境新，数据库加载失败。处理办法只有两个：切到编译时的环境跑，或者用当前环境重新编译。千万别手改版本号，那是自欺欺人。
规矩很简单：编译和运行用同一套环境脚本，环境脚本进版本管理，升级先在测试项目上验证。每次跑之前先 echo $ZEBU_ROOT、echo $VCS_HOME 确认一遍，比出问题再查省事得多。
四、常见故障定位
板子 OFFLINE、资源不足。下载或配置阶段报 not enough board/target resources，先查 test_server 看哪些板子 OFFLINE，再看编译日志里这次 run 到底申请了哪些板子。板子被别的任务占着是排队，板子 OFFLINE 是要修，两种处理完全不同。别急着重启，别杀别人的任务。
swap 挂起、进程假死。仿真跑着跑着不动了，先看进程还在不在、CPU 还动不动，再看系统 log 有没有 OOM kill。xmsim 这类进程的输出和 xeDebug 的 log 合并在一起，grep 那个文件找错误，别只盯着终端。
缺库起不来。图形工具报 libX11.so.6 not found、libnsl.so.1 not found，是运行主机缺 32 位库或者缺基础包。先用 ldd 把缺的库一次查全，确认二进制是 32 位还是 64 位再装对应的包，别逐个试。
# 查缺失的库，一次查全
ldd /path/to/tool | grep "not found"
# 查谁在写日志文件（找写日志的进程）
lsof xeDebug.log
# 看系统有没有悄悄杀进程
dmesg | grep -i "killed process" | tail -20五、运维规范
- 环境脚本统一：所有人 source 同一份环境脚本，个人配置只做加法，不许改基础变量。
- 版本锁定：项目立项时锁定工具版本，流片前不升级；升级走变更流程。
- 变更记录：谁改了环境、改了什么、为什么改，写进记录，出问题先翻记录。
- 故障复盘：每次故障写清楚现象、根因、处理和预防，下次同样报错直接翻复盘。
仿真器运维的核心是确定性：同样的输入，在同样的环境里，跑出同样的结果。资源看得见、主机摸得着、版本对得上，剩下的才是设计本身的问题。
