使用Solr6.3 遇到的两个重要问题及解决

2019-02-23  本文已影响12人  明翼

一、背景

前段时间,一连参与了两次客户的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,如下:

<directoryFactory name="DirectoryFactory"
class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>

三、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你如果参数没有修改是直接不让你启动的。
项目实施中,要多研究下业务数据,数据是业务的核心,从数据中可以发现很多问题,如果这次可以及时查询分析,就很容易发现这个问题。

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

上一篇下一篇

猜你喜欢

热点阅读