FlexNet Publisher 2026 R1 License Server 资源容量规划、并发连接测试与参数调优指南

适用版本：FlexNet Publisher 2026 R1（11.19.10），License Administration Guide，March 2026
研究范围：License Server Manager（重点为 lmgrd）与 vendor daemon 的连接容量、文件描述符容量、压力测试方法及并发连接参数调整。
资料边界：本文只把 Revenera 2026 R1 官方文档明确陈述的内容写作“官方结论”；测试步骤、计算模板和 Linux 观测命令属于基于官方机制构建的工程实施方法，并明确标注为“工程方法”，不冒充 Revenera 原文。

1. 核心结论

FlexNet Publisher 的 license server 由两层组成：License Server Manager（lmgrd 或 lmadmin）和 vendor daemon。License Server Manager 是客户端连接 vendor daemon 的入口，负责初始接触并把请求转交给相应 vendor daemon，因此它的同时连接能力小于 vendor daemon。lmgrd 默认可同时处理约 1,000 个客户端连接。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；License Server Manager “lmgrd”]

vendor daemon 的最大连接能力接近 30,000 个 job connections，但 Revenera 为保证 license server 性能，建议总连接数不超过 10,000。只有在 license model 简单、服务器硬件性能较强，并且软件生产商事先完成压力测试的情况下，才可以考虑超过 10,000。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

在 POSIX 平台上，vendor daemon 的实际连接限制不是只由 MAX_CONNECTIONS 决定。vendor daemon 启动时调用一次 getrlimit() 获取系统可打开文件描述符数量，并把该系统限制与 MAX_CONNECTIONS 比较；实际使用较小值，并从系统能力中扣除一定内部预留。因此，提高 MAX_CONNECTIONS 而不提高进程启动时的文件描述符限制，不会获得对应的实际容量。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

LM_SERVER_HIGHEST_FD 只用于限制 lmgrd 的同时客户端连接数，不影响 vendor daemon 的允许连接数。在 Linux 上，该变量最大值和默认值为 1024；在 Windows 上为 4096，但每个 lmgrd job connection 使用四个文件描述符。[来源：Revenera 2026 R1，Environment Variables]

容量测试必须分别覆盖两种不同压力：

入口连接洪峰：大量客户端在短时间内同时连接 lmgrd；
稳定持有连接：大量 job connections 被转交给 vendor daemon 并持续存在。

这是由官方描述的两层连接模型、不同限制和不同失败表现直接决定的。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；License Server Manager “lmgrd”]

2. 架构与连接原理

2.1 License Server Manager 的职责

Revenera 说明，License Server Manager 是 license server 的一个组成部分，另一个组成部分是 vendor daemon。lmgrd 负责：

启动并维护 license 文件 VENDOR 行中列出的 vendor daemon；
接受 FlexEnabled application 的初始连接；
把 checkout 或其他请求转交给正确的 vendor daemon。

[来源：Revenera 2026 R1，License Server Manager “lmgrd”]

连接路径可表示为：

FlexEnabled application
        │
        │ 初始连接、vendor 定位
        ▼
lmgrd / lmadmin
        │
        │ hand off
        ▼
vendor daemon
        │
        │ checkout、heartbeat、checkin、管理查询
        ▼
License service

该图是依据官方“gateway”和“hand off client connections”描述绘制的逻辑示意。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；License Server Manager “lmgrd”]

2.2 为什么 `lmgrd` 与 vendor daemon 的容量不能混为一谈

lmgrd 主要承担客户端初始连接和请求转交，因此它面对的是同时建立连接的瞬时并发。vendor daemon 在接管连接后承担实际的 license job 交互，因此它面对的是持续存在的 job connections 总量。Revenera因此明确指出，License Server Manager 的连接限制小于 vendor daemon。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

这意味着以下两个场景可能得到完全不同的结果：

10,000 个 job 分批、平缓启动：lmgrd 未必出现约 1,000 个同时连接的洪峰，但 vendor daemon 可能长期持有大量连接；
2,000 个 job 在同一时刻启动：即使最终稳定连接数不高，也可能先把 lmgrd 的入口连接能力压满。

上述场景是根据官方两层容量模型推导出的工程解释，不是官方提供的固定测试数据。[依据：Revenera 2026 R1，Maximum Client Connections to License Server]

2.3 restart 后的状态特征

Revenera说明，lmgrd 和 vendor daemon 重启后都不保留状态信息；服务端不会记得重启前仍有 outstanding checkout 的客户端。该设计使 server 总是从已知状态启动，但重启后的客户端恢复行为取决于客户端和生产商实现，不能从通用管理手册推断所有 EDA 工具都会以相同方式恢复。[来源：Revenera 2026 R1，License Server Manager “lmgrd”]

3. 容量规划对象

3.1 `lmgrd` 同时连接容量

Revenera给出的 lmgrd 默认同时连接限制约为 1,000 个客户端，并允许使用 LM_SERVER_HIGHEST_FD 对其进行限制。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

LM_SERVER_HIGHEST_FD 的官方定义如下：

用于限制到 lmgrd 的同时客户端连接数；
默认允许最大同时连接数，约为 1,000；
Linux 最大值和默认值为 1024；
Windows 最大值和默认值为 4096，但每个 lmgrd job connection 使用四个文件描述符；
不影响 vendor daemon 的允许客户端连接数。

[来源：Revenera 2026 R1，Environment Variables]

因此，LM_SERVER_HIGHEST_FD 更适合作为 lmgrd 的入口保护或限制参数，而不能用来扩展 vendor daemon 容量。[来源：Revenera 2026 R1，Environment Variables]

3.2 vendor daemon 总连接容量

Revenera给出三层边界：

边界	官方说明
接近的最大连接能力	约 30,000 job connections
通用性能最佳实践	总连接不超过 10,000 jobs
超过 10,000 的前提	license model 简单、硬件强，并由 producer 事先完成压力测试

[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

“接近 30,000”不能解释为生产环境应把上限直接设置为 30,000；Revenera同时给出的性能最佳实践仍是 10,000 以内。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

3.3 POSIX 文件描述符容量

Revenera要求，在 Linux 和 Unix 上，文件描述符 ulimit 至少应达到预计的 vendor daemon 最大 job connections 数。官方特别指出，Linux VM 的文件描述符上限通常可能只有 1024，因此可能需要通过启动脚本、systemd 或 launchd 配置提高。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

在 POSIX 平台上，官方给出的 vendor daemon 限制逻辑是：

effective_vendor_limit
    = min(MAX_CONNECTIONS, systemLimit - certainReserve)

其中，systemLimit 由 vendor daemon 启动时的一次 getrlimit() 调用获得；certainReserve 是 vendor daemon 为内部使用保留的资源，官方页面没有公开其具体计算值。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

因此不能把公式进一步写成一个固定可计算常数，也不能声称“nofile 等于 N 时一定可接受 N 个业务连接”。官方只明确说明要扣除一定预留。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

3.4 `MAX_CONNECTIONS`

MAX_CONNECTIONS 用于限制 vendor daemon 的最大连接数。2026 R1 页面给出的允许范围为 31 到 10,00,000，未配置时默认值为 10,00,000；该页面使用印度数字分组，10,00,000 即 1,000,000。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

这个参数允许填写的数值范围不等于官方推荐的生产性能范围。通用性能指导仍然是 vendor daemon 总连接数不超过 10,000，接近 30,000 是最大能力描述，超过 10,000 需要 producer 预先压力测试。[来源：Revenera 2026 R1，MAX_CONNECTIONS；Maximum Client Connections to License Server]

vendor daemon 接近限制时，会保留 30 个连接供 lmreread、lmstat 等重要工具交互。连接限制达到后，进一步连接会被断开并返回 -237 (LM_VD_MAX_CLIENTS_REACHED)；版本低于 11.16.3 的旧客户端可能收到 -140 (LM_BADCOMMAND)。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

4. 需要规划的资源维度

4.1 官方明确关联的资源

基于 2026 R1 文档，连接容量至少直接关联以下资源：

资源	对象	官方关系
同时客户端连接	`lmgrd`	默认约 1,000；可由 `LM_SERVER_HIGHEST_FD` 限制
job connections	vendor daemon	接近 30,000；最佳实践不超过 10,000
文件描述符	POSIX vendor daemon	`ulimit` 至少覆盖预计最大 job connections；实际限制参与 `min()` 计算
服务器硬件性能	vendor daemon	超过 10,000 仅在强硬件、简单 license model、producer 压测后考虑
网络连接状态	`lmgrd`	过载时可能积累 `ESTABLISHED` 和 `CLOSED_WAIT` socket
管理连接预留	vendor daemon	保留 30 个连接供重要 utility 使用

[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Environment Variables]

Revenera在这些页面中没有给出 CPU 核数、内存容量、磁盘 IOPS 或网络带宽的固定 sizing 表。因此不能仅凭通用手册写出“每 1,000 个连接需要多少 CPU/内存”的官方数值。超过 10,000 时，官方要求 producer 预先压力测试，而不是套用统一硬件公式。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

4.2 连接数不等同于许可证使用数

lmstat 可以显示 daemon 状态、license files、各 feature 用户和 vendor daemon 下的 feature 用户；但它不返回未服务的 uncounted licenses，也不返回 queued users 和因 duplicate grouping 共享的 licenses。[来源：Revenera 2026 R1，lmstat]

因此，lmstat 中的 feature checkout 数不能直接替代底层 TCP 连接数或 vendor daemon 的连接计数。官方文档也没有规定一个 EDA job、一个 checkout、一个 feature 与一个 TCP connection 必然一一对应。容量测试必须同时采集 license 业务视图和操作系统连接/FD视图。[依据：Revenera 2026 R1，lmstat；Maximum Client Connections to License Server]

5. 如何测试资源容量

本章中的测试组织、阶段划分、Linux 命令和判定模板属于工程测试方法。其测试对象、阈值和失败信号来自 Revenera 2026 R1 官方文档；Revenera没有在上述章节提供一套可直接执行的标准压测脚本。

5.1 测试前提

使用与生产环境相同或拟部署版本的 lmgrd、vendor daemon、license file、options file 和客户端版本组合。Revenera建议始终使用最新版本的 lmgrd，同时指出新 lmgrd 可配合旧 vendor daemon 或客户端，但新 vendor daemon/客户端未必能正确配合旧 lmgrd。[来源：Revenera 2026 R1，License Server Manager “lmgrd”]
测试应由非 root 用户运行 license server。Revenera说明，root 启动进程会引入安全风险；如果必须由 root 发起，应使用 su 让 lmgrd 以非特权用户运行。[来源：Revenera 2026 R1，Manual Start]
确认 lmgrd 和 vendor daemon 所需端口已在防火墙开放，否则连接失败不能用于判断容量。[来源：Revenera 2026 R1，Starting the License Server Manager on UNIX Platforms]
在测试前记录 vendor daemon 启动时继承的文件描述符限制，因为 POSIX 平台只在 vendor daemon 启动时调用一次 getrlimit()。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

5.2 基线采集

5.2.1 License 服务视图

使用 lmstat 检查 license manager 与 vendor daemon 状态：

lmutil lmstat -lm -c port@host
lmutil lmstat -vd -c port@host
lmutil lmstat -S vendor_name -c port@host

-lm 显示 license manager 状态，-vd 显示 vendor daemon 状态，-S vendor 列出该 vendor 的 feature 用户。[来源：Revenera 2026 R1，lmstat]

避免把高频 lmstat -a 当作无成本采集方式。Revenera明确说明 -a 可能开销较高，活跃用户很多时会产生大量网络活动。[来源：Revenera 2026 R1，lmstat]

5.2.2 POSIX 进程资源视图

以下命令用于读取 Linux 运行态，不是 Revenera工具命令：

LMGRD_PID=$(pgrep -o lmgrd)
VENDOR_PID=$(pgrep -o vendor_daemon_name)

grep -i 'open files' /proc/${LMGRD_PID}/limits
grep -i 'open files' /proc/${VENDOR_PID}/limits

find /proc/${LMGRD_PID}/fd -mindepth 1 -maxdepth 1 | wc -l
find /proc/${VENDOR_PID}/fd -mindepth 1 -maxdepth 1 | wc -l

采集这些数据的依据是：官方把 POSIX vendor daemon 的实际连接限制与启动时 getrlimit() 得到的 open-file limit 关联起来。[来源：Revenera 2026 R1，MAX_CONNECTIONS；Maximum Client Connections to License Server]

5.2.3 Socket 状态视图

ss -s
ss -Hantp | grep -E 'lmgrd|vendor_daemon_name'

应特别统计 ESTABLISHED 和 CLOSE-WAIT。Revenera指出，lmgrd 被连接请求洪峰压垮时，server 上可能积累 ESTABLISHED 与 CLOSED_WAIT sockets；客户端活动降低后，这些状态会随着 lmgrd 稳定而消退。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

Linux 工具通常把该 TCP 状态显示为 CLOSE-WAIT；Revenera页面文本使用 CLOSED_WAIT。本文不据此扩展出额外协议含义。

5.3 测试 A：`lmgrd` 瞬时连接洪峰

目标

验证大量客户端同时发起初始连接时，lmgrd 是否出现入口拥塞，并确定当前环境能够稳定处理的启动速率和同时连接峰值。

方法

准备可重复发起合法 license 请求的测试客户端或生产商提供的测试工具；
分阶段提高同一时间窗口内的启动数量，例如逐级增加并发批次；
每一阶段保持 license 业务请求类型一致，避免同时改变 feature、客户端版本和网络路径；
记录客户端错误、debug log、lmgrd socket 状态、连接建立时间和请求成功率；
在每阶段之间等待连接状态恢复到基线，避免上一阶段残留干扰下一阶段。

该方法针对的是 Revenera所称的“spike of client connection requests”。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

官方失败信号

客户端通常出现 LM_CANTREAD (-16)；
debug log 可能出现“Maximum connections to the server has reached”相关告警；
server 上 ESTABLISHED 和 CLOSED_WAIT socket 出现堆积。

[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

通过标准建议

工程上可把“通过”定义为：目标启动洪峰下没有 -16，没有最大连接告警，socket 状态能够在测试后恢复，且业务请求成功率和响应时间满足内部SLA。Revenera只提供错误与状态指示，没有规定统一响应时间或成功率阈值，因此 SLA 必须由组织自行定义。[依据：Revenera 2026 R1，Maximum Client Connections to License Server]

5.4 测试 B：vendor daemon 稳态连接容量

目标

验证 vendor daemon 在大量 job connections 持续存在时的容量、稳定性和接近限制时的行为。

方法

分批启动能保持 license job connection 的受控测试 workload；
每一批达到稳定状态后，采集 vendor daemon FD 数量、连接数、lmstat 状态、debug log 和客户端错误；
逐步提高稳定连接量，不要直接跳到理论最大值；
在 10,000 连接以内验证常规生产目标；
若计划超过 10,000，必须把该测试升级为 producer 参与或确认的压力测试，因为这是 Revenera给出的前提；
不应把接近 30,000 当作普通生产目标。

[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

官方失败信号

当 vendor daemon 的最大 job 数量达到时：

典型连接错误为 LM_CANTCONNECT (-15)；
debug log 可能显示 server 因文件描述符耗尽而不能处理更多并发客户端。

[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

当明确达到 MAX_CONNECTIONS 时：

vendor daemon 断开后续连接；
客户端返回 -237 (LM_VD_MAX_CLIENTS_REACHED)；
版本低于 11.16.3 的旧客户端可能返回 -140 (LM_BADCOMMAND)；
vendor daemon 为 lmreread、lmstat 等重要工具保留 30 个连接。

[来源：Revenera 2026 R1，MAX_CONNECTIONS]

5.5 测试 C：持续稳定性与回落

达到目标容量后，应保持一段内部定义的稳定运行窗口，再逐步释放测试客户端，观察：

新 checkout 是否持续成功；
debug log 是否出现连接上限或 daemon 异常；
FD 使用量是否随连接释放而下降；
socket 状态是否回落；
lmstat -lm 和 lmstat -vd 是否持续显示 daemon 正常。

Revenera明确描述了 lmgrd 过载时 socket 堆积会在客户端活动降低后消退；lmstat 可监控 license manager 和 vendor daemon 状态。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；lmstat]

官方文档没有规定测试必须持续多少分钟或小时。因此测试时长应根据组织的工作负载持续时间、峰值周期和风险要求设定，不能写成 Revenera固定标准。

5.6 测试 D：监控工具自身的影响

在相同业务负载下分别测试：

不运行全量 lmstat -a；
按计划周期运行 lmstat -a；
使用 lmstat -S vendor、-f feature 或 --no-user-info 缩小查询范围。

Revenera说明 lmstat -a 是潜在高开销命令，活跃用户很多时会产生大量网络活动；-S、-f、--no-user-info 和 -t 可用于限定范围或连接等待时间。[来源：Revenera 2026 R1，lmstat]

这个对比测试可用于判断监控是否显著占用连接和网络资源，但 Revenera没有提供“每多少秒执行一次”的固定安全周期，不能捏造统一轮询频率。

6. 如何根据测试结果设置并发连接数

6.1 调整决策树

出现容量问题
   │
   ├─ 客户端 -16，lmgrd 日志最大连接告警，ESTABLISHED/CLOSED_WAIT 堆积
   │      └─ 判断为 lmgrd 入口洪峰问题
   │
   ├─ 客户端 -15，日志显示 out of file descriptors
   │      └─ 判断为 vendor daemon/OS FD 容量问题
   │
   ├─ 客户端 -237
   │      └─ 判断为 vendor daemon 达到 MAX_CONNECTIONS
   │
   └─ 旧客户端 -140 且服务端已到 MAX_CONNECTIONS
          └─ 考虑旧客户端兼容表现

以上错误与症状映射来自 Revenera 2026 R1 官方文档。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Error Code Descriptions]

6.2 调整 `lmgrd`：`LM_SERVER_HIGHEST_FD`

原理

LM_SERVER_HIGHEST_FD 限制 lmgrd 的同时客户端连接数；它不影响 vendor daemon。Linux 上最大值和默认值为 1024，Windows 上为 4096，但 Windows 每个 lmgrd job connection 使用四个文件描述符。[来源：Revenera 2026 R1，Environment Variables]

何时降低

如果压测表明，过大的入口并发会让后端 vendor daemon、网络或应用响应显著恶化，可用该参数限制进入 lmgrd 的同时连接规模，作为入口保护。官方只说明该变量用于“limit”，没有给出自动限流算法或推荐降低比例，因此具体值必须由测试确定。[来源：Revenera 2026 R1，Environment Variables]

何时提升

在 Linux 2026 R1 文档中，该变量最大值是 1024，因此不能把它设置为超过官方声明的 Linux 最大值来扩展 lmgrd。若已经使用默认最大值并仍因同一时刻启动洪峰触发 -16，缓解重点应转向降低连接洪峰，例如分批启动、错峰或由 producer 提供可扩展方案，而不是声称可无限提高 LM_SERVER_HIGHEST_FD。[来源：Revenera 2026 R1，Environment Variables；Maximum Client Connections to License Server]

分批启动和错峰属于依据“spike of client connection requests”提出的工程措施，不是 Revenera文档中的具体调度器配置。

6.3 调整 vendor daemon：`MAX_CONNECTIONS`

原理

MAX_CONNECTIONS 是 vendor daemon 的显式连接限制。POSIX 平台实际限制取 MAX_CONNECTIONS 与启动时系统文件描述符能力之间的较小值，并扣除内部预留。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

提升条件

可以考虑提高 MAX_CONNECTIONS 的前提是：

压测确认当前失败是 -237 或明确达到 MAX_CONNECTIONS，而不是 lmgrd 的 -16；
vendor daemon 启动时的 open-file limit 足以支持新的目标值和内部预留；
新目标仍符合性能要求；
总连接计划超过 10,000 时，由 producer 事先完成压力测试；
不把接近 30,000 的最大能力描述当作默认生产建议。

[来源：Revenera 2026 R1，MAX_CONNECTIONS；Maximum Client Connections to License Server]

降低条件

可基于压测主动降低 MAX_CONNECTIONS，将其作为 vendor daemon 的保护边界，避免在更高连接规模下出现不可接受的性能下降。Revenera明确把该参数定义为 vendor daemon 最大连接限制，但没有给出自动计算公式或推荐利用率，因此降低值必须来自实际压力测试结果。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

配置形式

官方页面给出的选项名与参数形式为：

MAX_CONNECTIONS num_conn

范围为 31 到 1,000,000。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

修改前应备份 options file。是否可以通过特定 vendor daemon 的 lmreread 无中断应用、以及 Synopsys snpslmd 对该变更的具体行为，应以软件生产商文档为准；Revenera该页面没有明确承诺所有 producer 实现都可热变更，所以本文不作此保证。

6.4 提高 POSIX 文件描述符限制

原理

vendor daemon 启动时只调用一次 getrlimit()。因此已经运行的进程不会因为管理员随后在另一个 shell 中执行 ulimit 而自动获得新的连接容量。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

设置原则

Revenera要求 Linux/Unix 的 file descriptor ulimit 至少达到预计的 vendor daemon 最大 job connections 数。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

工程上还应考虑内部预留及日志、监听 socket 等非业务 FD，但官方只明确说会扣除 certainReserve，没有公布具体余量，因此不能给出一个声称为官方标准的固定加成比例。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

systemd

Revenera 2026 R1 提供了 Linux toolkit 中的 demo.sh 和 demo.service 示例，并说明可以通过 systemd 启动脚本配置 license server daemon 的 file descriptor ulimit，同时建议 system service 使用非特权用户运行。[来源：Revenera 2026 R1，Systemd Config File]

常见 Linux systemd 实现形式如下，但 LimitNOFILE 的具体值必须由容量测试决定：

[Service]
LimitNOFILE=<tested_value>

该具体 directive 是 Linux systemd 的工程实现示例；Revenera页面说明的是通过 systemd 启动配置 file descriptor ulimit，并未在页面正文中指定统一的 LimitNOFILE 数值。[依据：Revenera 2026 R1，Systemd Config File；Maximum Client Connections to License Server]

变更后必须重新启动 vendor daemon，才能让启动时的 getrlimit() 读取新限制。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

6.5 调整顺序

推荐采用以下顺序，避免把不同层级问题混淆：

先确认错误层级：-16 更指向 lmgrd 入口洪峰；-15 结合 out-of-FD 日志更指向 vendor daemon/FD；-237 明确表示 vendor daemon 最大连接已达到。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Error Code Descriptions]
检查运行态 FD 限制：确认 vendor daemon 启动时实际继承的 open-file limit。[来源：Revenera 2026 R1，MAX_CONNECTIONS]
检查 MAX_CONNECTIONS：判断是显式参数先触顶，还是系统 FD 先触顶。[来源：Revenera 2026 R1，MAX_CONNECTIONS]
先做压测再改值：超过 10,000 连接必须满足 producer 预压测前提。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]
重新启动并复测：POSIX getrlimit() 只在 vendor daemon 启动时调用一次。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

7. 容量测试结果如何转化为生产配置

7.1 定义三个测试点

建议从测试结果中提取三个工程指标：

稳定容量点：持续运行时无连接错误、无上限告警，性能满足内部 SLA；
退化点：连接仍成功，但响应时间、CPU、socket 堆积或管理查询开销开始明显恶化；
失败点：出现 -16、-15、-237、旧客户端 -140 或官方描述的 debug log 告警。

错误和日志信号来自 Revenera官方文档；“稳定点/退化点/失败点”是工程归纳方法。[依据：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS]

7.2 选择生产上限

生产上限不应直接等于首次失败点。应低于已验证的退化点，并覆盖正常峰值、计划增长和监控/管理连接。Revenera没有给出统一安全系数，因此不能写成固定的 70%、80% 或 90% 官方规则。[依据：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS]

同时必须遵守以下官方边界：

vendor daemon 通用最佳实践不超过 10,000 jobs；
超过 10,000 时须满足简单 license model、强硬件和 producer 预先压力测试；
POSIX file descriptor ulimit 至少覆盖预期最大 job connections；
vendor daemon 还会为重要 utilities 保留 30 个连接。

[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS]

7.3 示例决策表

测试结果	配置动作	原理与依据
`lmgrd` 在启动洪峰中出现 `-16`，vendor 稳态连接不高	降低同一时间窗口的启动并发；核查 `LM_SERVER_HIGHEST_FD` 是否被人为设低	`-16` 是 `lmgrd` 同时连接超限的典型表现；该变量只限制 `lmgrd`
vendor 返回 `-237`，FD 仍有充足空间	在生产商支持和压测通过前提下提高 `MAX_CONNECTIONS`	`-237` 表示 vendor daemon 达到最大连接数
vendor 出现 `-15` 且日志显示 out of file descriptors	提高启动时 FD limit；重启后复测	POSIX 实际容量受 `getrlimit()` 结果约束
`MAX_CONNECTIONS` 很高，但进程 soft nofile 很低	优先提高进程 FD，不应只继续提高 `MAX_CONNECTIONS`	实际限制取两者较小值并扣除预留
10,000 以上开始性能退化	把生产目标控制在已验证范围；进一步扩展需 producer 压测	官方最佳实践为不超过 10,000
高频 `lmstat -a` 时性能恶化	降低全量查询频率或缩小查询范围	官方指出 `-a` 可能昂贵且产生大量网络活动

[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Environment Variables；lmstat]

8. 验证与回滚

8.1 变更前记录

至少保存：

license file 与 options file；
当前 LM_SERVER_HIGHEST_FD；
当前 MAX_CONNECTIONS；
lmgrd 与 vendor daemon 版本；
vendor daemon 运行进程的 open-file limits；
基线 lmstat -lm、lmstat -vd 输出；
debug log；
基线 socket 与 FD 数量。

这些记录用于把变更前后状态与官方限制模型对应起来。[依据：Revenera 2026 R1，Environment Variables；MAX_CONNECTIONS；lmstat]

8.2 变更后验证

确认 lmgrd、vendor daemon 均正常运行：

lmutil lmstat -lm -c port@host
lmutil lmstat -vd -c port@host

lmstat 官方支持 -lm 和 -vd 状态检查。[来源：Revenera 2026 R1，lmstat]

确认 vendor daemon 新进程继承了预期 open-file limit。该验证是必要的，因为 getrlimit() 只在启动时调用一次。[来源：Revenera 2026 R1，MAX_CONNECTIONS]
重跑相同 workload 和连接洪峰测试，确保测试变量一致。
搜索 -15、-16、-237、旧客户端 -140 及最大连接、文件描述符相关日志。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Error Code Descriptions]
确认管理工具仍可连接；vendor daemon 官方保留 30 个 utility connections，但不应把这作为业务连接超限的长期运行策略。[来源：Revenera 2026 R1，MAX_CONNECTIONS]

8.3 回滚

如果新设置导致性能下降或不稳定：

恢复备份的 options file 或环境变量配置；
恢复原有 file descriptor 配置；
重启 license server，使 vendor daemon 在启动时重新读取系统限制；
使用 lmstat -lm、lmstat -vd 和基线测试验证恢复。

重启后 server 不保留之前的状态信息，这是 Revenera说明的设计特征；具体 EDA 客户端如何重连必须依据软件生产商文档评估。[来源：Revenera 2026 R1，License Server Manager “lmgrd”]

9. 对 Synopsys `snpslmd` 95% 告警的应用

对于日志：

(snpslmd) WARNING: Server has hit 95% of the max connections limit

可以可靠判断它由 vendor daemon snpslmd 发出，而不是 lmgrd 发出；但仅凭这一行不能确定到底是 MAX_CONNECTIONS 边界还是系统文件描述符边界，也不能把它解释为某个 feature 的 license 使用率达到 95%。这是基于 Revenera对 vendor daemon 连接限制和两层架构的解释。[依据：Revenera 2026 R1，MAX_CONNECTIONS；Maximum Client Connections to License Server]

应按以下顺序取证：

# 1. 确认进程
pgrep -a lmgrd
pgrep -a snpslmd

# 2. 查看 snpslmd 运行态文件描述符限制
SNPS_PID=$(pgrep -o snpslmd)
grep -i 'open files' /proc/${SNPS_PID}/limits

# 3. 查看当前 FD 数量
find /proc/${SNPS_PID}/fd -mindepth 1 -maxdepth 1 | wc -l

# 4. 查找 options file 中的 MAX_CONNECTIONS
grep -RniE '^[[:space:]]*MAX_CONNECTIONS' /path/to/license/config

# 5. 查看 daemon 状态
lmutil lmstat -lm -c port@host
lmutil lmstat -vd -c port@host

# 6. 检查连接状态
ss -Hantp | grep snpslmd

这些 Linux 命令是工程取证手段；判断依据来自官方：vendor daemon 实际限制受 MAX_CONNECTIONS 和启动时 open-file system limit 共同约束，lmstat 可查看 manager/vendor daemon 状态。[来源：Revenera 2026 R1，MAX_CONNECTIONS；lmstat]

10. 官方文档未给出的内容

为避免把经验写成官方事实，以下内容在本文引用的 Revenera 2026 R1 页面中没有统一规定：

每 1,000 个连接所需 CPU、内存、磁盘或网络带宽；
一个 Synopsys EDA job 对应多少个 snpslmd TCP connections；
snpslmd 应设置成多少 MAX_CONNECTIONS；
统一的 LimitNOFILE 推荐值；
固定的压力测试持续时间；
固定安全系数或固定告警百分比；
lmstat 的统一安全轮询周期；
Synopsys vendor daemon 是否支持对 MAX_CONNECTIONS 无中断热变更；
超过 10,000 连接时 Synopsys 对具体 SCL 版本的支持边界。

这些事项必须通过实际测试和 Synopsys 对相应 SCL/snpslmd 版本的官方支持资料确认。Revenera通用文档只明确要求，超过 10,000 连接应由 producer 预先完成压力测试。[来源：Revenera 2026 R1，Maximum Client Connections to License Server]

11. 官方来源

Maximum Client Connections to License Server
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Maximum_Client_Connections_to_License_Server.htm
MAX_CONNECTIONS
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/MAX_CONNECTIONS.htm
Environment Variables（LM_SERVER_HIGHEST_FD、TCP_NODELAY、FNP_IP_ENV）
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Environment_Variables.htm
License Server Manager “lmgrd”
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/fla_lmgrd.htm
lmstat
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/lmstat.htm
Systemd Config File
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Systemd_Config_File.htm
Manual Start
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Manual_Start.htm
Starting the License Server Manager on UNIX Platforms
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Starting_the_License_Server_Manager_on_UNIX_Platforms.htm
Error Code Descriptions
Revenera FlexNet Publisher 2026 R1（11.19.10）License Administration Guide
https://docs.revenera.com/fnp/2026r1/LicAdmin_Guide/Content/helplibrary/Error_Code_Descriptions.htm

12. 最终建议

对于生产环境，不应通过单独提高一个参数解决并发问题。应分别验证 lmgrd 的瞬时入口洪峰和 vendor daemon 的稳态连接容量，然后结合：

LM_SERVER_HIGHEST_FD；
MAX_CONNECTIONS；
vendor daemon 启动时的 POSIX open-file limit；
10,000 jobs 的官方最佳实践边界；
-16、-15、-237、旧客户端 -140；
debug log 与 socket 状态；
producer 对超过 10,000 连接的压力测试结论；

确定生产上限。[来源：Revenera 2026 R1，Maximum Client Connections to License Server；MAX_CONNECTIONS；Environment Variables]

最关键的原则是：

lmgrd 的连接洪峰容量、vendor daemon 的稳定连接容量、POSIX 文件描述符容量和 feature license 数量是不同维度，必须分别测量、分别设限、联合验证。

该结论是对 Revenera 2026 R1 两层架构、连接限制、文件描述符机制和管理工具行为的综合归纳。[依据：本文列出的 Revenera 2026 R1 官方来源]

FlexNet Publisher 2026 R1 License Server 资源容量规划、并发连接测试与参数调优指南

FlexNet Publisher 2026 R1 License Server 资源容量规划、并发连接测试与参数调优指南

1. 核心结论

2. 架构与连接原理

2.1 License Server Manager 的职责

2.2 为什么 lmgrd 与 vendor daemon 的容量不能混为一谈

2.3 restart 后的状态特征

3. 容量规划对象

3.1 lmgrd 同时连接容量

3.2 vendor daemon 总连接容量

3.3 POSIX 文件描述符容量

3.4 MAX_CONNECTIONS

4. 需要规划的资源维度

4.1 官方明确关联的资源

4.2 连接数不等同于许可证使用数

5. 如何测试资源容量

5.1 测试前提

5.2 基线采集

5.2.1 License 服务视图

5.2.2 POSIX 进程资源视图

5.2.3 Socket 状态视图

5.3 测试 A：lmgrd 瞬时连接洪峰

目标

方法

官方失败信号

通过标准建议

5.4 测试 B：vendor daemon 稳态连接容量

目标

方法

官方失败信号

5.5 测试 C：持续稳定性与回落

5.6 测试 D：监控工具自身的影响

6. 如何根据测试结果设置并发连接数

6.1 调整决策树

6.2 调整 lmgrd：LM_SERVER_HIGHEST_FD

原理

何时降低

何时提升

6.3 调整 vendor daemon：MAX_CONNECTIONS

原理

提升条件

降低条件

配置形式

6.4 提高 POSIX 文件描述符限制

原理

设置原则

systemd

6.5 调整顺序

7. 容量测试结果如何转化为生产配置

7.1 定义三个测试点

7.2 选择生产上限

7.3 示例决策表

8. 验证与回滚

8.1 变更前记录

8.2 变更后验证

8.3 回滚

9. 对 Synopsys snpslmd 95% 告警的应用

10. 官方文档未给出的内容

11. 官方来源

12. 最终建议

Need IC Infra Help?

IC 基础架构咨询

Support the Creator

Search Posts

搜索文章

2.2 为什么 `lmgrd` 与 vendor daemon 的容量不能混为一谈

3.1 `lmgrd` 同时连接容量

3.4 `MAX_CONNECTIONS`

5.3 测试 A：`lmgrd` 瞬时连接洪峰

6.2 调整 `lmgrd`：`LM_SERVER_HIGHEST_FD`

6.3 调整 vendor daemon：`MAX_CONNECTIONS`

9. 对 Synopsys `snpslmd` 95% 告警的应用