一次SOLR索引更新的调优过程

   基于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服务器，索引速度恢复如初。