线上ES集群参数配置引起的业务异常案例分析

news2024/11/18 17:42:30

作者：vivo 互联网数据库团队- Liu Huang

本文介绍了一次排查Elasticsearch node_concurrent_recoveries 引发的性能问题的过程。

一、故障描述

1.1 故障现象

1. 业务反馈

业务部分读请求抛出请求超时的错误。

2. 故障定位信息获取

  • 故障开始时间

19:30左右开始

  • 故障抛出异常日志

错误日志抛出timeout错误。

  • 故障之前的几个小时业务是否有进行发版迭代。

未进行相关的发版迭代。

  • 故障的时候流量是否有出现抖动和突刺情况。

内部监控平台观察业务侧并没有出现流量抖动和突刺情况。

  • 故障之前的几个小时Elasticsearch集群是否有出现相关的变更操作。

Elasticsearch集群没有做任何相关的变更操作。

1.2 环境

  • Elaticsearch的版本：6.x。

  • 集群规模：集群数据节点超过30+。

二、故障定位

我们都知道Elasticsearch是一个分布式的数据库，一般情况下每一次查询请求协调节点会将请求分别路由到具有查询索引的各个分片的实例上，然后实例本身进行相关的query和fetch，然后将查询结果汇总到协调节点返回给客户端，因此存在木桶效应问题，查询的整体性能则是取决于是查询最慢的实例上。所以我们需要确认导致该故障是集群整体的问题还是某些实例的问题导致的。

2.1 集群还是实例的问题

1. 查看所有实例的关键监控指标

图片

图片

从监控图可以很明显的绿色监控指标代表的实例在19:30左右开始是存在异常现象，在这里我们假设该实例叫做A。

  • 实例A的指标es.node.threadpool.search.queue的值长时间达到了1000，说明读请求的队列已经满了。

  • 实例A的指标es.node.threadpool.search.rejected的值高峰期到了100+，说明实例A无法处理来自于业务的所有请求，有部分请求是失败的。

  • 集群整体的指标es.node.threadpool.search.completed有出现增长，经过业务沟通和内部平台监控指标的观察，业务流量平缓，并没有出现抖动现象，但是客户端有进行异常重试机制，因此出现增长是因为重试导致。

  • 实例A的指标es.node.threadpool.search.completed相比集群其他实例高50%以上，说明实例A上存在一个到多个热点索引。

  • 实例A的指标es.node.threadpool.cpu.percent的值有50%以上的增长。

  • 可通过指标es.node.indices.search.querytime和es.node.indices.search.querytimeinmillis的趋势可实例级别的请求耗时大致情况。

通过上面的分析，我们能给确认的是实例A是存在异常，但是导致业务请求超时是否是实例A异常导致，还需进一步分析确认。

2.2 实例异常的原因

到了这一步，我们能够非常明确实例是存在异常情况，接下来我们需要定位是什么导致实例异常。在这里我们观察下实例所在机器的MEM.CACHED、DISK.nvme0n1.IO.UTIL、CPU.SERVER.LOADAVG.PERCORE、CPU.IDLE这些CPU、MEMMORY、DISK IO等指标。

图片

1. CPU or IO

通过监控，我们可以很明显的看得到，DISK.nvme0n1.IO.UTIL、CPU.SERVER.LOADAVG.PERCORE、CPU.IDLE这三个监控指标上是存在异常情况的。

DISK.nvme0n1.IO.UTIL上深红色和深褐色指标代表的机器IO使用率存在异常，在这里我们假设深红色的机器叫做X，深褐色的机器叫做Y。

CPU.SERVER.LOADAVG.PERCORE和CPU.IDLE这俩个反应CPU使用情况的指标上代表绿色的机器在存在异常，在这里我们假设绿色的机器叫做Z。

  • 机器X的IO在故障时间之前就处于满载情况，机器X在整个过程当中是没有出现波动，因此可移除机器X可能导致集群受到影响。

  • 机器Y的IO在故障时间之前是处于满载情况，但是在故障期间IO使用率差不多下降到了50%，因此可移除机器Y可能导致集群受到影响。

  • 机器Z的CPU使用率在在故障期间直线下降，CPU.IDLE直接下降到个位数；CPU.SERVER.LOADAVG.PERCORE（是单核CPU的平均负载，2.5表示当前负载是CPU核数*2.5）直接增长了4倍，此时整个机器几乎都是处于阻塞的情况；DISK.nvme0n1.IO.UTIL则是从20%增长到了50%左右。其中CPU的指标是直线增长，IO的指标则是一个曲线增长。

异常实例A所在的机器是Z，目前机器Z的CPU和IO都存在增长情况，其中CPU已经到了系统的瓶颈，系统已经受到了阻塞，IO的利用率从20%增长到了50%，虽然有所增长，但是还未到达磁盘的瓶颈。

通过上面的分析，我们比较倾向于机器Z的CPU的异常导致了实例A的异常。这个时候我们需要确认是什么原因导致了机器Z的CPU异常，这个时候可通过内部监控平台的快照查看机器Z的快照信息。

图片

通过内部监控平台的快照，我们可以看到PID为225543的CPU使用率是2289.66%，166819的CPU的使用率是1012.88%。需要注意的是我们机器Z的逻辑核是32C，因此我们可认为CPU机器CPU的使用率理论上最高是3200%。但是使用率CPU最高的俩个实例的值加起来已经是超过了这个值，说明CPU资源已经是完全被使用完毕了的。

通过登陆机器Z，查询获取得到PID为225543的进程就是实例A的elasticsearch进程。

2. 实例CPU异常的原因

其实Elasticsearch本身是有接口提供获取实例上的热点进程，但是当时执行接口命令的时候长时间没有获取到结果，因此只能从其他方案想办法了。

获取实例上的热点进程：

curl -XGET /_nodes/xx.xx.xx.xx/hot_threads?pretty -s

实例A的CPU使用率高一般导致这个情况原因一个是并发过高导致实例处理不过来，另外一个则是存在任务长时间占据了进程资源，导致无多余的资源处理其他的请求。所以我们首先基于这俩个情形进行分析。

（1）是否并发度过高引起实例CPU异常

从之前的分析我们可以得知业务侧的流量是没有出现突增，search.completed的增长只是因为业务重试机制导致的，因此排除并发过高的原因了，那么剩下的就只有存在长任务的原因了

（2）是否长任务导致实例CPU异常

根据_cat/tasks查看当前正在执行的任务，默认会根据时间进行排序，任务running时间越长，那么就会排到最前面，上面我们得知异常的实例只有A，因此我们可以只匹配实例A上的任务信息。

curl -XGET '/_cat/tasks?v&s=store' -s | grep A

一般情况下大部分任务都是在秒级以下，若是出现任务执行已超过秒级或者分钟级的任务，那么这个肯定就是属于长任务。

（3）什么长任务比较多

根据接口可以看得到耗时较长的都是relocate任务，这个时候使用查看接口/_cat/shards查看分片迁移信息，并且并发任务还很多，持续时间相较于其他任务来说很长。

curl -XGET '/_cat/shards?v&s=store' -s | grep A

由于当时是优先恢复业务，因此没有截图，最后只能从监控获取得到这个时间是有进行relocate分片的迁移操作：

  • es.node.indices.segment.count：实例级别segment的个数。

  • es.cluster.relocatingshards：集群级别正在进行relocate的分片数量。

图片

（4）什么原因导致了分片迁移变多

 根据日常的运维，一般出现分片迁移的情况有：

  • 实例故障。

  • 人工进行分片迁移或者节点剔除。

  • 磁盘使用率达到了高水平位。

根据后续的定位，可以排除实例故障和人工操作这俩项，那么进一步定位是否由于磁盘高水平位导致的。

查看实例级别的监控：

图片

查看master的日志：

[xxxx-xx-xxT19:43:28,389][WARN ][o.e.c.r.a.DiskThresholdMonitor] [master] high disk watermark [90%] exceeded on [ZcphiDnnStCYQXqnc_3Exg][A][/xxxx/data/nodes/0] free: xxxgb[9.9%], shards will be relocated away from this node
[xxxx-xx-xxT19:43:28,389][INFO ][o.e.c.r.a.DiskThresholdMonitor] [$B] rerouting shards: [high disk watermark exceeded on one or more nodes]

根据监控和日志能够进一步确认是磁盘使用率达到了高水平位从而导致的迁移问题。

（5）确认引起磁盘上涨的实例

通过内部监控平台的DB监控，查看机器级别上所有实例的监控指标

es.instance.data_size：

图片

通过监控我们分析可以得到浅黄色、深蓝色、浅绿色三个实例是存在较大的磁盘数据量大小的增长情况，可以比较明显导出磁盘增长到90%的原因是浅黄色线代表的实例导致的原因。

2.3 根因分析

针对实例A磁盘波动情况进行分析：

图片

查看这个监控图，你会发现存在异常：

  • 磁盘数据量的下降和上升并不是一个缓慢的曲线。

  • 2023-02-07 19:20左右也发生过磁盘下降的情况。

出现磁盘的下降和趋势一次性比较多的情况，根据以往的经验存在：

  • 大规模的刷数据。

  • relocate的分片是一个大分片。

  • relocate并发数比较大。

第一个排除了，大规模的刷数据只会导致数据上升，并不会出现数据下降的情况，因此要么就是大分片，要么就是并发较大。

查看是否存在大分片：

# curl -XGET '/_cat/shards?v&s=store' -s | tail
index_name                            4     r      STARTED 10366880  23.2gb
index_name                            4     p      STARTED 10366880  23.2gb
index_name                            0     r      STARTED 10366301  23.2gb
index_name                            0     p      STARTED 10366301  23.2gb
index_name                            3     p      STARTED 10347791  23.3gb
index_name                            3     r      STARTED 10347791  23.3gb
index_name                            2     p      STARTED 10342674  23.3gb
index_name                            2     r      STARTED 10342674  23.3gb
index_name                            1     r      STARTED 10328206  23.4gb
index_name                            1     p      STARTED 10328206  23.4gb

查看是否存在重定向并发数较大：

# curl -XGET '/_cluster/settings?pretty'
{
... ...
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "node_concurrent_recoveries" : "5",
          "enable" : "all"
        }
      }
    }
  }
}

发现参数cluster.allocation.node_concurrent_recoveries设置成了5，我们看下官方针对这个参数的解释：Cluster Level Shard Allocation | Elasticsearch Guide [6.3] | Elastic

大致意思是同一个时间允许多个的分片可以并发的进行relocate或者recovery，我们就按照较大的分片数量20G*5，差不多就是100G左右，这个就解释了为什么data_size的增长和下降短时间内非常大的数据量的原因了。

到目前为止，我们能够确认的是因为分片迁移的问题消耗了实例A很大的CPU资源，从而导致实例A的CPU指标非常的高。

三、解决方案

基于上面的分析，我们假设由于实例A的异常导致集群整的异常；基于这种假设，我们尝试将实例A剔除集群，观察集群和业务的请求是否能够恢复。

3.1 猜想验证

将实例的分片迁移到其他的实例上，执行以下命令之后，可以明显的发现实例上的请求基本上下降为零了，并且业务反馈超时也在逐步的减少，基于这个情况验证了我们的猜想，是实例A的异常导致了业务的请求超时的情况。

curl -XPUT  /_cluster/settings?pretty -H 'Content-Type:application/json' -d '{
    "transient":{
        "cluster.routing.allocation.exclude._ip": "xx.xx.xx.xx"
    }
}'

图片

3.2 根本解决

猜想验证确认之后，那我们现在基于实例A的CPU的异常结果进行相关的优化：

修改参数cluster.routing.allocation.node_concurrent_recoveries

  • 该参数默认值是2，一般是不建议修改这个参数，但是有需要快速迁移要求的业务可以动态修改这个参数，建议不要太激进，开启之后需要观察实例、机器级别的CPU、磁盘IO、网络IO的情况。

修改参数cluster.routing.use_adaptive_replica_selection

  • 开启该参数之后，业务针对分片的读取会根据请求的耗时的响应情况选择下次请求是选择主分片还是副分片。

  • 6.3.2版本默认是关闭了该参数，业务默认会轮询查询主副分片，这在部分实例异常的情况会影响集群的整体性能。针对生产环境、单机多实例混合部署的情况下，建议开启该参数，对集群的性能有一定的提高。

  • 7.x的版本默认是开启了这个参数。

curl -XPUT  /_cluster/settings?pretty -H 'Content-Type:application/json' -d '{
    "transient":{
        "cluster.routing.allocation.node_concurrent_recoveries": 2,
        "cluster.routing.use_adaptive_replica_selection":true   
    }
}'

直接扩容或者迁移实例也是比较合适的。

四、总结

在本次故障，是由于集群参数配置不正确，导致集群的一个实例出现异常从而导致了业务的请求异常。但是在我们在进行故障分析的时候，不能仅仅只是局限于数据库侧，需要基于整个请求链路的分析，从业务侧、网络、数据库三个方面进行分析：

  • 业务侧：需确认业务的所在的机器的CPU、网络和磁盘IO、内存是否使用正常，是否有出现资源争用的情况；确认JVM的gc情况，确认是否是因为gc阻塞导致了请求阻塞；确认流量是否有出现增长，导致Elasticsearch的瓶颈。

  • 网络侧：需确认是否有网络抖动的情况。

  • 数据库侧：确认是Elasticsearch是否是基于集群级别还是基于实例级别的异常；确认集群的整体请求量是否有出现突增的情况；确认异常的实例的机器是否有出现CPU、网络和磁盘IO、内存的使用情况。

确认哪方面的具体故障之后，就可以进一步的分析导致故障的原因。

参数控制：

Elasticsearch本身也有一些参数在磁盘使用率达到一定的情况下来控制分片的分配策略，默认该策略是开启的，其中比较重要的参数：

  • cluster.routing.allocation.disk.threshold_enabled：默认值是true，开启磁盘分分配决策程序。

  • cluster.routing.allocation.disk.watermark.low：默认值85%，磁盘使用低水位线。达到该水位线之后，集群默认不会将分片分配达到该水平线的机器的实例上，但是新创建的索引的主分片可以被分配上去，副分片则不允许。

  • cluster.routing.allocation.disk.watermark.high：默认值90%，磁盘使用高水位线。达到该水位线之后，集群会触发分片的迁移操作，将磁盘使用率超过90%实例上的分片迁移到其他分片上。

  • cluster.routing.allocation.disk.watermark.high：默认值95%。磁盘使用率超过95%之后，集群会设置所有的索引开启参数read_only_allow_delete，此时索引是只允许search和delete请求。

补充：

一旦一台机器上的磁盘使用率超过了90%，那么这台机器上所有的ES实例所在的集群都会发起分片的迁移操作，那么同一时间发起并发的最大可能是：ES实例数*cluster.routing.allocation.node_concurrent_recoveries，这个也会导致机器的CPU、IO等机器资源进一步被消耗，从而所在的实例性能会更差，从而导致路由到机器上实例的分片的性能会更差。

一旦一台机器上磁盘使用率超过95%，那么这台机器上所有的实例所在的集群都会开启集群级别的参数read_only_allow_delete，此时不仅仅是一个集群，而是一个或者多个集群都无法写入，只能进行search和delete。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1241890.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

tp8 使用rabbitMQ

tp8 使用rabbitMQ

php8.0 使用 rabbitmq 要使用 3.6版本以上的&#xff0c; 并且还要开启 php.ini中的 socket 扩展 php think make:command SimpleMQProduce //创建一个生产者命令行 php think make:command SimpleMQConsumer //创建一个消费者命令行 生产者代码 <?php declare (strict_ty…
阅读更多...
2014年10月6日 Go生态洞察：Go在Google I/O和Gopher SummerFest的应用

2014年10月6日 Go生态洞察：Go在Google I/O和Gopher SummerFest的应用

&#x1f337;&#x1f341; 博主猫头虎&#xff08;&#x1f405;&#x1f43e;&#xff09;带您 Go to New World✨&#x1f341; &#x1f984; 博客首页——&#x1f405;&#x1f43e;猫头虎的博客&#x1f390; &#x1f433; 《面试题大全专栏》 &#x1f995; 文章图文…
阅读更多...
Oracle-客户端连接报错ORA-12545问题

Oracle-客户端连接报错ORA-12545问题

问题背景: 用户在客户端服务器通过sqlplus通过scan ip登陆访问数据库时&#xff0c;偶尔会出现连接报错ORA-12545: Connect failed because target host or object does not exist的情况。 问题分析&#xff1a; 首先&#xff0c;登陆到连接有问题的客户端数据库上&#xff0c;…
阅读更多...
redis-cluster集群模式

redis-cluster集群模式

Redis-cluster集群 1 Redis3.0引入的分布式存储方案 2集群由多个node节点组成,redis数据分布在节点之中,在集群之中分为主节点和从节点3集群模式当中,主从一一对应,数据写入和读取与主从模式一样&#xff0c;主负责写&#xff0c;从只能读4集群模式自带哨兵模式&#xff0c;可…
阅读更多...
Java开源ETL工具-Kettle

Java开源ETL工具-Kettle

一、背景 公司有个基于Kettle二次开发产品主要定位是做一些数据ETL的工作, 所谓的ETL就是针对数据进行抽取、转换以及加载的过程&#xff0c;说白了就是怎么对原始数据进行清洗&#xff0c;最后拿到我们需要的、符合规范的、有价值的数据进行存储或者分析的过程。 一般处理ETL的…
阅读更多...
【Vue入门篇】基础篇—Vue指令，Vue生命周期

【Vue入门篇】基础篇—Vue指令，Vue生命周期

&#x1f38a;专栏【JavaSE】 &#x1f354;喜欢的诗句&#xff1a;更喜岷山千里雪 三军过后尽开颜。 &#x1f386;音乐分享【如愿】 &#x1f384;欢迎并且感谢大家指出小吉的问题&#x1f970; 文章目录 &#x1f354;Vue概述&#x1f384;快速入门&#x1f33a;Vue指令⭐v-…
阅读更多...
首批！创邻科技入选《图数据库金融应用场景优秀案例》

首批！创邻科技入选《图数据库金融应用场景优秀案例》

11月11日&#xff0c;“全球金融科技中心网络年会”在第三届全球金融科技大会暨第五届成方金融科技论坛上成功在京举办。会上&#xff0c;北京前沿金融监管科技研究院发布了基于国际标准组织——国际关联数据基准委员会&#xff08;LDBC&#xff09;的《图数据库金融应用场景优…
阅读更多...
vivado联合modelsim测试覆盖率

vivado联合modelsim测试覆盖率

&#xff08;1&#xff09;配置环境 安装modelsim和vivado。点击vivado菜单栏中的tools&#xff0c;在下拉选项中选择compile simulation libraries。simulator选项选择&#xff1a;modelsim simulator。compile library location表示编译库存放的路径。simulator executable p…
阅读更多...
CSGO搬砖干货，全网最详细教学！

CSGO搬砖干货，全网最详细教学！

CSGO游戏搬砖全套操作流程及注意事项&#xff08;第一课&#xff09; 在电竞游戏中&#xff0c;CSGO&#xff08;Counter-Strike: Global Offensive&#xff09;被广大玩家誉为经典之作。然而&#xff0c;除了在游戏中展现个人实力和团队合作外&#xff0c;有些玩家还将CSGO作为…
阅读更多...
前向传播与损失函数

前向传播与损失函数

在机器学习和深度学习中&#xff0c;前向传播和损失函数是两个关键概念。它们在神经网络的训练过程中起着重要的作用&#xff0c;帮助模型学习和优化参数。 一、前向传播 前向传播是机器学习和深度学习中一种信息传递的过程。在神经网络中&#xff0c;前向传播指的是将输入数…
阅读更多...
【追求卓越10】算法--跳表

【追求卓越10】算法--跳表

引导 在上一节中&#xff0c;我们学习到二分查找&#xff0c;惊叹于它超高的效率&#xff08;时间复杂度为O(logn)&#xff09;。但是二分查找有一个局限性就是依赖于数组&#xff0c;这就导致它应用并不广泛。 那么适用链表是否可以做到呢&#xff1f;答案是可以的。只不过要复…
阅读更多...
c语言：回文字符串

c语言：回文字符串

题目&#xff1a; 思路&#xff1a; 创建一个字符数组&#xff0c;然后判断字符串长度&#xff0c;用循环&#xff0c;看对应字符是否相等&#xff0c;相等则输出&#xff0c;不相等则将对应字符ascll较大的改成ascll较小的&#xff08;题目要求字典最小的情况&#xff09;。…
阅读更多...
【MySQL】内连接和外连接

【MySQL】内连接和外连接

内连接和外连接 前言正式开始内连接外连接左外连接右外连接 前言 前一篇讲多表查询的时候讲过笛卡尔积&#xff0c;其实笛卡尔积就算一种连接&#xff0c;不过前一篇讲的时候并没有细说连接相关的内容&#xff0c;本篇就来详细说说表的连接有哪些。 本篇博客中主要用到的还是…
阅读更多...
WifiManager的getConnectionInfo被弃用了？快来使用ConnectivityManager获取更全的网络信息吧

WifiManager的getConnectionInfo被弃用了？快来使用ConnectivityManager获取更全的网络信息吧

前言 最近在使用flutter写桌面端的一个adb工具&#xff0c;可以使用adb命令无线连接设备&#xff0c;需要电脑和手机在同一局域网内&#xff0c;但是需要手机的ip地址。于是我想到写一个android桌面小组件&#xff0c;点一下就获取WiFi的ipv4地址并显示出来&#xff0c;先去找…
阅读更多...
提升性能测试效率：JMeter中的用户自定义变量！

提升性能测试效率：JMeter中的用户自定义变量！

前言 在测试过程中&#xff0c;我们经常会碰到测试服务地址有改动的情况&#xff0c;为了方便&#xff0c;我们会把访问地址参数化&#xff0c;当访问地址变化了&#xff0c;我们只需要把参数对应的值改动一下就可以了。 一&#xff1a;添加配置元件-用户定义的变量&#xff…
阅读更多...
P8599 [蓝桥杯 2013 省 B] 带分数(dfs+全排列+断点判断)

P8599 [蓝桥杯 2013 省 B] 带分数(dfs+全排列+断点判断)

思路&#xff1a;1.深度枚举所有排列情况 2.设置为每个排列设置两个断点&#xff0c;分为三部分&#xff1a;a,b,c 3.转换为乘法判断条件&#xff0c;满足加一 代码如下&#xff1a;&#xff08;可用next_permutation全排列函数代替dfs&#xff09; #include<iostream>…
阅读更多...
精通Nginx（18）-FastCGI/SCGI/uWSGI支持

精通Nginx（18）-FastCGI/SCGI/uWSGI支持

最初用浏览器浏览的网页只能是静态html页面。随着社会发展，动态获取数据、操作数据需要变得日益强烈，CGI应运而生。CGI（Common Gateway Interface）公共网关接口，是外部扩展应用程序与静态Web服务器交互的一个标准接口。它可以使外部程序处理浏览器送来的表单数据并对此作出…
阅读更多...
TypeScript 学习笔记 第三部分 贪吃蛇游戏

TypeScript 学习笔记 第三部分 贪吃蛇游戏

尚硅谷TypeScript教程&#xff08;李立超老师TS新课&#xff09; 1. 创建开发环境 创建工程&#xff0c;使用学习笔记的第二部分安装css部分 npm i -D less less-loader css-loader style-loader对css部分处理&#xff0c;能够运行在低版本浏览器 npm i -D postcss postcss…
阅读更多...
数据结构与算法编程题14

数据结构与算法编程题14

设计一个算法&#xff0c;通过一趟遍历在单链表中确定值最大的结点。 #include <iostream> using namespace std;typedef int Elemtype; #define ERROR 0; #define OK 1;typedef struct LNode {Elemtype data; //结点保存的数据struct LNode* next; //结构体指针…
阅读更多...
每日一题 1410. HTML 实体解析器（中等，模拟）

每日一题 1410. HTML 实体解析器（中等，模拟）

模拟&#xff0c;没什么好说的 class Solution:def entityParser(self, text: str) -> str:entityMap {&quot;: ",&apos;: "",>: >,<: <,&frasl;: /,&amp;: &,}i 0n len(text)res []while i < n:isEntity Falseif …
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023