Elasticsearch:管理和排除 Elasticsearch 内存故障

作者:来自 Elastic Stef Nestor

随着 Elastic Cloud 提供可观察性、安全性和搜索等解决方案,我们将使用 Elastic Cloud 的用户范围从完整的运营团队扩大到包括数据工程师、安全团队和顾问。作为 Elastic 支持代表,我很乐意与各种各样的用户和用例互动。

随着受众的扩大,我看到了更多关于管理资源分配的问题,特别是对分配健康状况​​进行故障排除和避免断路器的问题。我明白了!当我开始使用 Elasticsearch 时,我也有同样的问题。这是我第一次接触管理 Java 堆和时间序列数据库分片以及扩展我自己的基础设施。

当我加入 Elastic 时,我喜欢除了文档之外,我们还有博客和教程,这样我就可以快速上手。但随后,我在第一个月努力将我的理论知识与用户通过我的票务队列发送的错误联系起来。最终,我和其他支持代表一样发现,很多报告的错误只是分配问题的症状,同样的七个链接将使用户快速掌握成功管理其资源分配的方法。

作为一名支持代表,我将介绍我们向用户发送的最重要的分配管理理论链接、我们看到的最重要的症状以及我们指导用户更新他们的配置以解决他们的资源分配问题的地方。

理论

作为 Java 应用程序,Elasticsearch 需要从系统的物理内存中分配一些逻辑内存(堆)。这应该最多是物理 RAM 的一半,上限为 32GB。设置更高的堆使用率通常是为了应对昂贵的查询和更大的数据存储。父熔断器(Parent circuit breaker)默认为 95%,但我们建议在持续达到 85% 后扩展资源。

我强烈推荐这些概述文章以获取更多信息:

  • A heap of trouble
  • Heap: Sizing and swapping

配置

Elasticsearch 的默认设置会根据节点角色和总内存自动调整 JVM 堆的大小。但是,你可以根据需要通过以下三种方式直接配置它:

1. 直接在本地 Elasticsearch 文件的 config > jvm.options 文件中进行配置:

## JVM configuration################################################################
## IMPORTANT: JVM heap size
################################################################…# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space-Xms4g
-Xmx4g

2. 作为 docker-compose 中的 Elasticsearch 环境变量:

version: '2.2'
services:es01:image: docker.elastic.co/elasticsearch/elasticsearch:7.12.0environment:- node.name=es01- cluster.name=es- bootstrap.memory_lock=true- "ES_JAVA_OPTS=-Xms4g -Xmx4g"- discovery.type=single-nodeulimits:memlock:soft: -1hard: -1ports:- 9200:9200

3. 通过我们的 Elastic Cloud Hosted > Deployment > Edit 视图。注意:下拉菜单分配物理内存,大约一半将分配给堆。

故障排除

如果你目前遇到集群性能问题,则最有可能归结为常见原因:

  • 配置问题:主节点规模过小,没有 ILM 策略
  • 容量导致:请求速度/负载过高,重叠的昂贵查询/写入

所有以下 cURL/API 请求都可以在 Elastic Cloud Hosted > Elasticsearch API 控制台中、作为 Elasticsearch API 的 cURL 或在 Kibana > Dev Tools 下进行。

分配健康状况

数据索引存储在子分片中,这些子分片在维护以及搜索/写入请求期间会使用堆内存。分片大小不应超过 50GB。

以上述拥有 8GB 物理内存的两区域 Elastic Cloud 托管示例为例(总共分配两个节点),我们可以用以下命令查看示例:_cat/allocation

GET /_cat/allocation?v=true&h=shards,node
shards node41 instance-000000000141 instance-0000000000

以及:_cluster/health。

GET /_cluster/health?filter_path=status,*_shards{"status": "green","unassigned_shards": 0,"initializing_shards": 0,"active_primary_shards": 41,"relocating_shards": 0,"active_shards": 82,"delayed_unassigned_shards": 0
}

如果任何分片在 active_shards 或 active_primary_shards 之外的报告数 >0,则你已确定了性能问题的原因。

如果报告问题,最常见的情况是 unassigned_shards > 0。如果这些分片是主分片,你的集群将报告为 status:red,如果只有副本,它将报告为 status:yellow。 更多有关这些状态的描述请参考文章 “Elasticsearch 中的一些重要概念: cluster, node, index, document, shards 及 replica”。(这就是为什么在索引上设置副本很重要的原因 —— 如果集群遇到问题,它可以恢复,而不是经历数据丢失。)让我们假设我们有一个带有单个未分配分片的 status:yellow。为了调查,我们将通过 _cat/shards 查看哪个索引分片有问题。

GET _cat/shards?v=true&s=state
index                                 	shard prirep state    	docs   store ip       	node
logs                                  	0 	p  	STARTED     	2  10.1kb 10.42.255.40 instance-0000000001
logs                                  	0 	r  	UNASSIGNED
kibana_sample_data_logs               	0 	p  	STARTED 	14074  10.6mb 10.42.255.40 instance-0000000001
.kibana_1                             	0 	p  	STARTED  	2261   3.8mb 10.42.255.40 instance-0000000001

因此,这将适用于我们的非系统索引日志,这些日志具有未分配的副本分片。让我们通过运行 _cluster/allocation/explain 来查看是什么让它陷入困境。(专业提示:当你升级到我们官方的技术支持时,这正是我们所做的。)

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*
{ "index": "logs","node_allocation_decisions": [{"node_name": "instance-0000000005","deciders": [{"decider": "data_tier","decision": "NO","explanation": "node does not match any index setting [index.routing.allocation.include._tier] tier filters [data_hot]"
}]}]}

此错误消息指向 data_hot,它是索引生命周期管理 (index lifecycle management - ILM) 策略的一部分,表明我们的 ILM 策略与我们当前的索引设置不一致。在这种情况下,此错误的原因是设置了热温(hot-warm) ILM 策略而没有指定热温节点。(我需要保证某些事情会失败,所以这是我为大家强制提供的错误示例。有关更多信息,请参阅此示例故障排除视频以获取解决方案演练。)

如果你在没有任何未分配的分片时运行此命令,你将收到 400 错误,表示无法找到任何未分配的分片来解释,因为没有任何错误需要报告。如果你遇到非逻辑原因(例如,临时网络错误,如分配期间节点离开集群),那么你可以使用 Elastic 的方便的 _cluster/reroute。

POST /_cluster/reroute

此请求未经过自定义,将启动一个异步后台进程,尝试分配所有当前状态为:UNASSIGNED 的分片。(不要像我一样,不等它完成就联系开发人员,因为我以为它会立即发生,而且巧合的是,它会及时升级,让他们说没什么问题,因为什么都没有了。)有关更多信息,请参阅此故障排除视频,以监控分配健康状况​​。

熔断器 - Circuit breakers

堆分配达到最大值可能会导致对集群的请求超时或出错,并且经常会导致集群遇到熔断器异常。熔断器错误会导致 elasticsearch.log 事件,例如:

Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [num/numGB], which is larger than the limit of [num/numGB], usages [request=0/0b, fielddata=num/numKB, in_flight_requests=num/numGB, accounting=num/numGB]
GET /_cat/nodes?v=true&h=name,node*,heap*
# heap = JVM (logical memory reserved for heap)
# ram  = physical memoryname                                node.role heap.current heap.percent heap.max
tiebreaker-0000000002 mv             119.8mb           23    508mb
instance-0000000001   himrst           1.8gb           48    3.9gb
instance-0000000000   himrst           2.8gb           73    3.9gb

或者,如果你之前已启用它,请导航至 Kibana > Stack Monitoring。

如果你已确认自己正在触及内存熔断器,则需要考虑暂时增加堆,以便给自己留出调查的喘息空间。调查根本原因时,请查看集群代理日志或 elasticsearch.log 以查找前面的连续事件。你将寻找:

  • 昂贵的查询,尤其是:
    • 高存储桶聚合
    • 当我发现搜索在根据搜索 size 或 bucket 维度运行查询之前会临时分配堆的某个端口时,我感到非常愚蠢,因此设置 10,000,000 确实让我的运营团队感到心痛。
  • 非优化映射
    • 感到愚蠢的第二个原因是,我认为进行分层报告会比扁平化数据搜索更好(但事实并非如此)。
  • 请求量/速度:通常是批量或异步查询

扩展时间

如果这不是你第一次遇到熔断器,或者你怀疑这将是一个持续存在的问题(例如,持续达到 85%,因此是时候考虑扩展资源了),你需要仔细查看 JVM 内存压力作为长期堆指标。你可以在 Elastic Cloud Hosted > Deployment 中检查这一点。

或者你可以从 _nodes/stats计算它:

GET /_nodes/stats?filter_path=nodes.*.jvm.mem.pools.old{"nodes": { "node_id": { "jvm": { "mem": { "pools": { "old": {"max_in_bytes": 532676608,"peak_max_in_bytes": 532676608,"peak_used_in_bytes": 104465408,"used_in_bytes": 104465408
}}}}}}}

在这里:

JVM Memory Pressure = used_in_bytes / max_in_bytes

这种情况的一个潜在症状是 elasticsearch.log 中的垃圾收集器 (gc) 事件出现频率高且持续时间长:

[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s]

如果你确认了这种情况,则需要考虑扩展集群或减少对集群的需求。你需要调查/考虑:

  • 增加堆资源(堆/节点;节点数)
  • 减少分片(删除不必要/旧数据;使用 ILM 将数据放入热/冷存储中,以便缩小数据;关闭你不关心丢失的数据的副本)

我们随时为你提供帮助

哇哦!从我在 Elastic 支持中看到的情况来看,这是最常见的用户工单的概要:未分配的分片、不平衡的分片堆、熔断器、高垃圾收集和分配错误。所有这些都是核心资源分配管理对话的症状。希望你现在也知道理论和解决步骤。

不过,此时,如果你在解决问题时遇到困难,请随时与我们联系。我们随时为你提供帮助!联系我们:

  • Elastic 讨论
  • Elastic 社区 Slack
  • Elastic 咨询
  • Elastic 培训
  • Elastic 支持

为我们能够以非 Ops(也喜欢 Ops)的身份自行管理 Elastic Stack 的资源分配的能力而欢呼!

原文:Managing and troubleshooting Elasticsearch memory | Elastic Blog

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

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Jmeter基础篇(24)Jmeter目录下有哪些文件夹是可以删除,且不影响使用的呢?

一、前言 Jmeter使我们日常做性能测试最常用的工具之一啦&#xff01;但是我们在和其他同学协同工作的时候&#xff0c;偶尔也会遇到一些问题&#xff0c;例如我想要给别人发送一个Jmeter工具包&#xff0c;但这个文件包往往会很大&#xff0c;比较浪费流量和空间&#xff0c;…

排序算法(基础)大全

一、排序算法的作用&#xff1a; 排序算法的主要作用是将一组数据按照特定的顺序进行排列&#xff0c;使得数据更加有序和有组织。 1. 查找效率&#xff1a;通过将数据进行排序&#xff0c;可以提高查找算法的效率。在有序的数据中&#xff0c;可以使用更加高效的查找算法&…

如何在 WordPress 中轻松强制所有用户退出登录

作为一名长期管理 WordPress 网站的站长&#xff0c;我深知维护网站安全性的重要性。尤其是在面对会员网站或付费内容平台时&#xff0c;确保所有用户的登录状态是最新的&#xff0c;是维持网站正常运营的关键之一。今天&#xff0c;我就分享一下如何通过简单的步骤&#xff0c…

速通前端篇 —— HTML

找往期文章包括但不限于本期文章中不懂的知识点&#xff1a; 个人主页&#xff1a;我要学编程程(ಥ_ಥ)-CSDN博客 所属专栏&#xff1a;速通前端 目录 HTML的介绍 如何创建HTML文件 HTML 文件基本结构 HTML常用标签 title标签 标题标签 h1-h6 段落标签 p 换行标签 b…

当微软windows的记事本被AI加持

1985年&#xff0c;微软发布了Windows 1.0&#xff0c;推出了一款革命性的产品&#xff1a;记事本&#xff08;Notepad&#xff09;。这款软件旨在鼓励使用一种未来主义的新设备——鼠标&#xff0c;并让人们可以不依赖VI等键盘工具就能书写文本和编写代码。记事本因其简洁和高…

LSTM(长短期记忆网络)详解

1️⃣ LSTM介绍 标准的RNN存在梯度消失和梯度爆炸问题&#xff0c;无法捕捉长期依赖关系。那么如何理解这个长期依赖关系呢&#xff1f; 例如&#xff0c;有一个语言模型基于先前的词来预测下一个词&#xff0c;我们有一句话 “the clouds are in the sky”&#xff0c;基于&…

Vulnhub靶场 Billu_b0x 练习

目录 0x00 准备0x01 主机信息收集0x02 站点信息收集0x03 漏洞查找与利用1. 文件包含2. SQL注入3. 文件上传4. 反弹shell5. 提权&#xff08;思路1&#xff1a;ssh&#xff09;6. 提权&#xff08;思路2&#xff1a;内核&#xff09;7. 补充 0x04 总结 0x00 准备 下载链接&#…

重拾CSS,前端样式精读-媒体查询

前言 本文收录于CSS系列文章中&#xff0c;欢迎阅读指正 说到媒体查询&#xff0c;大家首先想到的可能是有关响应式的知识点&#xff0c;除此之外&#xff0c;它还可以用于条件加载资源&#xff0c;字体大小&#xff0c;图像和视频的优化&#xff0c;用户界面调整等等方面&am…

普通用户切换到 root 用户不需要输入密码配置(Ubuntu20)

在 Ubuntu 系统中&#xff0c;允许一个普通用户切换到 root 用户而不需要输入密码&#xff0c;可以通过以下步骤配置 sudo 设置来实现。 步骤&#xff1a; 打开 sudoers 文件进行编辑&#xff1a; 在终端中&#xff0c;输入以下命令来编辑 sudoers 文件&#xff1a; sudo visu…

MySQL系统优化

文章目录 MySQL系统优化第一章&#xff1a;引言第二章&#xff1a;MySQL服务架构优化1. 读写分离2. 水平分区与垂直分区3. 缓存策略 第三章&#xff1a;MySQL配置优化1. 内存分配优化Buffer Pool 的优化查询缓存与表缓存Key Buffer 2. 连接优化最大连接数会话超时连接池 3. 日志…

菲涅耳全息图

菲涅耳全息图&#xff1a;记录介质在物光波场的菲涅耳衍射区(物体到记录介质表面的距离在菲涅耳衍射区内)。 一、点源全息图的记录和再现 1.1 记录 设物光波和参考光波是从点源O(xo, yo, zo)和点源 R(xr, yr, zr)发出的球面波, 波长为λ1, 全息底片位于z0 的平面上, 与两个点源…

多线程-阻塞队列

目录 阻塞队列 消息队列 阻塞队列用于生产者消费者模型 概念 实现原理 生产者消费者主要优势 缺陷 阻塞队列的实现 1.写一个普通队列 2.加上线程安全和阻塞等待 3.解决代码中的问题 阻塞队列 阻塞队列&#xff0c;是带有线程安全功能的队列&#xff0c;拥有队列先进…

css样式:flex布局

文章目录 简介简单使用直接使用一行放不下的换行水平方向上对齐方式竖直方向上对齐方式布局中排列顺序放大比例缩小比例单个元素与其他元素不同的对齐 文章目录 简介简单使用直接使用一行放不下的换行水平方向上对齐方式竖直方向上对齐方式布局中排列顺序放大比例缩小比例单个元…

MySQL LOAD DATA INFILE导入数据报错

1.导入命令 LOAD DATA INFILE "merge.csv" INTO TABLE 报名数据 FIELDS TERMINATED BY , ENCLOSED BY " LINES TERMINATED BY \n IGNORE 1 LINES; 2.表结构 CREATE TABLE IF NOT EXISTS 报名数据 ( pid VARCHAR(100) NOT NULL, 查询日期 VARCHAR(25) NO…

详解模版类pair

目录 一、pair简介 二、 pair的创建 三、pair的赋值 四、pair的排序 &#xff08;1&#xff09;用sort默认排序 &#xff08;2&#xff09;用sort中的自定义排序进行排序 五、pair的交换操作 一、pair简介 pair是一个模版类&#xff0c;可以存储两个值的键值对.first以…

C#从入门到放弃

C#和.NET的区别 C# C#是一个编程语言 .NET .NET是一个在window下创建程序的框架 .NET框架不仅局限于C#,它还可以支持很多语言 .NET包括了2个组件&#xff0c;一个叫CLR(通用语言运行时)&#xff0c;另一个是用来构建程序的类库 CLR 用C写一个程序&#xff0c;在一台8688的机器…

算法复杂度详解

目录 算法定义 复杂度概念 时间复杂度 大O的渐近表示法 空间复杂度 常见复杂度对比 算法定义 算法(Algorithm):就是定义良好的计算过程&#xff0c;他取一个或一组的值为输入&#xff0c;并产生出一个或一组值作为 输出。简单来说算法就是一系列的计算步骤&#xff0c;用来…

AI写作(十)发展趋势与展望(10/10)

一、AI 写作的崛起之势 在当今科技飞速发展的时代&#xff0c;AI 写作如同一颗耀眼的新星&#xff0c;迅速崛起并在多个领域展现出强大的力量。 随着人工智能技术的不断进步&#xff0c;AI 写作在内容创作领域发挥着越来越重要的作用。据统计&#xff0c;目前已有众多企业开始…

电子应用设计方案-12:智能窗帘系统方案设计

一、系统概述 本设计方案旨在打造便捷、高效的全自动智能窗帘系统。 二、硬件选择 1. 电机&#xff1a;选用低噪音、扭矩合适的智能电机&#xff0c;根据窗帘尺寸和重量确定电机功率&#xff0c;确保能平稳拉动窗帘。 2. 轨道&#xff1a;选择坚固、顺滑的铝合金轨道&…

数据结构《栈和队列》

文章目录 一、什么是栈&#xff1f;1.1 栈的模拟实现1.2 关于栈的例题 二、什么是队列&#xff1f;2.2 队列的模拟实现2.2 关于队列的例题 总结 提示&#xff1a;关于栈和队列的实现其实很简单&#xff0c;基本上是对之前的顺序表和链表的一种应用&#xff0c;代码部分也不难。…