LS-DYNA许可证不够用？从监控调度到排查优化实战指南

上午十点，群里又有人喊了一声“许可证不够了”。紧接着三个项目组同时提交LS-DYNA碰撞分析作业，许可证池瞬间见底，后面排队的人不是报错退出，就是对着“license checkout failed”干瞪眼。我登录许可证服务器一看，前一晚有两个作业跑完后进程没清干净，96份浮动许可证里有30份被占着根本没干活，真正在跑计算的不到一半。

这种场景在不少做CAE仿真的单位里太常见了。大家都把“许可证不足”挂在嘴边，以为是预算问题、是老板不肯多买几份，但很多时候真正的问题是现有LS-DYNA许可证的使用效率太低。这篇东西适合仿真中心的运维人员、HPC管理员、CAE部门的负责人看，也适合那些每天跟LS-DYNA作业打交道、偶尔被许可证卡脖子的分析工程师。我会从许可证怎么流转讲起，把监控、调度、作业提交、服务器侧调优这些环节逐个拆开，最后给一份可以直接抄作业的排查手册。

1. 先弄清楚LS-DYNA许可证是怎么被“吃”掉的

1.1 许可证服务的底层逻辑

LS-DYNA的浮动许可证，底层用的是FlexNet（早期叫FlexLM）这套管理机制。整个体系里有三个角色：许可证服务器、许可证文件、客户端计算节点。许可证文件里写了两样东西，一是你买了多少份LS-DYNA的授权，二是服务器的主机名和端口。计算节点启动任务时，会向服务器发起一个“checkout”请求，服务器从许可证池里划出一份给这个任务，任务结束以后再“checkin”还回去。

这个过程看起来简单，但有个很关键的细节容易被忽略：客户端checkout到的许可证，和实际的MPI进程、CPU核数、内存是绑在一起的。LS-DYNA的授权通常有两种计量方式，SMP模式按调用核数扣证，MPP模式按MPI进程数扣证。你提交一个16进程的MPP作业，许可证池里就可能一次性划走16个授权。换句话说，一份许可证对应的是“一个可用的计算单元”，而不是“一个用户”。

明白了这个逻辑，再去想优化就有方向了。许可证不够用的时候，要么是池子本身小，要么是池子里有水但放不出来，要么是水被浪费掉了。后两种情况，恰恰是我们能通过管理手段解决的。

1.2 三类最典型的“隐性浪费”场景

第一类浪费是作业跑完后进程残留。作业脚本写得不够干净，或者MPI环境异常退出，导致ls-dyna进程还挂在计算节点上，许可证一直不释放。这个现象在集群上尤其常见，而且很难通过肉眼发现，因为计算节点上进程多了去了，没人会一个个去看哪个是僵尸。

第二类浪费是并行核数虚高。模型明明只有几十万网格，非要提交到32核、64核上去跑。许可证明明是按核数扣的，核数多除了让通信开销变大、计算速度没什么提升甚至变慢之外，还白白多占了几倍的许可证。

第三类浪费是排队和占用时间的错配。有些单位用调度系统但不做许可证联动，作业先在队列里排着，等排到了再开始checkout，如果此时许可证明明不够，作业就卡在初始化阶段，既不退出也不算在跑，挂一块巨大的“隐形隔间”。如果所有人都同时干这种事，许可证池会很快被占满，但实际计算负载可能并不高。

1.3 先给许可证算一笔账：总量与缺口

做优化之前，先要量化现状。最基本的指标是许可证利用率，算法很简单：统计周期内所有许可证被占用的时间之和，除以许可证总数乘以统计周期时长。

举个例子：你有100份许可证，统计一周七天，那么理论总时长是100 × 7 × 24 = 16800许可证小时。如果这一周内累计有8400小时被占用，利用率就是50%。很多单位晒出来的利用率听起来“有50%以上”，实际上远远不到，因为大家只看了工作时段，晚上和周末的闲置全被忽略了。

我建议的统计周期是全天24小时、全周7天，然后把数据拆成工作时段和夜间时段分别看。白天高峰期的峰值占用率如果长期贴着100%，而夜间平均占用率只有10%，那说明问题不是总量不够，而是调度不均。这种情况下盲目加购许可证，买来大概率也是让利用率更难看。

2. 用数据说话：先摸清许可证的真实使用率

2.1 lmstat命令的正确打开方式

FlexNet自带的命令行工具是lmstat，语法很简单，核心参数就一个-c指定许可证文件路径或端口@主机名，再加-a表示输出全部信息。在许可证服务器上执行，能看到三类关键信息：许可证服务器的状态、每个feature的授权总数和当前在用数、每个用户的占用明细。

典型输出长这样：

/lic/admin/flexnet/bin/lmstat -a -c 28000@lic-srv01

Users of LS-DYNA MPP: (Total of 128 licenses issued; Total of 96 licenses in use)

关键要看“Total of ... issued”和“Total of ... in use”这两个数字。前者是全部授权数，后者是当前已经占用的数量。下面还会逐行列出来：哪个用户在哪个主机上占了多少份、从什么时间开始checkout的。

用的时候有个坑，lmstat对服务器输出的解析依赖端口和主机名，如果服务器上有多个网卡，或者DNS解析有问题，命令会卡住不返回。我的习惯是先检查/etc/hosts，确保服务器主机名解析到正确的IP，再检查防火墙有没有把端口放开。

2.2 从日志里挖出用户级消耗明细

lmstat只能看到当前快照，看不出历史趋势，也没法告诉你“谁才是占用大户”。这个问题的答案藏在服务器日志里，FlexNet的vendor daemon会实时记录每次checkout和checkin，文件一般叫ansyslmd.log或者debug.log。

日志里每行都是这样的节奏：时间、动作、用户名、主机名、feature名、占用的数量。直接打开文件看会头大，我建议用文本处理工具把它变成统计报表。先按用户汇总所有checkout记录：

grep -E "CHECKOUT|CHECKIN" /opt/ansys/ansyslmd_2025.log \ | awk '{print $1, $2, $3, $4, $5, $6}' \ | sort | uniq -c | sort -nr | head -30

字段顺序可能跟你们日志实际格式有差异，但思路是固定的：先抓动作关键字，再提取关键列，排序后看排名。这样能非常快地发现，原来一个叫Zhang的用户经常同时占着20份许可证，一占就是大半天。

再进一步，可以用时间戳把checkout和checkin配对，算出单个用户平均占用时长。占用时长特别长、但计算负载不高的用户，大概率就是在浪费许可证。别急着找人家谈话，先把数据整理出来，拿着表格沟通，比口头说“你少占点”有说服力得多。

2.3 一张表拉通利用率、峰值、空闲率

围绕许可证做周报，我一般记录以下指标：

这五个指标我每周雷打不动统计一遍。别小看这张表，它能直接回答两个问题：你的许可证到底缺不缺，缺的是总量还是峰值。绝大部分单位的真实情况是总量够用、峰值挤兑。既然是挤兑，用调度手段错峰，比花钱加购有意义多了。

3. 从调度系统下手：让作业在许可证可用时才启动

3.1 为什么调度系统必须“感知”许可证

很多单位用Slurm或者PBS管理作业，但调度系统对许可证一无所知。作业排队的时候，调度系统只看CPU核数、内存、GPU这些计算资源，许可证的数量不在它的考虑范围内。作业一旦获得计算资源开始执行，应用层才发现许可证不够，于是卡住、重试、把节点资源白白占着。

这个问题的本质是，调度系统和许可证服务器决策依据割裂了。你想让作业真正顺利跑起来，就必须让其中一个环节提前判断许可证有没有。最优雅的方案是让调度系统直接感知许可证，不行就用作业前置检查脚本兜底，我两种都试过，实际效果都很好，关键看你们集群的情况。

3.2 Slurm、PBS、LSF的许可证联动配置

如果你的调度系统是Slurm，比较干净的方案是先登记许可证资源，再让作业按需申请。需要在slurm.conf里声明License：

Licenses=lsdyna@lic-srv01

然后在作业提交脚本里加上：

#SBATCH --licenses=lsdyna:1

这样Slurm就会把“lsdyna许可证”当作一种资源来调度：许可证被占满时，作业不会启动，而会留在队列里等待，不会出现“节点已经分配、应用起不来”的尴尬状态。

PBS系的商业发行版和LSF的License Scheduler也提供类似机制，原理是一样的：调度系统维护一个许可证资源池，作业申请与释放都和池子联动。配置语法以你们自己的调度器文档为准，但思路固定不变——让作业启动的条件同时包含“计算资源可用”和“许可证可用”。

如果你的调度器原生不支持许可证，那就用前置检查脚本。在作业执行的第一行，轮询检查许可证是否够用，不够就sleep等待，超时再退出：

#!/bin/bash #SBATCH -n 16 #SBATCH --mem=64G for i in $(seq 1 36); do free=$(lmstat -a -c 28000@lic-srv01 \ | grep "Users of LS-DYNA MPP" \ | sed -n 's/.*Total of \([0-9]*\) licenses in use.*/\1/p') if [ "$free" -lt 16 ]; then echo "$(date) [WARN] license不足，等待中..." sleep 300 else break fi done # 真正开始运行 ls-dyna_mpp i=job.k -np 16

这段脚本的逻辑很简单：每隔5分钟看一次空闲许可证数，够16份就跳出循环，不够就继续等，等满3个小时还没等到就直接退出，避免像幽灵一样挂在节点上占着资源。实测下来这种方式对中小规模集群非常稳。

3.3 排队策略：让高优先级项目先拿到许可证

调度联动解决了“作业启动时许可证不够”的问题，但还解决不了“重要项目被普通人抢走许可证”的问题。这时候需要做优先级管理。

在调度层面，可以用fairshare或者QOS给不同项目组设定优先级，大项目、紧急项目用高优先级队列，日常验证用低优先级队列。控制逻辑是：低优先级作业在许可证紧张时，宁可排在队列里，也不能去占用额度。

在FlexNet层面，还有更精细的选项文件控制，这个后面单独讲。这里先记住一个基本原则：许可证调度不是“谁先提交谁先得”，而是“根据业务价值排队”。没有这层设计，许可证池就是个公共草场，谁都能挤进来薅一把，最后谁的项目都做不快。

4. 从作业和模型侧省下每一份许可证

4.1 并行核数不是越大越省时间

不少工程师有个误区：核数越多，算得越快。这个想法在LS-DYNA上要打问号。LS-DYNA的显式求解算是强扩展性不错，但通信开销同样存在。网格规模不变时，进程数翻倍，计算时间并不会跟着减半，反而可能因为进程间数据交换变多，导致加速比明显下降。

更重要的是，许可证是按核数或者MPI进程数来扣的。一个32核作业消耗的许可证，是8核作业的4倍。如果8核跑3小时能出结果，32核跑1小时出结果，看起来很美好，但许可证消耗比是4:3，而且实际跑出来的加速比往往连2倍都到不了。也就是说，多花了4倍的许可证，时间只省了2小时，整体效率反而亏了。

我遇到过一个典型案例：一个只有30万网格的安全气囊模型，用64核去跑，运行时间基本没降，但许可证一下占掉64份，整个部门的其他人都没法提交作业了。查完之后把作业改成16核，模型本身不受影响，许可证压力瞬间缓解。

4.2 多大的模型用多少个核才不浪费

我自己的经验值供参考：单模型规模在50万网格以下的，8到16核足够；100万到300万网格，16到32核是甜点区间；500万网格以上，才需要考虑64核以上。这个经验值会因为接触算法、时间步长、单元类型不同而有浮动，但可以作为默认值的参考。

更严谨的做法是做一个“强扩展性测试”：固定模型不变，分别用8、16、32、64核跑一遍，记录加速比和单步计算耗时。你会发现当核数增加到某个点之后，再往上加，加速比曲线就平了。那个拐点，就是你这类模型的最佳并行规模。做完一次测试，以后同类型模型直接按这个标准提交，许可证消耗能精准卡在合理线上。

4.3 批量提交与并发上限控制

除了单作业核数，还要管住并发作业总量。仿真部门经常出现这种情况：同一组人同时提交20个相同模型的小作业，每个作业占8核，加起来160核许可证不够用，但每个作业其实完全没必要同一时刻跑，错开两批提交，10个10个跑，总运行时间和许可证峰值占用率立刻好看了不少。

调度系统上可以做并发限制。Slurm里可以用Array任务的MaxArraySize控制一批任务同时跑的数量，PBS系统可以在地上层封装一层提交网关，把大并发请求改造成排队小批量执行。这个操作不改变作业本身，只改变提交时机，效果却非常直接：许可证峰值消耗可以被压得很平，而总体计算吞吐量根本不降。

5. 服务器侧调优：把许可证池的“水龙头”拧稳

5.1 网络时延与防火墙：顺手解决“取证慢”

许可证服务器和计算节点之间的通信质量，直接影响作业启动速度。如果每次checkout要等几十秒，多半不是服务器性能问题，而是网络或DNS解析的问题。

几个排查点很有价值：第一，许可证服务器是否配置了多网卡或虚拟IP，计算节点能否稳定访问到它；第二，DNS反向解析是否正常，FlexNet在记录日志时会反向解析客户端主机名，如果解析超时，整个checkout流程会被拖慢；第三，防火墙是否只放行了TCP端口而忽略了UDP，FlexNet实际会用不同端口做心跳和状态查询，端口没放全会表现成“偶尔能取到证、偶尔取不到”。

我比较推荐的做法是，在计算节点的/etc/hosts里把许可证服务器的主机名和IP写死，跳过DNS这一步。配置简单，却能让checkout时间从“肉眼可见的延迟”降到“秒回”，这些小地方对用户体验提升很明显。

5.2 用FlexLM选项文件做预留、分组与配额

FlexNet的选项文件（*.opt）是精细化控制许可证分配的核心工具，很多管理员都不知道有这个东西。在许可证服务器目录下建一个选项文件，在lic文件的VENDOR行里加一行OPTIONS=路径指过去就行，灵活的分配规则都在这里定义。

比如你想给重点项目预留8份LS-DYNA MPP许可证，万一平时被别人抢占了，大项目来了也拿不到配额，可以在选项文件里写：

RESERVE 8 LS-DYNA_MPP GROUP key_project

GROUP成员就是从重点项目共享存储目录下提交作业的那些用户。这样配置以后，不管白天怎么挤，这个组永远保有8份许可证。

还可以用EXCLUDE限制个别用户的占用上限，或者用HOST_GROUP把许可证限定在指定计算节点上。这些规则写起来不难，但要想清楚业务模型再动手，规则太细反而会让服务器在分配许可证时频繁做匹配运算，影响响应速度。我见过一个单位把选项文件写成了一百多行的“不等式”，结果每次checkout都有1秒延迟，得不偿失。

5.3 冗余部署与故障转移

许可证服务器如果挂了，整个仿真部门都要停摆。FlexNet支持冗余服务器模式，最常见的是三台服务器组成一个冗余组，使用一份BEAT三节点容错机制。正常工作时刻只有一台主服务器在服务，另外两台做热备，主服务器宕机时自动拉起。

这种部署对许可证文件有要求，lic文件里需要写入三台服务器的hostid，配置时务必三台机器时间保持严格同步。冗余模式能帮你在硬件故障时不至于“全军覆没”，但也不是银弹，切换期间已checkout的许可证可能会有一小部分需要重新获取，这个情况要在本地运维手册里写清楚，别等出了事再让用户猜。

5.4 日志维护：别让debug.log把磁盘撑爆

FlexNet的日志有无限增长的毛病，尤其是debug.log，跑几个月轻松上GB。磁盘被日志撑满以后，许可证服务器会工作异常，表现成“有证但取不出来”，复盘时查来查去发现罪魁祸首是/opt目录满了，这种事故太憋屈了。

用logrotate按月切割日志，保留6个月份即可。同时把日志级别调低，日常运行不需要debug级输出，只有排查故障时才临时开启。日志维护这种活没多少技术含量，但要写进巡检清单，不然一定会在最忙的节点出幺蛾子。

6. 高频报错排查：许可证问题速查手册

6.1 高频报错与解决方案速查表

以上都是实战里最高频的问题。遇到报错不要一上来就怀疑许可证总量，先把上面列的几个检查完，大概率能定位。

6.2 时钟偏移：一个常被忽略的“隐形杀手”

FlexNet对时间敏感，客户端和服务器之间的时间偏差一旦超过阈值，checkout会直接失败。这个阈值通常很小，默认几秒级。但实际上很多计算节点的时钟根本不准，虚拟化环境尤其常见，关机再开机之后时间能差出去几分钟。

解决办法是统一走NTP。在许可证服务器和所有计算节点上配置同一个NTP源，并设置定期同步任务。这块配置好了，能避免大量“灵异现象”——作业时好时坏，用户换台机器就正常了，经常就是时间同步不稳定导致的。

6.3 许可证获取失败的标准排查流程

每次遇到“许可证取不到”的问题，我按固定顺序检查，这套流程救了很多次急。

第一，在服务器上执行lmstat -a，看feature总数和当前在用数。如果当前在用数已经等于总数，说明是资源耗尽，去看谁占着。第二，在计算节点上执行lmstat -a，确认节点能连上服务器，如果连不上，查网络和DNS。第三，检查系统时间是否同步，这个用date命令对比一下就能出来。第四，看服务器日志，搜索报错时刻附近的记录，重点看是否有“TIMEOUT”“DENIED”“UNSUPPORTED”这些关键字。第五，检查作业脚本提交时指定的feature名、并行核数是不是符合许可证约束。

这套流程走完，大部分问题都能在十分钟之内定位。真正的难点不是技术，而是流程没有固化下来，每次出问题都像第一次，人仰马翻。把流程写成文档，贴到团队wiki上，后面的人遇到类似问题能少走很多弯路。

7. 一些从实际管理里得到的琐碎体会

做了这么多年的许可证管理，最大的感受是，许可证优化里面七成是管理问题，三成才是技术问题。技术手段再漂亮，如果用户提交作业的习惯不改，高峰挤兑和乱用核数的情况还是会反复出现。建议每季度做一次许可证使用数据复盘，把TOP占用用户、峰值时段、浪费场景这些数据直接放进例会给团队看，效果比发通知好用得多。

还有一个小技巧想分享给同行：如果你有多个License feature可以混用，比如SMP和MPP都有授权，不妨在下班之后把默认提交模式切到配额更宽裕的那个，利用夜间闲置资源。这种做法不需要额外花钱，就能把夜间字段的利用率拉起来。许可证优化的本质不是抠门，而是让每一份已经花钱买来的资源，都在它该发挥作用的时间段里真正转起来。