HyperWorks 排队排到后半夜，你以为是许可不够，其实是 Unit 池被人当免费茶水间了

仿真组长老周在群里甩了张截图，凌晨一点半，三个 OptiStruct 作业还在 queue 里挂着，状态 Lc，许可等待。他说明天客户要看结果。我问他，白天池子里多少 Unit 在跑，他说不知道，Altair 那边只看到 total 用了多少。这就是 HyperWorks 最操蛋的地方：你盯着“作业排队”看，永远看不出谁在浪费，因为 HyperWorks 卖给你的不是“几个座位”，是一个共享 Unit 池，池子里的水被人拿杯子舀走之后坐在旁边刷手机，你从水位计上根本分不清是在真喝水还是在占着。

先把机制说清楚，不然所有讨论都是瞎猜。Altair 的 licensing 现在跑在 Altair License Manager（ALM） 上，一个 Altair Unit（AU）对应 1000 个 license features，你买的 AU 数乘以一千，就是池子里能同时被抽走的 feature 总量。关键在于 leveling：同一个 host、同一个 username 下跑多个 Altair 应用，只按最贵的那个扣 Unit，不是叠加。HyperMesh 抽 21 AU，再开 HyperGraph 抽 6 AU，池子里只少 21000 features，不是 27000。这个设计本来是省钱的，但在没人管的环境里，它反过来变成了浪费的放大器：一个人开着 HyperMesh 做前处理，同时挂一个 HyperView 看云图，再留一个 Inspire 窗口发呆，从池子的角度看，他就是那个“最贵的应用”在占着位置，后面的 OptiStruct 批处理排队等水喝，跟他没有半毛钱关系。

排队和“占用”是两回事，日志里分得清，人眼里分不清。

FlexNet 的 debug log 里，拒绝是拒绝，排队是排队。denied 是池子里当时确实没有足够的 feature 可给，说明供需在那个瞬间硬碰上了；但更多时候你看到的不是 denial，是 solver 作业提交之后在调度器那边等，等的原因是脚本里写的 -l h_rt 和许可 check 的顺序有问题，或者 PBS / SLURM 根本没有把 Altair 的 feature 可用量纳入调度决策。PBS Professional 自己就吃 GridWorks units（GWU），HyperWorks 吃的是 HyperWorks units（HWU），两套 feature 在同一个 license server 上，但 PBS 的调度器默认只看自己那一套的可用量，不天然感知 HWU 还剩多少。结果就是：compute 节点空着，调度器把作业派过去，作业启动第一步 almutil 去 checkout，被 ALM 一巴掌打回来，作业失败或者重新排队，一晚上就在那儿空转。这不是许可容量不够，是调度器跟许可管理器之间没有说同一种语言。

回收不是万能药，TIMEOUT 管的是心跳，不是人。

FlexNet 的 TIMEOUTALL 最小有效值是 900 秒，写 600 进去系统也按 900 执行，因为厂商在 daemon 层写死了下限，防止网络抖一下就误回收。这意味着就算你把回收开到最激进，一个 session 也得静默 15 分钟才会被踢回池子。更麻烦的是，TIMEOUT 检测的是 TCP 心跳的静默，不是键盘鼠标的活跃。工程师开着 HyperMesh 去开一小时会，窗口没关，心跳还在走，TIMEOUT 根本不触发。真想把“人走机在”的那部分 Unit 挤出来，光靠 license server 的配置不够，得在终端侧拿操作系统的输入空闲时间做交叉判断，或者至少把 check-in 的动作做在 HyperWorks 的 session 管理层，而不是指望 FlexNet 替你干这件事。

那调度到底怎么改，才叫“许可感知”，不是嘴上说说。

不需要上什么玄乎的算法。最低成本的一步，是把 ALM 的实时可用 feature 数，通过 almutil 或者 Altair One 的 API，喂给 PBS/SLURM 的调度策略里，让“提交作业”这个动作在进入 queue 之前就先看一眼池子。学术那边做的 license-aware backfilling 实验数据摆在那儿：在许可和算力双约束下，把许可可用性嵌入调度决策，平均等待时间能压掉 97%，许可利用率拉到 94%。你不需要一步做到论文的水平，但至少得让调度器知道“现在池子里只剩 3000 features，OptiStruct 一个作业要抽 4000，别把它塞进去空转”。第二步才是任务分级：交互式的前处理 session 和 overnight 的 solver 批处理走不同的优先级队列，solver 作业在提交时就把预估的 AU draw 写进 resource request，调度器据此做 backfill，把短作业填进长作业等 Unit 的缝隙里。HyperWorks 的 batch 模式本来就支持在命令行里指定 core 数和 solver 类型，把这些信息结构化地传到调度层，比拍脑袋“再加两套”有用得多。

一个不用翻墙就能查到的案例，比任何理论都响。 上饶汉腾汽车，CAE 仿真部门 7 台工作计算机里装了 10 套 HyperWorks，手里只有 1 套 2014 年买的正版，含 5 个授权 ukey，第三方鉴定确认其中 5 套未获授权。行政处罚罚款 2 万，听上去不疼，但和解条件是采购 230 万的正版软件。算一笔粗账：如果当初那 7 台机器上的安装全部走 ALM 的浮动 check-out，按真实并发来配 Unit，230 万里有多少是可以不花的，他们自己心里清楚。HyperWorks 的 Unit 池天生就是给浮动共享用的，你把它当 node-locked 一人一套来理解，然后靠“多装几台”来解决排队，最后就是汉腾这个结局：罚款是小头，被迫集中采购的那一下才是真出血。

老周后来做的事很简单，没加一套 Unit。他把 almutil 的实时 feature 用量每五分钟抓一次，跟 PBS 的 queue 状态并排贴在一张表上，跑了三个星期。然后发现白天池子里稳定有 6000 到 8000 features 被 HyperMesh 和 HyperView 的交互 session 占着，而这些 session 里超过四成在连续 20 分钟内的 CPU 时间几乎为零。他把 solver 作业的提交时间从“随时”改成“下午五点之后批量走”，同时给 PBS 加了一条 pre-check 脚本，feature 不够就直接进 held 队列，不再空转。一个月后，同一个 Unit 池，夜间 solver 的完成量多了将近三成，OptiStruct 的平均等待从四个多小时掉到五十分钟以内。他没买新许可，他只是把池子里那些被人拿杯子舀走之后没喝的水，重新倒回去了。