当前位置: 移动技术网 > IT编程>数据库>MongoDB > Elasticsearch 填坑记

Elasticsearch 填坑记

2018年06月24日  | 移动技术网IT编程  | 我要评论

前言

        技术的发展日新月异,传统企业数据库Oracle、SqlServer、DB2,Mysql等在今日不断的被各种大厂自研数据库取代,当然也有类似Elasticsearch等优秀的满足海量数据所使用的开源数据库。

       我司多个日志审计与态势感知项目中,也没有免俗,选择了Elasticsearch作为我们的日志存储与搜索引擎。关于Elasticsearch基础知识就不做更多介绍了,随便搜索下,有大量的介绍和使用文档。

       本文主要介绍我们在多个项目中,使用Elasticsearch过程中,各种填坑记录。

       在具体的生产环境中,我相信大家不会用Windows作为Elasticsearch的运行服务器的,所以下文基本都是以Linux(Centos7)为主要的运行环境。

       以下内容,仅供参考,实际遇到的问题,都需要在运维过程中,去仔细分析,查阅文档。解决问题的方法可能很简单,关键是能准确的定位问题,分析问题。

  • 安装

       Elasticsearch安装就不多阐述了,主要记住:创建非root用户,修改linux系统参数,修改jvm运行参数,修改Elasticsearch运行参数,这4个主要部分。

       由于Elasticsearch版本迭代比较快,不同的版本个别参数可能已经变更或废弃,所以修改前一定要认真阅读对应版本的官方文档,该参数是否还有效,这个地方是一个坑,需要重点注意。

 

  • 运行与系统调优

       Elasticsearch的安装其实还是比较简单的,但是在实际运行中,各种各样的问题就来了。在实际运行中出现的问题,其实主要还是数据量的问题,随着数据量的增长,就会出现各种资源问题,需要随时解决和调优。

1.内存问题

       官方建议Elasticsearch每个节点jvm配置内存不要大于系统总内存的一半同时不要大于32G。

       Elasticsearch本身在运行过程中,随着数据量的增加,内存的使用会越来越多,gc回收会越来越慢,最终导致Elasticsearch虽然活着,但不响应任何请求。

       这种情况下,扩充节点是个选项,但是大多数的情况,预算是固定的,硬件资源也是固定的,只能采取其他办法。

  • 数据要根据业务做成多索引的方式,因为每个索引都是占用内存的,多索引才有可能关闭部分历史数据索引,释放内存。最好做成定时任务,按照规则关闭不用的索引。

  • 定时对索引进行合并(merge segment)

  • jvm垃圾回收机制可以考虑配置为 UseG1GC 

  • 即使按照官方说明配置成32G以下,比如31G,在短时间数据量暴增的情况下,容易带来linux oom问题,如果存在这种情况,建议再配置小一点。

2.文件句柄问题

       linux中,所有的一切都与文件有关,实时打开的文件句柄数是有限制的,Elasticsearch可以看着是基于文件的数据库,随着数据量的增加,打开的句柄越来越多,就会导致系统停止对外响应,比如ssh登录不上去等问题。

       这种情况,首先建议调整linux内核参数,修改系统打开的最大文件句柄数量。

       其次还是要控制索引的数量,不要无限制的增长下去,想办法控制同时打开的文件句柄数量。

 3.硬盘问题

       硬盘当然是读写速度越快越好,数据量比较大的环境可以考虑冷热数据分离。

       需要注意的是当Elasticsearch数据所在的硬盘空间使用超过80%以上时,就可能出现数据不再写入该节点的情况,所以需要定时监测硬盘使用量。

       另外,不太建议使用通过网络挂载的硬盘空间。

       总的来说硬盘有关的问题相对少点,就不多说了。

 4.其他问题

       以下的问题,可能是在特定的环境下,特定的版本上出现的。

       运行环境,vmware+centos7.4 , kernel 3.x,3个ES节点,各64G内存。

       问题1:3个节点中,有2个数据节点频繁宕机,kernel异常日志提示watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [java:5783]。

       各种搜索,建议升级内核版本,大于4.13.0-1017。

       辛辛苦苦给2个节点升级内核,具体方法,自行百度,升级内核的坑就不多说了。

       问题2:升级内核后,问题1基本解决,但是在短时间数据流暴增的情况下,出现OOM问题。

       分析原因,应该还是jvm内存设置为31G,es索引底层索引内存请求加上jvm内存请求可能超出系统总物理内存(毕竟还有其他程序也要占用内存),导致OOM问题。解决办法,jvm内存适当调小一点。

       当然也可以调整内核参数,取消OOM特性(不建议在生产环境使用)。

       问题3:最郁闷的情况,解决完上述两个问题后,系统平均10多分钟就宕机一次,系统日志无报错,只在vcenter控制台上,提示kernel BUG at       drivers/net/vmxnet3/vmxnet3_drv.c:1441!。继续搜索,发现这是vmware的一个bug,在特定情况下出现:

       Linux VM is running kernel >= 4.8

       HW version of VM is >=13

       ESXi version is 6.5

       解决办法:

              修改虚拟机vmx配置文件,添加vmxnet3.rev.30 = FALSE

              或者 设置ethtool -G ethX rx-mini 0,ethX为网卡名称

 

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网