记：Elasticsearch 的 告警机制 和 jvm 内存分配

Elasticsearch 的告警机制导致的更新失败问题

总结：由于测试环境资源占用比例过高导致 elasticsearch 触发保护机制，导致的更新失败的问题

Es 告警日志：

查看服务器资源使用情况：

此时 Es 所在的挂载磁盘已经占用了 95%，Es 默认的保护机制：

从告警日志中看到，此时磁盘空间已经到了 90%，达到了高警戒水位线。此时 Elasticsearch 禁止了写操作，导致系统更新 Elasticsearch 资源失败。

如果想紧急恢复，提供以下措施，可以调高告警水位线：

PUT _cluster/settings
{
    "persistent":{
        "cluster.routing.allocation.disk.watermark.low":"90%",
        "cluster.routing.allocation.disk.watermark.high":"95%",
        "cluster.routing.allocation.disk.watermark.flood_stage":"97%"
    }
}

如想应急恢复索引功能，可以通过如下请求消除锁：

PUT */_settings?expand_wildcards=all
{
	"index.blocks.read_only_allow_delete": null
}

在此扩展一下索引块的五种不同的状态：

需要注意，删除索引、删除文档存在的区别：

可以看到删除文档时，并不是真正删除，只是逻辑删除。因此该文档所占用的空间并不会随着删除操作而马上释放，只有等下一次段合并的时候才会被真正的物理删除，这个时候才会释放磁盘空间。但是，在被查询到的文档标记删除的过程中同样需要占用磁盘空间，这个时候，删除操作并没有带来磁盘的资源释放，反而，磁盘使用率上升了，因此在删除过程中，需要保证集群磁盘有足够的余量，因为标记删除需要占用磁盘空间，如果磁盘空间不够，失败的概率还是很大的，严重时候，可能会造成集群崩溃和数据丢失。

所以 index.blocks.read_only_allwo_delete 禁用了删除文档操作，却可以删除索引。

回到最开始的问题，至此可以给出解决方案：

1. 使用 api 暂时上调告警线，恢复正常的索引功能，避免小程序端业务功能瘫痪
2. 整理服务器资源，清理日志文件和不需要用到的备份文件
3. 回调告警水平线

以下为本次整理服务器资源过程中，使用了的 linux 命令：

问题至此已经解决，以下记录本次问题带来的额外收货（问题定位错了，学到的额外知识）。

Elasticsearch 的 Jvm 内存分配为什么建议不大于 31 g（小于 32 g）？

首先我们可以查看一下 es 的启动参数：

[root@funfactory-share-01 ~]# ps -eo pid,user,args | grep "elasticsearch" | grep -v "grep"
29754 es       /data/app/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=SPI,JRE -Xms2g -Xmx2g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.io.tmpdir=/tmp/elasticsearch-7490738416214607905 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=logs/hs_err_pid%p.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=32 -XX:GCLogFileSize=64m -Dlog4j2.formatMsgNoLookups=true -XX:MaxDirectMemorySize=1073741824 -Des.path.home=/data/app/elasticsearch -Des.path.conf=/data/app/elasticsearch/config -Des.distribution.flavor=default -Des.distribution.type=tar -Des.bundled_jdk=true -cp /data/app/elasticsearch/lib/* org.elasticsearch.bootstrap.Elasticsearch -d
29797 es       /data/app/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller

可以看到存在 jvm 启动参数 -Xms2g -Xmx2g ，我们都知道 es 是基于 java 开发的，不同的 es 版本实际上需要不同的 jdk 版本，这个在官网有版本对应。

项目上 test 环境使用的 es 是 7.10 版本的默认的对内存大小为 2g，早些年的版本为 1g。这个配置在 elasticsearch/config/jvm.options 文件中：

## JVM configuration

################################################################
## IMPORTANT: JVM heap size
################################################################
##
## You should always set the min and max JVM heap
## size to the same value. For example, to set
## the heap to 4 GB, set:
##
## -Xms4g
## -Xmx4g
##
## See https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
## for more information
##
################################################################

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

-Xms2g
-Xmx2g

################################################################
## Expert settings
################################################################
##
## All settings below this section are considered
## expert settings. Don't tamper with them unless
## you understand what you are doing
##
################################################################

## GC configuration
8-13:-XX:+UseConcMarkSweepGC
8-13:-XX:CMSInitiatingOccupancyFraction=75
8-13:-XX:+UseCMSInitiatingOccupancyOnly

## G1GC Configuration
# NOTE: G1 GC is only supported on JDK version 10 or later
# to use G1GC, uncomment the next two lines and update the version on the
# following three lines to your version of the JDK
# 10-13:-XX:-UseConcMarkSweepGC
# 10-13:-XX:-UseCMSInitiatingOccupancyOnly
14-:-XX:+UseG1GC
14-:-XX:G1ReservePercent=25
14-:-XX:InitiatingHeapOccupancyPercent=30

## JVM temporary directory
-Djava.io.tmpdir=${ES_TMPDIR}

## heap dumps

# generate a heap dump when an allocation from the Java heap fails
# heap dumps are created in the working directory of the JVM
-XX:+HeapDumpOnOutOfMemoryError

# specify an alternative path for heap dumps; ensure the directory exists and
# has sufficient space
-XX:HeapDumpPath=data

# specify an alternative path for JVM fatal error logs
-XX:ErrorFile=logs/hs_err_pid%p.log

## JDK 8 GC logging
8:-XX:+PrintGCDetails
8:-XX:+PrintGCDateStamps
8:-XX:+PrintTenuringDistribution
8:-XX:+PrintGCApplicationStoppedTime
8:-Xloggc:logs/gc.log
8:-XX:+UseGCLogFileRotation
8:-XX:NumberOfGCLogFiles=32
8:-XX:GCLogFileSize=64m

# JDK 9+ GC logging
9-:-Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m
# BEGIN Log4j
-Dlog4j2.formatMsgNoLookups=true
# END Log4j

这里提供了两种方式修改 elasticsearch 的堆内存。最简单的方法是指定一个环境变量，在服务进程启动的时候指定这个变量的值，设置对应的堆大小，如：

export ES_HEAP_SIZE = 10g

也可以通过命令行参数的形式，在程序启动的时候把内存大小传递给它：

./bin/elasticsearch -Xmx10g -Xms10g

这里需要注意，确保堆内存最大值 Xmx 和最小值 Xms 的大小是相同的，防止程序在运行时改变堆内存的大小，这个是一个很耗资源的过程。

相信大家都听过一个说法：Elasticsearch 的 Jvm 内存分配为什么建议不大于 31 g。那么，为什么？

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

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

对于 32 位的系统，意味着堆内存大小最大为 4 GB。对应 64 位的系统，可以使用更大的内存，但是 64 位的指针，意味着很大的浪费，因为你的指针本身就已经更大了。更大的指针在主内存和各级缓存之间移动数据时，会占用更多的带宽。

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

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

即便你有足够的内存，也尽量不要 超过 32 GB。因为它浪费了内存，降低了 CPU 的性能，还要让 GC 应对大内存。