Solr集群性能下降无响应问题排查与配置咨询
环境信息
- 集群架构:3个Solr节点 + 3个ZooKeeper节点,每台AWS EC2实例同时运行1个Solr服务和1个ZooKeeper服务
- EC2分布:分别位于AWS us-east-1a、us-east-1b、us-east-1c可用区
- 实例配置:Linux 6.2.0-1018-aws,4核CPU,30.9Gb内存
- 软件版本:Java 11.0.21,Solr 9.1.0
问题1:此集群配置是否合理?是否存在通用问题?例如,3台EC2分布在不同可用区是否可行?
配置合理性与潜在问题
- 跨可用区部署可行且推荐:将节点分布在不同可用区能提升集群容灾能力,单个可用区故障不会导致整个集群瘫痪,符合高可用架构设计。
- 存在的通用问题:
- 跨可用区网络延迟:不同可用区之间的网络延迟高于同可用区,会增加Solr节点间、Solr与ZooKeeper间的通信耗时,高负载场景下可能放大性能问题。
- 单实例资源竞争:单台EC2同时运行Solr和ZooKeeper,会在CPU、内存、网络带宽上产生资源竞争,当Solr处理大查询或高并发请求时,可能影响ZooKeeper稳定性,反之亦然。
问题2:大查询时集群无响应/超时的问题分析与解决
关于你的推测
你的推测有一定合理性,但从日志来看,更直接的问题是节点间通信出现数据格式错误或网络中断:
- 日志中
Expected mime type application/octet-stream but got text/html说明节点间请求返回了HTML错误页面(如5xx、4xx),而非Solr预期的二进制响应。 Invalid version (expected 2, but 60) or the data in not in 'javabin' format表示节点收到的响应不符合Solr的javabin数据格式,大概率是通信过程中数据包损坏、中断,或者目标节点返回了非预期内容。
排查与解决步骤
1. 定位故障节点
日志反复指向http://10.9.13.144:8983/solr,优先检查该节点:
- 登录EC2实例,查看Solr服务状态:
systemctl status solr(若使用systemd管理) - 查看该节点Solr日志,排查是否有OOM、GC超时、端口占用等错误
- 本地测试节点可用性:
curl http://10.9.13.144:8983/solr/admin/cores,确认是否能正常返回JSON响应
2. 优化网络与通信配置
- 调整Solr节点间超时参数:在
solr.xml中修改以下参数,适配跨可用区网络延迟:<solrcloud> <str name="distribUpdateSoTimeout">30000</str> <!-- 节点间更新请求超时,从默认10s调整为30s --> <str name="distribUpdateConnTimeout">5000</str> <!-- 连接超时,从默认1s调整为5s --> <str name="shardHandlerTimeout">60000</str> <!-- 分片查询超时,默认60s,可按需调整 --> </solrcloud> - 检查EC2网络配置:确保安全组允许节点间8983(Solr)、2181/2888/3888(ZooKeeper)端口通信;若使用VPC,确认跨可用区网络带宽足够,无流量限制。
3. 缓解资源竞争
- 分离Solr与ZooKeeper资源:条件允许的话,将ZooKeeper迁移到独立EC2实例,避免资源争夺。若暂时无法分离:
- 给ZooKeeper分配固定内存(修改
zoo.cfg的-Xmx参数,比如-Xmx2g),避免占用过多内存影响Solr。 - 优化Solr JVM参数:设置堆内存为物理内存的50%-70%(如
-Xmx20g -Xms20g),配置GC参数优化内存回收,避免GC超时导致服务卡顿。
- 给ZooKeeper分配固定内存(修改
4. 优化大查询性能
- 避免一次性返回大量数据:使用分页查询(
start+rows参数)或游标查询(cursorMark参数),减少单次请求的数据传输量和节点处理压力。 - 优化查询语句:检查是否存在未优化的过滤条件、排序或聚合操作,比如缺少索引、使用低效函数查询,这些会大幅增加Solr的CPU和内存消耗。
- 调整查询缓存:合理配置
queryResultCache、filterCache等缓存,提升重复查询响应速度,但注意缓存不要占用过多内存。
5. 监控与预警
- 配置Solr监控(如自带Metrics、Prometheus+Grafana),实时跟踪节点CPU、内存、GC、网络IO等指标,及时发现瓶颈。
- 监控ZooKeeper状态:通过
zkServer.sh status查看节点角色、连接数,确保ZooKeeper集群稳定。
内容的提问来源于stack exchange,提问作者peter.petrov
相关产品推荐
相关产品推荐

