• Elasticsearch 填坑记


    前言

            技术的发展日新月异,传统企业数据库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为网卡名称

  • 相关阅读:
    Java小程序1(2015-8-6)
    Java小程序(2015-8-6)
    Java基础2(2015-8-3)变量与数据类型
    Java小程序2(2015-8-2)
    Java小程序1(2015-8-2)
    MySql修改时区
    6、ssm整合(干货)
    关于 TreeMap 和 HashMap 的去重操作
    5、SpringMVC:JSON
    4、配置MVC的乱码过滤:解决中文乱码
  • 原文地址:https://www.cnblogs.com/wishma/p/9218668.html
Copyright © 2020-2023  润新知