NX/UG 许可管理，先看数字再花钱

Siemens NX 用的是 FlexNet Publisher 体系，vendor daemon 叫 ugslmd，license 文件里按 feature 划模块——NX100/NX101 是基础建模，NX102/NX103 是高级装配和 PMI，Mach 系列管 CAM，ADVANCED SIM 管仿真。NX 启动时不是只 checkout 一个号，是按打开的功能叠加申请：Core 必占，进高级装配再叠一个，进 CAM 再叠一个。一个会话占三个 feature 是常态，这是很多人算许可账算不明白的根本原因——以为 100 个号够 100 个人用，结果高峰期 60 个人就把池子抽干了。

还有个隐藏成本叫僵尸会话（zombie session），人关机了 license 没 checkin，或者挂着会话去看邮件了，服务器侧看还是"已占用"。FlexLM 的 lmstat 只认心跳，CAD 软件保活机制太勤快，TIMEOUT 参数经常形同虚设，这就是为什么单靠 lmutil lmstat -A 拉出来的占用数据水分很大。Nx 应用的占用时长和真实操作时长是两个完全不同的数，前者比后者能虚高 30% 到 50%，采购要是按前者做续费决策，钱基本是白扔。

先做三件事，别倒着来

第一，把并发曲线拉出来看 30 天。按模块分、按区域分、按时段分，看清楚周二上午十点和凌晨三点的占用差多少。重点盯 denial log，FlexNet 的拒绝事件带时间戳和用户名，是真实的容量信号，不是偶发噪声。

第二，对 lmstat 数据做去水处理。用键鼠空闲检测 + 活跃命令识别（REGEN、PAN、ZOOM、文件 IO 都得算活跃）重新算一遍真实使用时长，两个数一对比就知道水分在哪。CAE 求解、批处理脚本占的号千万不能动，动手前先把计算型会话和交互型会话分开。

第三，合同、服务器配置、实际使用范围三边对齐。哪个模块买了多少、enroll 在哪台服务器、哪些用户组能用，这些都得落到台账上。安装量、授权量、登录人数、并发量四个口径分开算，混起来得出的"利用率"没法支撑任何决策。

几个能落地的动作

模块级告警阈值设起来，GSD 这种贵的模块用到 80% 就预警。低频用户的共享池和核心用户的专属池拆开，用 GROUP_RESERVE 把预留资源锁住。回收策略从只提醒不回收开始跑两周，等误判样本积累够了再开灰度。续费前按真实峰值做情景测算，不是按当前采购量线性外推，拿数据去砍 SKU 比拍脑袋管用一百倍。

几个别踩的坑

单日报错别当长期趋势解读。供需分析没做完就先采购或强制回收，两头吃亏。改进项没责任人、没完成时间、没回读验证，人员一流动立马打回原形。数据水分没挤就上会汇报，领导拿着虚高数字做决策，回头都是麻烦。

一个真事

华东一家做汽车底盘件的，280 个 NX 用户，150 个浮动并发，CAM 模块单独 40 个号。续约前内部跑了三周数据，发现峰值真实并发只有 98/150，CAM 模块峰值 22/40，闲置率 35% 左右——主要被午休挂机、下班忘关、离职未清号这三种情况吃掉。动作：分模块 Inactivity Timeout（Core 20 分钟、CAM 15 分钟）+ 三秒回收弹窗 + 清 5 个幽灵账号 + 各部门匿名化利用率周报。CAM 模块续约时按真实峰值砍到 28 个号，加上 NX 主包从 150 砍到 120，一年省下的维护费差不多是三个工程师的年薪。第一次上会有人不信，拿原始 lmstat 日志和去水后的操作时长对比表当场戳穿，采购和研发老大都闭嘴了。

丑话说前面：这些是挖潜手段，解决不了永久性超并发——新车 SOP 前全员加班那种，该临时租 Token 就租，硬撑出事故更难看。