Solr配置commitWithin=1ms软提交耗时1.5秒致查询旧数据问题咨询

延迟是否属于预期表现 #

该1.5秒的软提交延迟不属于预期表现。你配置了commitWithin=1ms，无额外负载的正常环境下软提交应该在毫秒级完成，你其他测试环境中end_commit_flush紧随preSoftCommit触发的表现才是符合预期的正常情况。

可能导致延迟的常见因素 #

从你提供的日志可以看到，本次软提交配置了openSearcher=true、waitSearcher=true，结合Solr 8.x版本的实现逻辑，常见的延迟诱因包括：

• 新Searcher预热开销：软提交开启新Searcher的过程中，会执行所有已配置的缓存（filterCache、queryResultCache、documentCache等）预热逻辑，同时会触发所有注册的SearcherEventListener回调。如果你的索引体量较大、缓存预热条目配置过多，或是自定义了耗时的Searcher监听逻辑，都会大幅拉长软提交的整体耗时。
• IO资源瓶颈：即使环境看起来无额外业务负载，也要检查索引文件、tlog文件所在磁盘的IO使用率。如果存在后台磁盘同步任务、快照备份任务抢占IO资源，或是磁盘本身IO性能不足，都会阻塞软提交的flush流程。
• 提交调度线程资源不足：软提交由commitScheduler线程池调度执行，如果该线程池的核心线程数配置过低、或是有其他长时间运行的提交/优化任务占满了线程池，会导致软提交任务排队延迟。你可以检查solrconfig.xml中<updateHandler>节点下的maxPendingCommits、commitThreadPriority等配置是否和正常测试环境一致。
• 段合并抢占资源：如果软提交触发的同时，后台刚好在运行索引段合并任务，CPU、IO资源被合并任务大量占用，也会拖慢软提交的执行效率。你可以排查对应时间点的Solr日志中是否有段合并的相关记录。
• 同文档高频更新的连锁影响：你在软提交执行过程中，对同一文档又发起了两次更新请求，更新操作会加锁操作内存索引map，如果更新处理器链中存在自定义的耗时逻辑，也可能阻塞软提交的执行流程。

排查建议 #

你可以优先对比异常环境和正常测试环境的以下差异，快速定位问题：

1. solrconfig.xml中更新处理器、缓存、Searcher相关的配置项
2. JVM参数配置，尤其是堆内存、GC相关配置，排查延迟发生的时间点是否有Full GC出现
3. 服务器的CPU、内存、磁盘IO指标，确认延迟发生时是否有资源占用异常

内容的提问来源于stack exchange，提问作者Rudolf Traunmüller