谁把 CATIA 的 MD2 占着不放,设计部反映许可严重不足

早上九点十分，群里又开始刷“谁把 CATIA 的 MD2 占着不放”，采购那边同步收到一条扩容申请，理由是“设计部反映许可严重不足”。但你去许可服务器上拉一眼实时状态，很可能看到另一个画面：一部分被签出的 Token 挂在某台工作站上，键鼠静默了四十多分钟，窗口里的装配体连视图都没转过一次。 抢是真的，闲也是真的。真缺口和假性短缺混在一起，采购看到的只有“不够用”三个字。

先把“不够用”拆开，别让它一团糨糊

“许可不够”在系统里至少对应四种完全不同的事实，混在一起谈，采购和 IT 永远对不上账。

• 容量真不够。 峰值并发持续顶到授权上限，拒绝数（denials）密集出现，排队时长在高峰段稳定拉长。这种是硬缺口，该买。
• 闲置占用把池子吃掉了。 授权数本身够，但大量 Token 被“开着不干活的会话”焊死在手里，真正要用的人签不进来。这是假性短缺，买再多也只是喂给闲置。
• 配置或模块错配。 买的是 A 模块的包，用户实际要用 B 模块；或者许可池按部门切死，A 部门闲着、B 部门排长队。数量够，结构不对。
• 流程或权限堵住了。 许可其实有空闲，但申请审批卡住、分配规则没覆盖到某个组，用户感知到的就是“拿不到”。

采购决策的起点不是“买不买”，是先把这四类分开。 分不开，后面所有动作都是赌。

第一步：摸底，重点盯“拒绝数”和“静默占用”

不要一上来就看平均利用率，那个数字在工业软件场景里几乎没有决策价值。平均下来三成闲置，不代表九点钟那二十分钟不排队。

具体要扒的东西：

• 峰值并发，不是平均值。 FlexNet 环境下用 lmutil lmstat -a -c port@host 定时跑，每五到十分钟一次，把 Total of X licenses in use 落成带时间戳的流水，至少覆盖一个完整项目周期。只看一次 lmstat 的实时快照，等于拿一张照片判断一部电影。
• 拒绝数，单独拉。 这里有一个很实际的坑：lmstat 根本不报 denials，用户点了软件没拿到许可、弹窗关掉走人，这件事在实时状态里是隐身的。denials 得从 vendor daemon 的 debug log 里解析，或者用支持 denials 采集的监控端去补。看不见拒绝数，你看到的“利用率”只反映供给端，不反映需求被压掉了多少。
• “已占用但无操作”的会话明细。 不是只看在线时长。某武汉汽配企业 200 个 CATIA V5R2026 许可，拉一周日志，日均 43 个处于“已占用但超过 2 小时无操作”状态。这 43 个不一定是闲置，但它们是必须逐个过一遍的嫌疑名单。

摸底出来的底稿，每一条要能指到“哪个账号、哪台机器、哪个模块、什么时间段、键鼠和命令状态是什么”。只有汇总百分比，后面没人服。

第二步：分类，把“不能碰的”先摘出去

拿到嫌疑名单，下一件事不是直接配回收，是标白名单。这一步省了，上线当天就会有人抱着没保存的模型来找你。

必须跳过往闲检测的场景，至少要包括：

• 正在跑求解的 CAE 进程。 Ansys Mechanical 算一晚上，键鼠确实没动，但 CPU 跑满。只看键鼠空闲就回收，第二天结果没了，这个责任没人担得起。
• KBE / DMU 脚本节点。 表面无键鼠，后台在循环运算、在刷视图。某汽配研究院的做法是给 KBE/DMU 脚本机直接白名单，Token 常驻到主动退出。
• 高工专机 / 审图终端。 高工经常开着大装配去查标准、对尺寸，窗口不动不等于没在用；审图终端可能只是 Viewer 模式浏览，也不能按设计岗的阈值一刀切。

白名单不是“永久占号”，是“退出时释放，但中间不碰”。 跟 RESERVE 把许可占死是两回事。

第三步：回收，条件要“与”，不是“或”

回收规则最容易出事的地方，是把键鼠空闲当成唯一判据。有人设 15 分钟无键鼠就回收，结果把正在跑大型装配干涉检查的会话踢了——电脑确实没动，CPU 跑满，人还在等结果。

相对稳的做法是多条件同时满足才触发：

• 键鼠无输入 ≥ N 分钟；
• 无活跃命令（不在草图编辑、Regen、DMU 回放、KBE 循环回调里）；
• 主窗口标题未变、视图静止，避开正在 Save As 的瞬间。

阈值按模块和岗位分开，不要一个数管全公司。普通设计岗 20 到 30 分钟，DMU/KBE 脚本机直接白名单，审图终端可以放长到 40 分钟以上。15 分钟一刀切，在工业软件场景里误杀概率太高；30 分钟起步，配合白名单，才跑得稳。

回收之后原用户回来的路径，必须提前设计。回收的是 Token，不是会话进程。 本地窗口保留，用户一动鼠标，客户端异步重新申请，走单独的优先级队列，不能跟新来的请求混排。没设优先级的时候，被回收用户平均等待能到 8 分钟以上；设了之后可以压到几十秒量级。回收做得再准，回来排队十分钟，用户体验跟强制踢下线没有本质区别。

第四步：在“回收跑稳之后”再看采购

不要在同一个月里既上回收又提扩容，两件事的数据会互相污染，你分不清峰值下降到底是因为回收生效还是采购到货。

顺序是：先让回收跑满一个完整的业务周期，再看剩下的缺口。

如果回收上线后，峰值并发仍然贴着授权上限，拒绝数没有明显下降，排队时长在高峰段稳定存在，那才是真缺口。这时候拿数据去谈采购，依据是“回收已经吃掉了闲置，剩下的需求是刚性的”，而不是“业务部门说不够”。某华南整车厂 160 个 CATIA V6 许可，回收前高峰平均等 22 分钟，闲置率 38%，本来准备追加 40 个；回收跑稳后闲置压到 8.2%，等待降到 3 分钟，采购单子撤了。

第五步：验证，别只看“利用率”一个数

看四个东西，放同一张看板上：

• 峰值并发：有没有从“顶死”变成“有峰但可调度”。
• 拒绝数：这是假性短缺是否被挤掉的最直接证据。回收跑了但拒绝数不降，说明你收错了人或者收的量不够。
• 平均等待时长：要保留下钻明细，能定位到具体模块和时段。
• 回收后重取等待：单独看，别混在总体等待里。这个数字如果超过一两分钟，回收策略的用户接受度会迅速崩掉。

利用率涨了但拒绝数也涨，说明你在制造排队，不是在优化。 利用率没动但拒绝数降了、等待短了，才是真把闲置挤出来了。

一个实测，不漂亮，但每一步都能对上

某汽车零部件企业，CATIA V5 和 3DEXPERIENCE 混跑，DS License Server 管着二十来个 MD2 包。早高峰八点五十到十点十分全满，群里天天有人喊拿不到。采购那边已经准备走扩容。

IT 先没动采购。把 lmstat 定时跑了三周，同时从 debug log 里扒 denials，发现两件事：峰值时段有接近三成的被签出会话，键鼠空闲超过 25 分钟且无活跃命令；而 denials 在早高峰的分布并不是均匀的，集中在少数几个模块上。 换句话说，不是整个池子不够，是“一部分 Token 睡着了，另一部分模块在硬堵”。

他们把 KBE 脚本机和两台高工专机标了白名单，普通设计岗设 25 分钟多条件回收，审图终端 40 分钟，回收后重取走优先级队列。跑了两个月，MD2 包没有增购，早高峰的 denials 降到了个位数，回收用户回来重新拿到许可的中位时间在两分钟以内。省下来的扩容预算，最后只补了两个真正持续拒绝的模块备机，不是整包扩容。

这里面没有任何“黑科技”。就是把拒绝数和闲置会话放在一起看，然后先把不能碰的摘出去，再收能收的，最后才让采购进场。顺序对了，数字自己会说话。