基于Lucene的SOLR一直以稳定、高性能著称,虽然其在高并发下对CPU要求较高,但能解决复杂的查询并能以如此快的速度内返回搜索结果,实在是开发搜索的一大利器。公司部署在Linux服务器上的Master-Slave架构的SOLR在过去1年多以来运行都比较稳定。
最近一周,有开发人员反馈索引更新速度非常慢,造成一大堆数据还未等待索引操作,客户端提交索引的逻辑优化很多遍都没有效果。对于索引性能的检查,主要是从客户端和服务端两个地方入手:
1、客户端,检查结果发现多线程并未出现死锁,通过solrj发送索引命令因为执行速度太慢一直被阻塞在线程池中,客户端使用的是官方推荐的ConcurrentUpdateSolrServer,采用批量adds的方式更新索引(平均每秒需要更新3万条),使用效率更高的二进制请求(替换XML请求);客户端未不是问题的根源。
2、服务端,IO压力不大,内存充裕,CPU占用率偏高达到40%以上;查看solr日志发现大量出现adds 300条索引的时间QTime达到惊人的几十秒;索引瓶颈出现在服务端。
于是安排开发人员分析是否因为
随着数据量的上升(1.3亿条索引数据、占用磁盘空间50G左右),而带来的索引压力大造成速度被拖垮?通过调整solrconfig.xml的一系列参数,如增大ramBufferSizeMB,加大mergeFactor,减少autoCommit次数,尽量减少磁盘操作,测试索引速度,但收效甚微。通过GC日志分析垃圾回收正常,即使更换垃圾回收策略也没有明显的提升空间。
最后只能去dump线程分析CPU花费在哪些上面,在dump日志中看到tomcat的很多线程都处于等待状态,处于Running状态的经常是分词,于是把堆栈拷贝出来给分词器开发人员分析,开发人员从堆栈中看出代码执行在简繁体转换,在快速修复分词器的这个bug后更新到SOLR服务器,索引速度恢复如初。