可恨的Solr6.3不稳定根源终于找到了

一、背景

前段时间，一连参与了两次客户的Solr问题解决，非常具有参考价值，特别是第二次，网上用Solr的人越来越少，写下总结，希望给使用Solr也遇到类似的问题的朋友一点提示吧。

二、MMapDirectory报错

2.1 报错现象

报错的信息还是比较直接提示Map映射失败，并给出了"sysctl vm.max_map_count”等需要修改的提示。

2.2 解决办法

1、按照如下方式修改内存映射的限制参数
vi /etc/sysctl.conf
vm.max_map_count=262144
#生效配置
sysctl –p
说明：设置可以使用的使用虚拟内存的限制和最大线程数。
2、更改程序可以使用最大内存限制
ulimit -m unlimited 在.bashrc中加入 或更改配置文件:/etc/security/limits.conf
说明：设置程序可以使用的最大内存。
3、更改程序可以使用的最大虚拟内存限制
ulimit -v unlimited 在.bashrc中加入 或更改配置文件:/etc/security/limits.conf【按照这里面的格式来改】
说明：设置程序可以使用的最大虚拟内存。

但是我们由于没有root用户，所以只能采用利用其它Directory，如下：

三、Solr和Zookeeper超时问题

这是这个系统第二次的问题了，很尴尬，首先同事查到是Zookeeper显示会话超时，然后我查了下Solr的GC日志发现有回收内存占用时间太长的情况，120秒，远远超过了我们设置的20秒的超时时间，所以报错。
我们设置的Solr运行内存为96G内存，按照一般情况来说，这个是足够的了，为什么会出现这种问题，用:

jmap -dump:live,format=b,file=out.txt pid

将内存输出到out.txt，直接看的话并没有发现什么异常信息，我们对照了Solr的故障机器和其他正常机器的内存占用情况，发现FieldInfo这个对象特别多，这个是索引中字段元数据信息的，这个为什么会多那，其他同事查了下索引发现，有几个索引的字段名超长，这导致字段名占内存很大，后面我们通过下线索引的方式验证了下，确实是这个问题，有问题的索引下线后，GC的时间减少了，再也没有出现过这个问题，而且Solr的节点内存占用稳定在64G左右。

四、总结

Solr性能不错，灵活性也还行，稳定性差些，有些系统参数没有修改竟然没有提示，这点比ES做的差，ES你如果参数没有修改是直接不让你启动的。
项目实施中，要多研究下业务数据，数据是业务的核心，从数据中可以发现很多问题，如果这次可以及时查询分析，就很容易发现这个问题。

血淋淋的教训，希望对大家有点帮助。