网站微营销公司哪家好,广西网站建设与规划,怎么建电子商务网站,erp系统下载作者#xff1a;来自 Elastic Stef Nestor 随着 Elastic Cloud 提供可观察性、安全性和搜索等解决方案#xff0c;我们将使用 Elastic Cloud 的用户范围从完整的运营团队扩大到包括数据工程师、安全团队和顾问。作为 Elastic 支持代表#xff0c;我很乐意与各种各样的用户和…作者来自 Elastic Stef Nestor 随着 Elastic Cloud 提供可观察性、安全性和搜索等解决方案我们将使用 Elastic Cloud 的用户范围从完整的运营团队扩大到包括数据工程师、安全团队和顾问。作为 Elastic 支持代表我很乐意与各种各样的用户和用例互动。
随着受众的扩大我看到了更多关于管理资源分配的问题特别是对分配健康状况进行故障排除和避免断路器的问题。我明白了当我开始使用 Elasticsearch 时我也有同样的问题。这是我第一次接触管理 Java 堆和时间序列数据库分片以及扩展我自己的基础设施。
当我加入 Elastic 时我喜欢除了文档之外我们还有博客和教程这样我就可以快速上手。但随后我在第一个月努力将我的理论知识与用户通过我的票务队列发送的错误联系起来。最终我和其他支持代表一样发现很多报告的错误只是分配问题的症状同样的七个链接将使用户快速掌握成功管理其资源分配的方法。
作为一名支持代表我将介绍我们向用户发送的最重要的分配管理理论链接、我们看到的最重要的症状以及我们指导用户更新他们的配置以解决他们的资源分配问题的地方。 理论
作为 Java 应用程序Elasticsearch 需要从系统的物理内存中分配一些逻辑内存堆。这应该最多是物理 RAM 的一半上限为 32GB。设置更高的堆使用率通常是为了应对昂贵的查询和更大的数据存储。父熔断器Parent circuit breaker默认为 95%但我们建议在持续达到 85% 后扩展资源。
我强烈推荐这些概述文章以获取更多信息
A heap of troubleHeap: 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.namees01- cluster.namees- bootstrap.memory_locktrue- ES_JAVA_OPTS-Xms4g -Xmx4g- discovery.typesingle-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?vtruehshards,node
shards node41 instance-000000000141 instance-0000000000
以及_cluster/health。
GET /_cluster/health?filter_pathstatus,*_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?vtruesstate
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?prettyfilter_pathindex,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 [request0/0b, fielddatanum/numKB, in_flight_requestsnum/numGB, accountingnum/numGB]
GET /_cat/nodes?vtruehname,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_pathnodes.*.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 社区 SlackElastic 咨询Elastic 培训Elastic 支持
为我们能够以非 Ops也喜欢 Ops的身份自行管理 Elastic Stack 的资源分配的能力而欢呼 原文Managing and troubleshooting Elasticsearch memory | Elastic Blog
