Elasticsearch使用优化之拙见

　　

Elasticsearch常常作为日志存储和分析的工具,在企业级应用中常常使用.Elasticsearch提供强大的搜索,分析功能,已经是后端技术栈不可缺少的一部分。

在维护ElastciSearch集群的时候,对Elasticsearch进行了一些调优和分析,现整理成文,纯属拙见,如果有不合理之处,欢迎指出探讨。我所使用的Elasticsearch版本为5。x。

Elasticsearch有大量的查询数据和插入数据的请求,需要大量文件句柄,centos系统默认的1024个文件句柄。如果文件句柄用完的了,这就意味着操作系统会拒绝连接,意味着数据可能丢失,这是灾难性的后果,

不能被接受。登陆Elasticsearch的启动用户,用一下命令查看:

ulimit - a

查看结果:

核心文件大小(块,- c) 0
　　数据赛格大小(kb - d)无限
　　调度优先级(e) 0
　　文件大小(块,- f)无限
　　等待信号(我)127673
　　马克斯锁定内存(kb - l)无限的
　　最大内存大小(kb - m)无限的
　　打开的文件(- n) 1024
　　管大小(512字节,- p) 8
　　POSIX消息队列(字节,q) 819200
　　实时优先级(- r) 0
　　堆栈大小(kb - s) 8192
　　cpu时间(秒- t)无限
　　最大用户进程(- u) 2056474
　　虚拟内存(kb - v)无限
　　文件锁(- x)无限的

上面的文件句柄(打开文件)的个数为1024,在ElasticSearch大量请求的情况下,这个句柄数量是不够的,可以改成655360。

临时修改可以通过执行以下命令,即可立即生效,但是机器重启后又会失效:

ulimit - n 655360

永久生效,修改/etc/安全/限制。配置,需要重启机器生效:

u_ - nofile 655360

上述配置中u_为启动ElasticSearch的用户,设置了该用户的ElasticSearch的文件句柄为655360,

ElasticSearch是运行在JVM上的,对其做JVM参数调优至关重要。最常见的调优是Java内存的分配。下面是JVM的内存模型,具体每块的作用,不在这里阐述。

ElasticSearch使用优化之拙见


JVM内存分为新生代和老年代。

<李>

新生代(或者伊甸园)

<李>

新实例化的对象分配的空间。新生代空间通常都非常小,一般在100 MB - 500 MB。新生代也包含两个幸存空间。

<李>

老年代

<李>

较老的对象存储的空间。这些对象预计将长期留存并持续上很长一段时间。老生代通常比新生代大很多。

新生代,老生代的垃圾回收都有一个阶段会“停止世界”。在这段时间里,JVM停止了程序运行,以便对对象进行可达性分析,收集死亡对象。在这个时间停止阶段,一切都不会发生。请求不被服务,萍不被回应,分片不被分配。整个世界都真的停止了。

对于新生代,这不是什么大问题,那么小的空间意味着GC会很快执行完。但是老生代大很的多,而这里面一个慢GC可能就意味着1秒乃至15秒的暂停——对于服务器软件来说这是不可接受的。

那一般我们给新生代和老年代分配多大的内存呢?他们的比例是多少呢?

一般来说,老年代和新生代的内存比例为2:1是比较合适的。比如给堆内存分配3 g,则新生代分配1 g,其余都给老年代。在ElasticSearce的配置文件JVM。选择文件配置:

-Xms3g//配置堆初始化大小 　　-Xmx3g//配置堆的最大内存 　　-Xmn1g//配置新生代内存。

在使用Elasticesearch的时候,我们对装Elasticesearch的机器进行了升级,从最小的8 g内存升级到了16 g内存,然后到目前的32 g内存。一台机器装一个Elasticesearch节点,我们应该怎么分配机器的内存呢?

官方给出了解决方案,把一半(少于)的内存分配给Luence,另外的内存分配给ElasticSearch。null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null 　　null

Elasticsearch使用优化之拙见