概述

今天主要介绍一下ES的内存分配机制，众所周知Elasticsearch默认安装后设置的内存是1GB，对于任何一个生产环境来说，这个设置都太小了。

和数据库类似，ES对于内存的消耗，和很多因素相关，诸如数据总量、mapping设置、查询方式、查询频度等等。默认的设置虽开箱即用，但不能适用每一种使用场景。作为ES的开发、运维人员，如果不了解ES对内存使用的一些基本原理，就很难针对特有的应用场景，有效的测试、规划和管理集群。

要理解ES如何使用内存，先要尊重下面两个基本事实:

• 1. ES是JAVA应用
• 2. 底层存储引擎是基于Lucene的

一、官方建议：把内存的一半给Lucene+不要超过32G+关闭swap

1、分配一半给lucene

内存对于Elasticsearch来说绝对是重要的，用于更多的内存数据提供更快的操作，而且还有一个内存消耗大户-Lucene。
Lucene的设计目的是把底层OS里的数据缓存到内存中。Lucene的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
Lucene的性能取决于和OS的交互，如果你把所有的内存都分配给Elasticsearch，不留一点给Lucene，那你的全文检索性能会很差的。
最后标准的建议是把50%的内存给elasticsearch，剩下的50%也不会没有用处的，Lucene会很快吞噬剩下的这部分内存用于文件缓存。

如果你不需要对分词字符串做聚合计算（例如，不需要 fielddata ）可以考虑降低堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。

2、不要超过32G

JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。

在 Java 中，所有的对象都分配在堆上，并通过一个指针进行引用。 普通对象指针（OOP）指向这些对象，通常为 CPU 字长 的大小：32 位或 64 位，取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。

对于 32 位的系统，意味着堆内存大小最大为 4 GB。对于 64 位的系统， 可以使用更大的内存，但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是， 更大的指针在主内存和各级缓存（例如 LLC，L1 等）之间移动数据的时候，会占用更多的带宽。

Java 使用一个叫作 内存指针压缩（compressed oops）的技术来解决这个问题。 它的指针不再表示对象在内存中的精确位置，而是表示 偏移量 。这意味着 32 位的指针可以引用 40 亿个 对象 ， 而不是 40 亿个字节。最终， 也就是说堆内存增长到 32 GB 的物理内存，也可以用 32 位的指针表示。

一旦你越过那个神奇的 ~32 GB 的边界，指针就会切回普通对象的指针。 每个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。事实上，当内存到达 40–50 GB 的时候，有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存。

这段描述的意思就是说：即便你有足够的内存，也尽量不要 超过 32 GB。因为它浪费了内存，降低了 CPU 的性能，还要让 GC 应对大内存。

3、关闭swap

ES建议要关闭 swap 内存交换空间，禁用swapping。频繁的swapping 对服务器来说是致命的。

当内存交换到磁盘上，一个100微秒的操作可能变成 10毫秒，然后10 微秒的操作时延累加起来，可以看出 swapping 对于性能的影响是多么致命。

可以用以下方式临时禁用：

 swapoff -a

永久禁用swap：

用vi修改/etc/fstab文件，在swap分区这行前加 # 禁用掉，保存退出后重启。

二、ES内存分配明细

Elasticsearch 限制的内存大小是 JAVA 堆空间的大小，不包括Lucene 缓存倒排索引数据空间。

• Lucene 中的 倒排索引 segments 存储在文件中，为提高访问速度，都会把它加载到内存中，从而提高 Lucene 性能。所以建议至少留系统一半内存给Lucene。
• Node Query Cache (负责缓存f ilter 查询结果)，每个节点有一个，被所有 shard 共享，filter query查询结果要么是 yes 要么是no，不涉及 scores 的计算。
  集群中每个节点都要配置，默认为：indices.queries.cache.size:10%
• Indexing Buffer 索引缓冲区，用于存储新索引的文档，当其被填满时，缓冲区中的文档被写入磁盘中的 segments 中。节点上所有 shard 共享。
  缓冲区默认大小： indices.memory.index_buffer_size: 10%如果缓冲区大小设置了百分百则 indices.memory.min_index_buffer_size 用于这是最小值，默认为 48mb。indices.memory.max_index_buffer_size 用于最大大小，无默认值。
• Shard Request Cache 用于缓存请求结果，但之缓存request size为0的。比如说 hits.total, aggregations 和 suggestions. 默认最大为indices.requests.cache.size:1%
• Field Data Cache 字段缓存重要用于对字段进行排序、聚合是使用。因为构建字段数据缓存代价昂贵，所以建议有足够的内训来存储。
  Fielddata 是 延迟 加载。如果你从来没有聚合一个分析字符串，就不会加载 fielddata 到内存中，也就不会使用大量的内存，所以可以考虑分配较小的heap给Elasticsearch。因为heap越小意味着Elasticsearch的GC会比较快，并且预留给Lucene的内存也会比较大。。
  如果没有足够的内存保存fielddata时，Elastisearch会不断地从磁盘加载数据到内存，并剔除掉旧的内存数据。剔除操作会造成严重的磁盘I/O，并且引发大量的GC，会严重影响Elastisearch的性能。

三、如何修改ES的内存

一般有两种方式修改Elasticsearch的堆内存

1、指定ES_HEAP_SIZE环境变量

服务进程在启动时候会读取这个变量，并相应的设置堆的大小。设置命令如下：

 export ES_HEAP_SIZE=10g

2、通过命令行参数的形式

在程序启动的时候把内存大小传递给它：

 ./bin/elasticsearch -Xmx10g -Xms10g

备注:确保Xmx和Xms的大小是相同的，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源，可以减轻伸缩堆大小带来的压力。
一般来说设置ES_HEAP_SIZE环境变量，比直接写-Xmx10g -Xms10g更好一点。

四、监控data node上segment memory

ES的data node存储数据并非只是耗费磁盘空间的，为了加速数据的访问，每个segment都有会一些索引数据驻留在heap里。因此segment越多，瓜分掉的heap也越多，并且这部分heap是无法被GC掉的！ 理解这点对于监控和管理集群容量很重要，当一个node的segment memory占用过多的时候，就需要考虑删除、归档数据，或者扩容了。

怎么知道segment memory占用情况呢? CAT API可以给出答案。

1、查看一个索引所有segment的memory占用情况

 GET /_cat/segments/索引名?v&h=index,shard,segment,size,size.memory

2、查看一个node上所有segment占用的memory总和

 GET /_cat/nodes?v&h=name,port,sm

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~