Coverity许可证并发怎么查看，还有许可证并发不足的时候要怎么排查，不能光看还能不能登录，或者扫描还能不能跑。Coverity在不同的部署和授权方式下，可能会受到许可证服务器、授权feature、团队成员数量、代码规模，或者扫描任务占用这些方面的限制。实际排查的时候，要先弄清楚碰上的情况，到底是浮动许可证被别人占满了，还是许可证路径、服务器连接、授权项目没有对上，才导致失败，这样才不会一开始就错怪到并发不够上面去。

　　一、Coverity许可证并发怎么查看

　　Coverity的许可证并发，一般要去许可证服务器那边查看，不能只在客户端这一头盯着报错。尤其是在企业环境里，很多开发机、构建机，还有CI流水线，都可能同时去访问同一套授权，客户端只能看到自己拿不到许可证，却看不到是谁正在占用。

　　1、确认许可证服务器的地址

　　先要检查【SNPSLMD_LICENSE_FILE】或者【LM_LICENSE_FILE】这两个环境变量，看看有没有配置正确。

　　常见的写法大概是“端口 服务器名”，比如27020 license-server。要是本机的环境变量还指着旧服务器、测试服务器，或者端口写错了，就会出现好像没有许可证的假象。这时候不是并发真的不够，而是客户端压根没有连到正确的许可证服务上。

　　2、用lmstat查看许可证占用情况

　　进入许可证工具所在的目录以后，可以执行lmutil lmstat-a-c端口 服务器，去查看当前许可证的状态。

　　输出里面一般会显示某个feature一共有多少个授权，当前正在使用多少个，比如总共issued了多少license，现在in use的有多少。这里的in use数量，才是判断并发是不是被占满的关键。如果当前使用数已经跟总数一样了，那新任务再启动的时候，就有可能拿不到许可证。

　　3、查看具体是谁在占用，哪台机器在占用

　　接着往下翻lmstat的输出，去找用户名、主机名、启动时间，还有进程信息。

　　这一步能看出来许可证到底被谁占着。比如某个CI节点正在跑分析任务，那算是正常占用；但要是某台机器上已经没有构建任务了，却还长时间占着许可证不放，那就要怀疑是不是进程残留在那里，或者客户端是异常退出的，又或者许可证没有被及时收回去。排查的时候不能光看数量，还要盯一下占用的来源。

　　二、Coverity许可证并发不足怎么排查

　　许可证并发不足，经常发生在自动化扫描扎堆跑起来的时候。开发人员白天手动分析，晚上CI全量扫描，再加上多个分支同时触发任务，都会让许可证在某一小段时间里被集中占满。排查的时候，要分清到底是授权真的不够用了，还是任务调度安排得不合理。

　　1、判断是不是真的碰到了上限

　　把Total licenses issued和Total licenses in use放在一起对比，看当前的占用是不是已经满了。

　　如果总数是5，当前占用也是5，再想启动新的Coverity分析就失败，这个比较像是并发不足的表现。要是当前占用并没有满，却照样报许可证错误，那就得转去查许可证的路径、feature名称、版本能不能对上，还有服务器连接有没有问题，不要再照着并发不足的路子往下硬查。

　　2、检查CI流水线是不是在抢许可证

　　去看一下Jenkins、GitLab CI，或者其他流水线平台里面，Coverity扫描任务是怎么设的并发。

　　不少团队会让好几个不同的项目，在同一个时间点去跑cov-build、cov-analyze，或者提交缺陷任务。单个任务看着没事，可几十个分支一起被触发，就会一下子把许可证占满。可以考虑给Coverity扫描阶段加上排队规则，或者把全量扫描挪到低谷时段去跑，日常分支只跑必要范围的分析。

　　3、排查异常的占用和残留的进程

　　要是在lmstat里面，发现某个用户或者某台主机的占用时间明显偏长，不太正常，那就要回到对应的那台机器上，去查Coverity相关的进程。

　　重点看cov-build、cov-analyze、cov-commit-defects这些命令是不是还在跑。如果任务已经失败了，进程却没有自己退出，许可证就可能一直被占着。处理之前，先要确认这个任务还有没有保留的价值，不要随手就杀掉还在跑的正式扫描，不然可能会把分析结果弄断。

　　三、Coverity许可证使用怎么优化

　　并发不足这个事，不一定每次都要靠增加授权去解决。Coverity这类跟构建、分析和提交缺陷绑得很紧的工具，任务设计要是不合理，会明显放大许可证的压力。把扫描的策略理顺，很多时候比单纯扩容来得更直接。

　　1、把全量扫描和日常扫描分开

　　全量扫描会占用很长时间，比较适合放在一个固定的时间窗口里执行；日常分支可以根据项目情况，去做增量分析、关键模块分析，或者合并前的检查。

　　如果每次提交都拉起一套完整的Coverity流程，许可证很容易被零碎的小任务挤满。特别是大型C/C++项目，构建捕获和静态分析都比较耗时，更需要把全量任务和日常任务拆开来安排。

　　2、减少重复和无效的扫描

　　检查构建脚本、扫描脚本和流水线配置，确认同一份代码没有被翻来覆去地分析。

　　有些流水线在编译阶段跑一次捕获，到了质量门禁阶段又重新跑一次分析，失败了还会被自动反复重试。这样不光浪费时间，也会一直占着许可证不放。建议给失败重试设一个次数上限，再把扫描入口收拢到固定的脚本里面，避免不同项目各写一套逻辑。

　　3、建立许可证占用记录

　　要是并发不足的情况经常出现，可以定时把lmstat的输出保存下来，记下每天的高峰时段、占用项目，还有占用机器。

　　这些记录能帮着判断问题到底出在哪儿。如果每天固定时间被夜间任务打满，那就去调整调度；如果某个项目长期占用时间过长，就去优化分析配置；如果整体高峰一直存在，再评估是不是需要增加授权。没有记录的时候，只靠用户零零散散的反馈，很容易把偶然出现的问题，当成长时间的老毛病。

　　总结

　　Coverity许可证并发怎么查看，许可证并发不足怎么排查，关键是先要确认许可证服务器和授权类型，再通过lmstat去查看总数、占用数，还有占用的用户和主机。发现并发不足的时候，不要一下子就认定是授权数量不够，要接着去检查CI并发、残留进程、重复扫描、许可证路径和feature匹配这些方面。把扫描任务排上队，全量扫描和日常分析错开，再配合占用记录去判断趋势，许可证资源才更容易用得平稳。