Solr从8.11升级到9.0后高负载节点僵死问题排查求助

问题背景 #

因安全需求将Solr集群从v8.11.1升级至v9.0.0，同步将Java从1.8-openjdk升级至11-openjdk（Solr 9最低要求）。升级后节点在高负载下出现僵死：

• 执行 service solr stop 无法正常停止服务，必须用 kill -9 强制终止
• 负载升高时节点服务不可达，本地Web界面无法访问，SSH常规停止命令无响应

升级变更清单 #

• Solr版本：v8.11.1 → v9.0.0
• Java版本：java-1.8-openjdk → java-11-openjdk
• Core配置文件solrconfig.xml调整：
  • luceneMatchVersion从8.11.1改为9.0
  • 移除旧缓存配置（v9不再支持queryCache/documentCache的solr.LRUCache，默认改为CaffeineCache；filterCache原使用FastLRUCache）
  • 移除不支持的xslt类型queryresponsewriter
• 日志级别调整为WARN（因默认日志输出增多）

已尝试无效操作 #

• 改用openjdk-19替代11
• 调整内存：原16G服务器，SOLR_JAVA_MEM设为"-Xms5g -Xmx5g"，尝试过改为8G，或升级服务器到32G保持原配置
• 优化Solr Core（自1月后未优化过）

集群配置：2个节点，单Core含近1亿条文档，优化后大小约130G

排查步骤 #

1. 抓取线程与堆快照 #

当节点僵死时，立即执行以下命令获取诊断信息：

• 线程快照：jstack <solr_pid> > solr_thread_dump.txt
• 堆快照：jmap -dump:format=b,file=solr_heap_dump.hprof <solr_pid>
  重点分析：
  • 是否存在阻塞线程（锁等待、IO阻塞等）
  • CaffeineCache相关线程是否异常
  • 请求处理线程是否全部挂起

2. 分析GC日志 #

确保Solr启动时开启GC日志（在SOLR_OPTS中添加）：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/var/log/solr/gc.log

排查方向：

• 是否频繁触发Full GC
• Old区内存是否持续增长（内存泄漏嫌疑）
• G1GC（Java 11默认）的停顿时间是否过长

3. 开启慢查询日志 #

在solrconfig.xml中配置慢查询记录：

<requestDispatcher handleSelect="true">
  <requestParsers enableRemoteStreaming="false" multipartUploadLimitInKB="2048000" formdataUploadLimitInKB="2048000"/>
  <querylog enable="true" threshold="1000"/> <!-- 记录耗时超过1秒的查询 -->
</requestDispatcher>

通过慢查询日志定位高负载下的耗时请求，排查是否存在未优化的查询导致线程阻塞。

4. 验证CaffeineCache适配性 #

Solr 9默认使用CaffeineCache替代旧LRUCache，需确认：

• 是否显式配置缓存参数（如maximumSize、expireAfterAccess），默认配置可能不适配1亿级文档场景
• 对比升级前后缓存命中率，若命中率骤降，需调整缓存大小或过期策略

可能遗漏的关键配置变更 #

1. Java 11兼容性调整 #

• 检查自定义插件（若有）是否兼容Java 11（Java 11移除了部分旧API）
• 在SOLR_OPTS中添加兼容参数，如--add-opens java.base/java.lang=ALL-UNNAMED（部分旧插件可能需要）
• 显式指定G1GC收集器：-XX:+UseG1GC（Java 11默认，但可确保生效）

2. 索引格式完整升级 #

虽然已修改luceneMatchVersion为9.0，仍需执行索引升级命令确保格式完全适配：

bin/solr upgrade -c <core_name>

避免高负载下索引读写异常。

3. 并发线程池配置 #

Solr 9对请求处理线程池的默认配置与v8不同，需检查solrconfig.xml中的线程池参数：

<queryThreadPool size="100" minSize="10" maxSize="200" idleTimeout="5000"/>

根据业务并发量调整线程池大小，避免高负载下线程耗尽导致僵死。

4. 磁盘IO性能排查 #

通过iostat -x 1监控磁盘使用率、读写延迟，确认是否存在磁盘IO饱和。130G索引在高负载下，若使用机械硬盘，极易因IO瓶颈导致请求阻塞。

临时应急方案 #

排查期间可通过以下配置缓解问题：

• 通过负载均衡限制单节点QPS，降低并发请求量
• 开启Solr分片缓存，减少重复查询的磁盘IO
• 调整新生代内存占比，如-Xms5g -Xmx5g -XX:NewRatio=2，减少Minor GC次数

内容的提问来源于stack exchange，提问作者Jeroen