HyperWorks求解器排队排到崩溃？先别急着加许可，把调度做明白

仿真团队的痛，IT不懂。

采购说"你们要多少买多少"，IT说"服务器并发数没满啊"，只有仿真工程师自己知道——明明license池里还有OptiStruct的许可，但我的任务就是跑不起来，因为Radioss被占满了，而我的任务刚好要同时checkout这两个求解器。

HyperWorks这玩意儿跟CATIA、NX那种交互式CAD软件完全不一样。CAD是人在用，人下班了许可就该释放。仿真是机器在跑，一个非线性任务跑几十个小时很正常，期间许可一直占着不放。高峰期十个人同时提交任务，许可池瞬间被打穿，剩下的人只能排队等。

但真的是许可不够吗？

不一定。很多时候是调度没做好。

比如有人下午五点半提交了一个预计跑八小时的显式动力学任务，然后下班回家了。这个任务占着八个Radioss许可跑了一整夜，而晚上本来可以错峰跑批处理的其他任务全被堵住了。再比如有人开了HyperMesh前处理，checkout了OptiStruct许可准备跑优化，结果中途去开会了，一开就是两小时，许可占着没动。

先把数据拉出来看。

按求解器模块统计并发，别只看"HyperWorks"一个总数。OptiStruct、Radioss、Nastran、Abaqus（如果混用的话），每个求解器的许可是独立的，高峰期到底哪个模块在堵，要分开看。

区分交互会话和批处理会话。HyperMesh前处理是交互式的，人盯着屏幕操作；OptiStruct求解是批处理的，提交完就不用管了。这两类对许可的占用模式完全不同，混在一起统计没有意义。

看失败重试。任务提交失败后自动重试的，一次失败可能触发三次checkout请求，日志里看着像三个用户在抢许可，实际上是一个人。这个要过滤掉，不然数据是虚高的。

调度怎么搞。

给任务分级。关键路径上的任务优先跑，可延迟的往后排。比如第二天要汇报的结果，今晚必须跑完；下周才要的优化迭代，可以排到凌晨。

设预约机制。大任务提前报备，IT这边看许可池的空闲窗口，安排到合适的时间段跑。别所有人都赶在下午提交，把资源挤爆。

回收僵尸会话。HyperMesh开了不操作超过两小时的，自动发邮件提醒；四小时没响应，释放许可。批处理任务跑完了但session没正常退出的，自动清理。这个脚本不难写，Altair的license日志格式很规整，解析一下就行。

几个数盯着：

任务等待时长——从提交到拿到许可开始跑，花了多久，这个数直接反映用户体验；
模块拒绝率——每个求解器的checkout被拒次数除以总请求次数，哪个模块高就重点看哪个；
批处理成功率——提交的任务有多少是正常跑完的，失败率高的话可能是许可不稳定或者资源不够；
峰值利用率——别只看平均值，看每天最高并发到了多少，连续几天打满才考虑扩容。

说个事。

有家做碰撞仿真的，买了四十个Radioss许可，天天有人抱怨排队。IT一看日志，白天峰值确实四十个全满，但仔细分析发现其中有六个session是前一天晚上提交的批处理任务，早上早就跑完了，但session没释放，一直挂着。另外有几个人习惯早上上班先开HyperMesh把许可占上，然后去开晨会，一占就是四十分钟。加了自动回收规则，跑完的批处理session十五分钟内自动清理，空闲超过三十分钟的交互式会话自动提醒。跑了一个月，白天平均等待时长从两小时降到二十分钟，扩容的事就没提了。