行业引领：LS-DYNA 许可管理新标准，规范行业发展

周五下午四点，碰撞安全组过来说整车正面碰撞排了两个小时还没跑上。你打开 LSTC License Manager 一看，池子里 60 个核显示占用 52 个。

按理说还剩 8 个，不该排队。但队列里就是卡着不动。

这个现象在 LS-DYNA 上特别典型，因为它的许可逻辑跟 CAD 软件根本不是一回事。

先说句实在的：这个标题里的"行业引领""新标准"是平台标题的写法，下面我要讲的不是什么标准，就是这些年攒下来的一些做法，能不能被你们采用还得看自己的场景。

根源：LS-DYNA 是按核计费的，不是按人

CATIA、SolidWorks 这类按并发用户数走，一个用户占一个许可，逻辑很简单。LS-DYNA 不是。

它走的是 LSTC 那套许可管理（基于 FLEXlm/FlexNet 那一脉，但用的是 LSTC 自己的客户端和管理工具）。并行分两种：

• SMP（Shared Memory Parallel，共享内存并行）：单机多核，一般只跑单节点
  
• MPP（Massively Parallel Processing，分布式内存并行）：跨节点，靠 MPI 做域分解
  
• 关键在许可消耗规则。​ 按 Ansys 官方 Licensing Guide 的说法，一个跑在 n 核上的 LS-DYNA 计算，消耗 1 个基础 LS-DYNA 许可（dyna）+ (n-1) 个 LS-DYNA HPC 许可（dysmp）。
• 还有一条特别容易踩：标准的 anshpc 和 anshpc_pack（Ansys HPC 包）不能用在 LS-DYNA 上。​ LS-DYNA 有自己的 dysmp 许可，按 8/16/32/64/128/256 这些档位买，可以叠加。我见过公司买了大包 Ansys HPC，兴冲冲去跑 MPP，结果报错，才发现许可类型根本对不上。
• 所以一个 64 核的 MPP 求解任务，一次吃掉 1 个 dyna + 63 个 dysmp。​ 一个高保真整车碰撞几百核同时跑，池子瞬间见底。
• 这就导致了一个调度盲区：许可系统监控的是"核心有没有被 check out"，不判断"这些核心是不是在真算"。
• 求解进程崩了但客户端没退出 → 核心一直挂着
  
• 参数化扫描提交一批，前面还在排队，后面已经把核心预定了
  
• 界面上显示占用，实际零产出
  
• 这些就是僵尸核心。

四个坑

① 把"核数"当"并发用户数"采购

按工程师人数乘个系数来买核。

为什么会踩？因为这是最省事的做法，HR 有人头数。但 LS-DYNA 的消耗跟人没关系 —— 一个工程师提交 64 核任务，Token 消耗是另一个跑 4 核任务的 16 倍。

后果是两头不讨好：小任务随便跑，大任务永远排不上，然后所有人一起喊"不够"，采购再加，加完还是同样的问题。

② 不做作业调度，所有任务一视同仁

谁先提交谁先跑，纯 FIFO。

后果：一个 256 核的整车碰撞把池子吃满，后面十几个 8 核的小模型全堵着。等到下班，大任务还在跑，小任务一个没动。总吞吐没变，但交付时效全乱了。

③ 无视僵尸核心

崩掉的进程、异常退出的作业、卡在 "still running" 的远程任务 —— 这些占着的核不会自己回来。

LS-DYNA 这套其实是给了工具的：lstc_qrun​ 看当前占用（用户、主机、程序、启动时间、进程数），lstc_qkill <host>​ 强制释放某个卡住的许可，lstc_license_count 看剩余数量。

但很多团队从来没用过，或者只有一个人会用，他一休假就没人管了。

④ 服务器侧的网络问题当成"许可证不够"

这个坑很隐蔽。每次 checkout 要等几十秒，多半不是服务器性能问题 —— 是 DNS 反向解析超时。FlexNet 记日志时会反解客户端主机名，解析超时会拖慢整个 checkout 流程。

还有防火墙只放 TCP 没放 UDP，表现就是"偶尔能取到证、偶尔取不到"，比彻底不通还难查。

怎么解：按顺序来

第一层：摸底 —— 先把数据拿出来

• lstc_qrun​ 拉当前占用，看清是谁、哪台机器、跑的 SMP 还是 MPP、多少个 proc
  
• 开 debug log / 报表日志，按 5 分钟粒度聚合成日峰值，取过去 30 天的 P90，不是最大值，更不是月均
  
• 把 SMP 和 MPP 分开统计。这两类任务的并发规律不一样，混在一起看没有意义
  
• 拆到项目 / 部门维度：谁在什么时候用了多少核时
  
• 周期至少 4–8 周，覆盖一个完整项目节奏。只跑一周看到的是假象
  
• 产出一张表：任务类型 / 核数分布 / 日峰值 P90 / 峰值时段 / 排队时长 / 僵尸占用次数。

第二层：零成本优化 —— 不花钱，动配置和规矩

• 清僵尸：定期跑 lstc_qrun，对长时间无进展的用 lstc_qkill 释放。最好写成定时任务
  
• 开排队，别让作业直接失败。FLEXlm 的选项文件里可以配排队和 FIFO/快速队列，拿不到许可就等着，而不是报错退出
  
• 给关键组预留：用 RESERVE​ 给碰撞安全组留一部分核，保证他们永远有得用
  
• 用 GROUP / HOST_GROUP 做隔离：按项目组、按计算节点划分，避免一个大作业吃满全池
  
• MAX 限制单个用户的占用上限，防止一个人提交一堆扫描任务把池子占死
  
• 服务器侧排查：DNS 反向解析、防火墙 TCP+UDP 都放行、多网卡/VIP 的访问稳定性
  
• 冗余部署：许可服务器挂了整个仿真部门停摆。可以按三节点冗余来配，具体形式以厂商支持的方式为准
  
• 有个提醒：选项文件别写太长。​ 规则太细，服务器每次 checkout 都要做匹配运算，我见过写成一百多行的，结果每次取许可都慢一拍，得不偿失。

第三层：采购与调度策略

• 采购基数按 P90 的核数，不按人头
  
• 核数档位要跟你的典型任务对齐。如果大多数任务是 32 核以下，买一堆 256 档的用不上，叠加组合算清楚
  
• 别为一年出现三次的超大任务常备核数，排队等或者临时弹性扩容，都比养一年便宜
  
• 放在续约窗口上调整，期中硬改要补差价，到期日还会乱
  

第四层：才轮到工具

两三套软件、一个集群，LSTC 自带那几个命令加 Excel 够用。

等你有了十几套软件、跨厂区、要每天看、要做自动回收和优先级调度、要按项目分摊成本，再考虑集中监控和调度平台。

但要说清楚：工具不会替你判断"这个任务该不该占 256 核"。​ 这个只能靠人定规矩，规矩错了，报表再漂亮也是错的。

一个真事

有家做汽车零部件的（不点名了），LS-DYNA 池子 96 核，天天喊不够，采购报了要再加 64 核。

我先让他们开了一周日志，跑出来是这样：

• 日峰值 P90：78 核（不是 96，更不是他们以为的"常年打满"）
  
• 但峰值时段集中在工作日上午 9–11 点，夜里 60% 以上的核是空着的
• 僵尸占用：一周里抓到 11 次进程异常退出但许可没释放，平均每次挂 3–5 个小时
  
• 一个 256 核的整车碰撞每周提交一次，那两三个小时里别的任务全堵着
  
• 改了四件事：
• 定时清僵尸（每两小时扫一次 lstc_qrun）
  
• 开排队，失败改成等待
  
• 给两个关键组各 RESERVE 16 核
  
• 那个 256 核的大任务改成走夜间窗口，单独排期
  
• 三个月后：日峰值降到 71 核（峰值被削平了），排队时长从平均 2 小时降到 20 分钟以内，周吞吐反而涨了。
• 采购申请从"加 64 核"改成了"加 16 核"，一年省下来的不只是许可费，还有维护费。
• 那个"不够"从来不是数量问题。96 个核里有相当一部分，是挂在崩掉的进程上、堵在没排队的队列里、睡在夜里的。