最近公司的其中的一个集群的solr出现了一个比较奇怪的事情,先简单说说以下的情况
机器A是前端的逻辑应用
机器B是具体一个 solr 应用
很通用的方式都是从机器A向机器B的 solr 拿搜索结果并呈现给前端,机器A与机器B处于千兆局域网络。
前端的同事反应有时候, solr 返回的 QTime 很快,但实现搜索出来的结果时间却很久,我大概画了一个图,让大家更明白。
如上图所示,前端的同事在请求 solr 的方法前后加了时间计算,就是请求的所有时间,再前去 solr 反回的 QTime ,则就是网络的响应时间了。前端的同事发现,有些情况下,当然不是特定的条件,QTime 返回一般只就 100 ms 到 200 ms ,但网络的响应时间却比QTime 大很多,经常是1秒甚至更长。
找寻问题的根源:
1. 基于这一个情况,当时我认为是内部的网络有问题,但通过机器之前的同步文件,速度也非常快,似乎都不存在过多的网络延时。
2. 因为 solr 那端是用了 tomcat ,当时有想过是否 tomcat 的连接池原因?通过更改 server.xml 的参数,问题似乎依然,但如果直通访问 tomcat 上的网页速度非常快,也看不出什么任何延时。
3. 会不会是 linux 主机的 sokcet 连接数,参数等影响了?因为机器安装上去后,我是看到并没有对 /etc/syscotl.conf 的参数做调整过,机器A与机器B也调整过了,但问题依旧。
4. 因为前端的机器A是用了 httpclient 的,把 httpclient 的连接池,参数等也调整过,问题依旧,最后把 httpclient 完全去掉了,改用了普通的 socket ,效果有一点点的改善,但不明显。
最后似乎都是无计可施了。。。。,按字面的理解,QTime 就是搜索的总用时。
在查看代码的情况下,在各搜索模块的 component 的 prepare , process 的时间都非常快,与QTime 很符合,当时我认为,搜索的过程就这样子了,时间很快哦,难道是把搜索的结果写回机器A时很久了?
最后在自己最不认为是问题的代码块中添加了一个时间检查,如下:
就从表面上来说,这段代码是所有的搜索操作都完成后,需要把搜索的结果 solrRsp 写到网络并回传到机器A的前端去,但这个时间耗用的时间与响应时间非常吻合,看来时间就是耗用在这个了,而且一个偶尔的发现,如果把solr 参数 rows=0 的时候,发现所有的响应时间非常短,都在几毫秒完成了。但就算 rows=1 也好,响应时间都有几十毫秒,这里我突然间意识到,在里面,肯定还有读写硬盘的操作并非仅仅是把结果写回网络中。
最后深入看代码后,发现了,其实 solrRsp 只拿到 docId, 具体的文档的内容,还需要通过 docId 从硬盘中读回来。正正就是这段时间损耗了,因为 QTime 在这之前已经结束了,并没有算上这一部分时间,导致了误解了 QTime 的与网络响应时间之前的关系。以 BinaryResponseWriter 为例子,时间都用在以下的代码里面的
因为群集中的索引比较大,一份索引约20G左右,这机器总有4份,约80G左右这时读取索引的内容反而成了瓶颈了。
解决的方案:
一个能缓解这种情况的方法就是在 solrconfig.xml 中,把 docsCache 加大到100W甚至更大,这个只能对于之前读取过的 doc 才能有效,所以这种方式只能是暂时缓解没有根本解决。
一个比较彻底解决的是,在启动的过程,通过 index.termEnum 把索引的所有相关的内容都采用延时加载到一个 数组中,一个 2000W ,只要内存有16G以上那并不是什么难题。对于这么大的的数据量,肯定是只有一份索引在添加新的索引,其他的索引保持不变,就算有删除了数据,也不会 optimize ,所以这种方式还是能根本上解决以上的问题。
欢迎转载,请注册出处 http://kernaling-wong.iteye.com/blog/2017985
相关推荐
这些测试结果对于理解和优化 Solr 在实际应用中的性能具有重要的指导意义。在选择 Solr 部署模式时,需要根据具体的业务需求和预期的并发量来权衡单节点和集群的优劣。在需要高性能读写和高可用性的场景下,Solr ...
- **JVM配置**:Solr运行于Java虚拟机(JVM)之上,合理的JVM配置对提高性能至关重要。例如,设置合理的堆内存大小(`-Xms` 和 `-Xmx` 参数)以确保有足够的内存用于索引和缓存,避免频繁的垃圾回收。 - **HTTP缓存**...
在Solr中,Schema是核心组件之一,它定义了文档的结构和处理方式。`manageschema`功能允许用户通过Web界面动态地修改Schema,而无需直接编辑XML文件,简化了管理和维护过程。在这个"增加了分词器后的配置文件"中,...
### Solr性能优化关键知识点详解 #### 一、理解Solr环境与版本 - **环境配置**:在本文档中,我们关注的是基于Tomcat 6的Solr 3.5版本的部署与优化,这对于初学者来说是一个非常实用且稳定的组合。 - **Solr简介...
随着传统互联网和移动互联网的持续发展,网络带给我们的...目前一些搜索公司在公共互联网领域提供了很好的解决方案,但是企业或者政府机关内部相关信息往往需要应用独立的搜索系统,Solr Cloud则是很好的一个平台选择。
solr在做检索的时候时常需要得知他的性能参数,此处使用8G内存,双核处理器测试的结果
最后,ES的一个不足之处在于文档编写可能不如Solr全面。由于ES和Solr都在快速的发展中,版本更新频繁,用户应该基于自己的需求进行实际测试,来判断哪个产品更适合自己的应用场景。对于ES而言,尽管它提供了很多先进...
"solr性能调优.mht"文件专门针对Solr的性能优化,包括索引优化、硬件配置、查询策略调整等方面,对于追求高效稳定运行的Solr系统来说,这部分内容是必不可少的。 这些文档和资料覆盖了Solr的多个方面,包括入门、...
8. **搜索性能优化**:Solr提供了多种优化手段,包括使用倒排索引、缓存策略、查询优化器等,以提高查询速度和整体性能。 9. **安全与认证**:Solr 8.x引入了内置的安全性框架,包括Zookeeper的ACL和Solr的Role-...
- **性能优化**:Solr团队不断努力提升查询速度和索引效率,8.11.1版本可能包含了一些新的性能优化。 - **新功能**:可能引入了新的搜索特性,比如新的查询语法、更强大的分析器或者对最新技术标准的支持。 - **稳定...
Solr的多种性能优化技巧,如索引的性能优化、缓存的性能 优化、查询的性能优化、JVM和Web容器的优化,以及操作系统级别的优化。 拓展知识中首先讲解了Solr的一些比较生僻的知识点,如伪域、多语种索引支持、安全认证...
Solr-9.0.0是该软件的最新版本,此版本可能包含了一些新的特性和改进,比如性能优化、新的查询语法、更强大的分析器等。 在Solr-9.0.0的压缩包中,通常会包含以下组件: 1. **bin** 文件夹:这个目录下有启动和...
增量更新是Solr的一个关键特性,它允许系统仅处理自上次完整索引以来发生更改的数据,从而提高了性能并降低了资源消耗。"apache-solr-dataimportscheduler.jar" 是一个专门为Solr设计的扩展包,用于实现自动化的数据...
产品逻辑优化经常会容易被忽略,但效果却往往比数据库调优、JVM 调优之类的来的更明显。例如,在 12306 春运抢火车票的场景,由于访问的人多,用户点击“查票”之后系统会非常卡,进度条非常慢,作为用户,我们会...
通过深入研究`solr-9.0.0-src.tgz`源码,开发者可以理解Solr的工作原理,定制自己的搜索解决方案,解决特定场景下的性能挑战,并为社区贡献新的功能和优化。同时,这也为学习和研究信息检索、全文搜索、分布式计算等...
2. 引入了新的查询执行模型(Distributed Searcher):优化了分布式查询的性能和稳定性。 3. 增强的CSV处理:支持更大的CSV文件导入,改进了错误处理机制。 4. 优化的内存管理:减少了内存消耗,提高了系统稳定性。 ...
Java 8是Solr 7.x系列支持的最低版本,因为Solr的许多特性和性能优化都是针对Java 8设计的。安装Java 8后,你需要在系统的环境变量中设置`JAVA_HOME`,指向Java安装目录。这一步是必要的,因为Solr启动时会读取此...
9. **性能优化**:Solr可以通过调整缓存策略、使用NRT(Near Real Time)索引、优化查询执行计划等方式提高查询速度。 10. **安全与身份验证**:Solr 8.8.2可能包含安全模块,允许设置访问控制列表(ACLs)和角色...
10. **性能优化**:掌握如何调整Solr的配置参数,如缓存大小、索引策略等,以适应不同的工作负载。 总之,Solr4.9开发涉及多个方面,从基本的索引构建到复杂的分布式搜索和数据处理,都需要开发者有扎实的技术基础...