Checkmarx SAST扫描慢，很多时候不是单纯“机器不够”，而是把三类问题混在了一起。一类是扫描范围本来就偏大，一类是项目没有用好增量扫描这条提速路径，另一类是队列和并发上限没有按CxManager与CxEngine的边界去配。Checkmarx官方文档写得很清楚，队列里会区分Pending和Queued，其中Pending还在做上传、解压等准备动作，Queued才是已经准备好但在等系统资源；同时，CxManager的并发上限和CxEngine的并发上限也不是同一个配置项。

　　一、Checkmarx SAST扫描很慢

　　真要把时间压下来，先不要急着提并发，更稳的顺序是先收扫描范围，再看增量扫描，再决定要不要改资源上限。因为Checkmarx官方已经明确说明，排除文件和目录会直接缩短扫描时间，而增量扫描本身就是为加快扫描速度设计的。

　　1、先把不该扫的内容排掉。

　　官方文档明确写到，排除文件和文件夹能缩短扫描时间，同时让结果更准确。默认规则本身就会排掉不少测试文件、压缩后文件、备份文件、超大文件和部分第三方目录，所以先确认项目是不是把这些内容都带进去了，往往比一上来改线程更有效。

　　2、把增量扫描用起来，但别乱用。

　　CxSAST的增量扫描会把本次文件的哈希和上一次Full Scan中同名文件的哈希做比较，只扫描变化部分。官方同时提醒，增量扫描只有在项目已经至少完成过一次Full Scan时才可用，而且更适合常规全量扫描超过45分钟的项目。

　　3、先管变化比例，再谈提速收益。

　　官方文档给出的默认阈值是7%。如果变化量超过阈值，增量扫描要么转成Full Scan，要么按配置直接失败；在CxSAST旧版口径里，这个阈值默认也是7，而且可配动作是FAIL或FULL。也就是说，增量扫描不是“永远更快”，而是建立在改动比例可控的前提上。

　　4、队列里先分清是上传慢还是资源不够。

　　如果状态一直停在Pending，更像是上传、解压或准备任务在耗时；如果已经进了Queued，就说明扫描本身已经准备好，只是在等系统资源。这一步先看清，后面才知道该改项目包、改排队策略，还是改并发上限。

　　二、Checkmarx扫描队列与资源配额怎么调

　　队列和资源配额这件事，最容易错在“只改一个地方”。CxManager有自己的最大并发扫描数，CxEngine也有自己的最大并发扫描数和可接受的LOC范围。官方文档说明，CxManager的Maximum number of concurrent scans默认是2，且不能超过许可证允许的并发数；CxEngine端则可以进一步按项目规模和并发上限做细分。

　　1、先改CxManager的总并发上限。

　　在Settings里的Application Settings中，CxManager的Maximum number of concurrent scans默认值是2。官方明确说明，这个值不能超过许可证允许的并发数，而且修改后必须重启CxScansManager服务才会生效。这个参数更像总闸门，决定系统同时允许多少个扫描任务进入运行态。

　　2、再改CxEngine的单机并发能力。

　　在Engine Management里注册或修改Engine Server时，可以设置Max Concurrent Scans。官方说明里写得很直接，这个值取决于你系统资源本身，所以它不该凭感觉拉大，而要根据CPU、内存和项目规模去定。

　　3、用LOC范围给不同引擎分工。

　　CxEngine端还支持Scan LOC limits，可以给某台引擎限定它只接收某个规模区间的项目。官方特别提醒，如果所有引擎的区间拼起来不连续，或者某次扫描的代码规模落在所有范围之外，扫描会直接失败。对大仓库和小项目混跑的环境，这个配置比简单拉并发更有价值。

　　4、把同一项目的排队策略收紧。

　　官方队列文档说明，同一项目如果连续排了多次扫描，可以配置成三种行为，一种是全部都保留处理，一种是保留旧的取消新的，一种是保留新的取消旧的；API文档里对应的枚举值就是KeepAll、KeepOld、KeepNew。对高频提交项目来说，这一步很重要，不然同一个项目自己的旧扫描就会把新扫描堵住。

　　三、Checkmarx扫描节奏怎么收

　　很多团队后面越扫越慢，不是不会调参数，而是没有把“全量、增量、队列、引擎”这几层收成一个固定节奏。更稳的做法，是让主分支定期跑Full Scan，日常改动优先跑Incremental Scan，再配合项目级排队策略去消掉重复任务。官方文档对这条线写得很清楚，增量扫描最有效的前提就是主线持续有完整Full Scan，分支和PR也尽量跟基线保持同步。

　　1、主分支定期跑Full Scan。

　　不要让所有扫描都走增量。官方已经提醒，增量扫描依赖之前的Full Scan，而且长期只跑增量会让变化累计，最后超过阈值后不是转全量就是直接失败。

　　2、日常提交优先跑Incremental Scan。

　　如果项目已经有可靠的Full Scan基线，日常提交和分支提交优先用增量扫描，会比每次全量重扫更省资源。官方文档也说明，IDE触发的SAST扫描默认就是增量扫描。

　　3、重复触发多时先调项目排队策略。

　　如果同一个项目一天内会连续触发多次扫描，先把QueueKeepMode收到KeepNew或KeepOld这类更适合你流程的模式，通常比继续堆引擎更见效。这样做的目的，是让队列先少掉无效重复任务。

　　4、最后再看要不要扩资源。

　　当范围已经收过、增量已经跑顺、同项目重复扫描也被压住后，队列还是长期在Queued状态，这时候再回头加CxManager并发、加CxEngine并发或拆LOC区间，收益才更稳定。因为这时你解决的才是真正的资源瓶颈，而不是流程本身的浪费。

　　总结

　　Checkmarx SAST扫描很慢，先别急着提机器，先把扫描范围、增量扫描和队列状态分清。Checkmarx扫描队列与资源配额怎么调，重点也不是只改一个并发参数，而是把CxManager总并发、CxEngine单机并发、LOC分流和同项目排队策略一起收顺。把这几层先理清，扫描时间通常会比单纯加资源降得更稳。