（一：原理4）ElasticSearch内存分配以及优化

ElasticSearch内存分配以及优化

1：服务器内存分配

服务器内存消耗大户：
1：Elasticsearch
2：Lucene(全文搜索)

通常我们设置的es内存指这里的Elasticsearch heap<32G并小于节点内存的50%。取min(332G,服务器内存/2)

Elasticsearch heap其中主要内存作用如下

Node Query Cache ：用于filter过滤查询，默认10%
Indexing Buffer ：用于写入shard的缓存，默认10%
indices.fielddata.cache.size：用于缓存字段数据，默认无上限，
	最大大小不能超过indices.breaker.fielddata.limit（默认为 JVM 堆的 40%）

服务器剩余内存=服务器内存-Elasticsearch heap-其他服务占用
剩余内存主要作用：缓存segment数据，提升查询时候数据的命中率，提高查询效率和速度

1.1：为什么不建议大于32g？

jvm 在内存 < 32G 的时候会采用一个：内存对象指针压缩技术。
需要明白：不一定是 32GB，一般 linux 系统上都是介于 (31, 32)，所以为了安全起见我们统一都可以设置为 31GB。
在 java 中，所有的对象都分配在堆上，然后有一个指针引用它。指向这些对象的指针大小通常是CPU的字长大小，不是 32bit 就是 64bit，这取决于你的处理器，指针指向了你的值的精确位置。 对于32位系统，内存最大可使用4G。
64系统可以使用更大的内存。但是64位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存 和 缓存器之间移动数据的时候，会占用更多的带宽。 java 使用一个叫内存指针压缩的技术来解决这个问题。 它的指针不再表示对象在内存中的精确位置，而是表示偏移量。这意味着32位的指针可以引用40亿个对象，而不是40亿个字节。最终，也就是说堆内存长到32G的物理内存，也可以用 32bit 的指针表示。 一旦你越过那个神奇的 30-32G 的边界，指针就会切回普通对象的指针，每个对象的指针都变长了，就会使用更多的 CPU、内存、带宽，也就是说你实际上失去了更多的内存。
事实上当内存到达40-50GB的时候，有效内存才相当于使用内存对象指针压缩技术时候的32G内存。
结论就是：即便你有足够的内存，也尽量不要超过32G，因为它浪费了内存，降低了CPU的性能，还要让GC应对大内存。

2：服务器内存使用详解

2.1：Elasticsearch内存分配

Elasticsearch默认安装后设置的堆内存是1GB，实际业务肯定不够，需要进行配置，不要超过32G
因为如果堆大小小于 32 GB，JVM 可以利用指针压缩，这可以大大降低内存的使用：每个指针 4 字节而不是 8 字节。如果大于32G 每个指针占用 8字节，并且会占用更多的内存带宽，降低了cpu性能。
每G管理分片数不超过20，即可推理总分片数。

xmx-JVM最大允许分配的堆内存，按需分配
xms-JVM初始分配的堆内存
这是我们的配置
-Xmx10g -Xms10g

1：fielddata：顺排索引

fielddata就是存储字段以及字段的类型。会消耗大量的JVM内存，几个g是正常的，因此，尽量为JVM设置大的内存，不要为不必要的字段启用fielddata存储。通过format参数控制是否启用字段的fielddata特性，字符类型的分析字段，fielddata的默认值是paged_bytes，这就意味着，默认情况下，字符类型的分析字段启用fielddata存储。一旦禁用fielddata存储，那么字符类型的分析字段将不再支持排序和聚合查询。
** Fielddata 是 延迟 加载也是第二次查询快的原因**。如果你从来没有聚合一个分析字符串，就不会加载 fielddata 到内存中，也就不会使用大量的内存。
如果没有足够的内存保存fielddata时，Elastisearch会不断地从磁盘加载数据到内存，并剔除掉旧的内存数据。剔除操作会造成严重的磁盘I/O，并且引发大量的GC，会严重影响Elastisearch的性能。

1、format属性

fielddata会消耗大量的JVM内存，因此，尽量为JVM设置大的内存，不要为不必要的字段启用fielddata存储。通过format参数控制是否启用字段的fielddata特性，字符类型的分析字段，fielddata的默认值是paged_bytes，这就意味着，默认情况下，字符类型的分析字段启用fielddata存储。一旦禁用fielddata存储，那么字符类型的分析字段将不再支持排序和聚合查询。
2、加载属性（loading）

loading属性控制fielddata加载到内存的时机，可能的值是lazy，eager和eager_global_ordinals，默认值是lazy。
lazy：fielddata只在需要时加载到内存，默认情况下，在第一次搜索时，fielddata被加载到内存中；但是，如果查询一个非常大的索引段（Segment），lazy加载方式会产生较大的时间延迟。
eager：在倒排索引的段可用之前，其数据就被加载到内存，eager加载方式能够减少查询的时间延迟，但是，有些数据可能非常冷，以至于没有请求来查询这些数据，但是冷数据依然被加载到内存中，占用紧缺的内存资源。
eager_global_ordinals：按照global ordinals积极把fielddata加载到内存。

• 获取filebeat

GET /_stats/fielddata?fields=*

Fielddata是堆内存的最大使用者之一，因此也是内存不足和导致节点不稳定的主要原因之一。
可以限制其在堆内存的空间

2 ：Node Query Cache

(负责缓存filter 查询结果)，每个节点有一个，被所有 shard 共享，filter query查询结果要么是 yes 要么是no，不涉及 scores 的计算。对于读多写少集群可以提高该配置提高命中率。
集群中每个节点都要配置，默认为：indices.queries.cache.size:10%

3 ：Indexing Buffer

索引缓冲区，用于存储新索引的文档，当其被填满时，缓冲区中的文档被写入磁盘中的 segments 中。节点上所有 shard 共享，设置的大小是针对每个分片的，对于写多读少集群可以调大配置。
缓冲区默认大小： indices.memory.index_buffer_size: 10%
如果缓冲区大小设置了百分百则 indices.memory.min_index_buffer_size 用于这是最小值，默认为 48mb。
indices.memory.max_index_buffer_size 用于最大大小，无默认值。

4 ：Shard Request Cache 用于缓存请求结果

2.2：Lucene：segment

服务器总内存除过给jvm配置的其余都给了lucene，占用page cache内存，page cache保存对文件数据segment（segment是shard数据的一部分内容）的缓存。缓存索引的部分数据，用于提升查询响应（segment越大查询的名字率就越高查询性能越高，这也就是es查询响应ms级和s的主要差别所在就是内存）
服务器执行：free -g可查看内存使用，es节点只有es服务，基本cache就是缓存的segment。

lucene详解文档
segment详解
lucene文件内容

3:内存不够解决：ram.percent 达到100%

3.1 es高负载带来的影响

为什么es内存使用率到达75%会下降？

3.2 查看节点内存负载：get _cat/nodes

发现内存被消耗完毕，此时读写均异常

主节点每30秒会去检查其他节点的状态，如果任何节点的垃圾回收时间超过30秒，则会导致主节点任务该节点脱离集群。

1:节点负载详解

节点负载详解

get _cat/nodes?h=ip,cpu,hp,rp,fm,sm,qcm,sqti,rc,rm,dt,du&v
curl -s “ip:9200/_cat/nodes?h=ip,hp,rp,rc,rm,fm,sm,sc,qcm,sqti,dt,du&v”

ip:node.ip
cpu：cpu使用率
hp：堆内存使用
rp：ram.percent,总内存使用量百分比，保持在75%以下最好
rc：Used total memory,使用总内存大小
rm：ram.max：总内存大小
fm：fielsdata.sizeMemoey:字段缓存
sm：segment.memory：segment使用的内存
sc：segments.count：segment的数量
qcm：query_cache.memory_size：查询缓存的内存使用
sqti：search.query_time:查询总用时
dt：disk.total：所有磁盘空间
du：disk.used：使用的磁盘空间

2：问题原因分析：lucene缓存了过多的索引数据:

现在让我们假设您有一个集群，它有三个节点，整体内存压力要高得多。在这个例子中，三个节点中的两个节点在很长一段时间内非常有规律地最大化，一个节点始终徘徊在垃圾收集开始的75%左右。

高内存压力从两个方面影响集群性能:当内存压力升至75%及以上时，可用内存会减少，但是您的集群现在还需要花费一些CPU资源来通过垃圾收集回收内存。
垃圾收集进行时，这些中央处理器资源不可用于处理用户请求。因此，随着系统资源越来越受限，用户请求的响应时间会增加。如果内存压力持续上升并接近100%，
则会使用更的垃圾收集形式，这反过来会极大地影响集群响应时间。

3.3 问题解决

1：减少集群负载：
先减少或停止入库数据，
分片索引的数量，减少副本数
2：集群扩容
3：分析es架构是否合理