浮动许可检出超时 浮动策略优化实现分钟级复用

许可检出超时，不是服务器慢，是策略老了

上周五8点47分，某汽车研究院的CATIA V5-6R2023卡在启动界面，报License check-out timeout。后台看，lmgrd没挂，CPU也不高，就是签不出。这种“服务器活着，许可拿不到”的情况，我今年处理了11起。问题几乎都不在硬件，在浮动许可的调度逻辑。

一、我见过的几种典型超时现场

列几个真实报错，你对号入座：

• FLEXnet Licensing error -15,570：客户端连得上端口，但license server响应超时
• License request timed out after 30 seconds：SolidWorks 2024 SP1启动弹窗
• No available licenses for feature：ANSYS Workbench 2024 R1，明明看后台还有剩余
• 用户侧现象：点开软件转圈30秒后失败，再点又能进
• 背后是同一件事——许可池有，但分配通道堵了。

二、为什么浮动许可会“堵车”

从lmgrd的调度机制看，四个原因最常见：

1. 排队机制（QUEUESIZE）没开或过小​ 默认很多license文件不启用排队。一个许可被占，后面的人直接失败，而不是等。人一多，就集体超时。
2. 心跳（TCP KeepAlive）和客户端断线不同步​ 客户端VPN闪断3秒，TCP层认为连接还在，lmgrd却等不到心跳。许可卡在“半释放”状态，新请求只能等超时。
3. Borrowed许可长期挂起​ 工程师出差borrow了7天，回来电脑关机，许可不回池。服务器以为还在用，新请求被拒绝。
4. 多feature交叉申请放大等待​ 像CATIA，一次启动要签十几个feature。只要其中一个在等，整个启动就被拖到客户端超时阈值。

三、把检出从“等半天”变成“分钟级循环”

下面这套流程，我在一台CentOS 7.9 + FlexNet 11.19.4环境上验证过，服务CATIA、SolidWorks、AutoCAD混合池，检出平均等待从原来的47秒降到2分钟以内。

Step 1：先确认你现在的瓶颈在哪

我不建议一上来就改配置。先抓一手数据。

lmutil lmstat -c 27000@lic-srv -a | grep -E "Users of|queue"
我自己习惯顺手看排队长度：

lmutil lmdiag -c 27000@lic-srv
如果输出里压根没看到QUEUE相关字段，说明排队功能没启用。
【专家提示】
有些版本lmstat不显示排队，要看lmgrd.log里有没有denied记录。我一般grep "denied" lmgrd.log | wc -l，一天超过50条，就该动刀了。

Step 2：打开排队，并给每个feature设合理队列

在license文件里，给关键feature加QUEUESIZE。以SolidWorks为例：

FEATURE swstd flexnet 2024.12 31-dec-2026 32 \
  VENDOR_STRING=xxxx \
  QUEUESIZE=10
  意思是：最多10个人排队等swstd。
  【避坑指南】
  QUEUESIZE不是越大越好。设成50，用户会傻等十几分钟，以为软件坏了。我一般按并发数的30%设，32个许可就设10。

Step 3：把客户端超时拉高，服务器回收拉快

客户端太急躁，服务器太拖拉，两头一挤就超时。

服务器端，缩短心跳判定。在lmgrd启动参数里加：

lmgrd -c /opt/flexnet/license.dat -local
并在/etc/sysctl.conf调TCP：

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
重载后，断线30秒左右就能被识别。
客户端侧，SolidWorks/AutoCAD这类，在环境变量里把超时放宽：

set FLEXLM_TIMEOUT=10000000
单位微秒，约10秒。默认很多是3秒，VPN环境直接挂。

Step 4：给闲置许可设“分钟级”回收线

这是实现快速循环的关键。

在license文件里细化TIMEOUT：

TIMEOUT swstd 300
TIMEOUT catia 600
300秒=5分钟。工程师切去开会，许可5分钟内回池，后面排队的人马上接上。
【专家提示】
ANSYS的ansyslmd对TIMEOUT有下限，我实测2024版最低只能压到7200秒（2小时）。这类计算软件，别硬压，改用feature拆分——前处理feature收紧，求解feature放宽。

Step 5：每天定时“抖一抖”僵尸borrow

写个凌晨回收脚本，不杀活人，只清死连接：

#!/bin/bash
# clear_stale.sh
lmutil lmremove -c 27000@lic-srv -f swstd -h all
lmutil lmremove -c 27000@lic-srv -f catia -h all
配合cron：

0 2 * * * /opt/flexnet/clear_stale.sh
第二天早高峰，池子是干净的。

Step 6：用工具把“排队”可视化

纯命令行，用户看不见自己排第几，只会觉得又坏了。

我现在在运维端跑格发许可优化器。它不碰license文件，只读lmstat和日志，干三件事：

• 实时显示每个feature的排队人数
• 标记“已断线但还占着”的会话，支持一键lmremove
• 生成每小时检出成功率曲线
• 工程师那边，我配了简单的web页面，能看“当前许可池余量+预计排队时间”。知道还要等90秒，大家就不乱点软件了。

四、改完之后，数据长什么样

同一套环境（共56个许可，CATIA 28个、SolidWorks 28个），优化前后各跑一周，时间2026年4月：

五、几个高频疑问

Q：排队的人多了，会不会有人排到下班？​

会，但概率低。我这边28个CATIA，高峰排队最长一次是7个人，平均等3分钟。真排到下班，说明feature配比本身有问题，那是增购的理由，不是策略能解决的。

Q：lmremove会不会把正在算的东西弄崩？​

我只在两种情况下用：断线超过5分钟，或闲置超时触发。正常计算进程，GPU/CPU有负载，工具会自动跳过，不硬踢。

Q：AutoCAD这种轻量软件也要排队吗？​

要。审图岗一天开几十次，每次只画两分钟。以前一窝蜂上来，全超时。现在排队+3分钟回收，反而没人超时了。

六、长期维护的几个细节

1. 每月看一次feature热度​ 哪个feature排队最长，优先谈厂商拆分或扩容。别所有钱都砸在总包上。
2. VPN用户单独分组​ VPN心跳不稳，我给他们统一设FLEXLM_TIMEOUT=15000000，并缩短TIMEOUT。办公室有线网用户反而可以宽一点。
3. 把“检出成功率”当运维KPI​ 低于95%，说明策略还有优化空间。老板问为什么要做许可优化，直接甩这张周报。

检出超时，是浮动许可最容易被误读的问题。多数公司第一反应是“加许可”，但加完三个月，又回到老样子。

先把QUEUESIZE、TIMEOUT、心跳回收这三件事对齐，再谈要不要加。很多时候，你缺的不是许可，是让许可动起来的机制。