从Solr卡顿到G1垃圾回收

开源搜索引擎Solr是一款非常优秀的搜素引擎，只要一些简单的配置就能进行使用，大大减少了开发时间。

在我工作的环境中，整站的商品搜索业务都是依托于Solr，在Solr的使用上沉淀了不少宝贵的开发经验。随着公司商品数据规模不断的扩大，针对Solr的二次开发难度也在不断的增大，在过去的几年时间内，我把大量的数据放在索引构建上，从之前的DB模式24小时都无法完成全量的构建，到现在使用hive + avro + mapreduce把全量构建压缩到3小时以内，从之前的DB增量模式经常出现更新失败，更新延迟，到现在使用kafka+redis的模式保证更新数据不丢实，更新的延迟在1分钟以内。整个全量增量的索引架构都是可以横向扩展。

在索引构建告一段落后，查询又出现了问题，经常可以看到Solr每隔20分钟，会有timeout情况的出现。查看了下日志，在那段报错的时间段，正好是slave从master上获取增量数据的时间（replication配置了每隔20分钟slave replication一次数据到master），而Solr中许多内置的缓存都开的比较大。当数据更新后，Solr会对Cache进行重新的预热，在这个时候，有大量的内存对象会被换入换出，可能在这个点触发了full gc。

为了验证是否是full gc的可能，首先第一步获取full的信息，命令：

使用lsof命令根据端口找出pid（当然linux有很多其他方式，条条大路通罗马），然后使用jstat -gc命令获取信息。图中该Solr程序已经运行了196hrs35min，可以看出FGC一共执行了356次&#x