资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/浅谈某运维平台ES优化之路

浅谈某运维平台ES优化之路

IT那活儿 / 3356人阅读
浅谈某运维平台ES优化之路
点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

  
近期的某一天凌晨三点我收到一条ES异常告警，登录环境发现ES节点数在正常和异常间反复横跳，查看日志发现数据节点与master节点通信异常，出现数据节点频繁上下线的情况，ES集群压力山大，处理恢复后续又多次出现了该问题，ES优化刻不容缓，以下我就此分享下ES的优化方案。





优化方案



1. 索引分片数优化

首先我们先看一下ES集群的整体情况，ES共24个节点，其中6个master节点，18个data节点，数据量11.9TB，但是索引数达到了12817，分片数量达到了53617，了解ES的同学肯定知道，这样的分片数肯定是远超了官方建议的。
我们先看看为什么会有这么多索引和分片数，索引设置是否合理。
以索引domp_10000_zhuji-messages为例，可见索引分片数为1，副本数为1，数据量最大的不过10M，一般来说日志类的索引一个分片可以承载30G左右的数据，可见domp_10000_zhuji-messages这样数据量的索引完全没有必要做日索引。
与应用沟通得知索引domp_10000_zhuji-messages保留周期为90天，意味着domp_10000_zhuji-messages索引就能占180个分片，如果我们将其改造为月索引，单个索引数据量预估在300M左右，一个分片也是完全够用，那么此时在保留周期内我们只需要6个分片就可以满足需求，分片数量直接减少了30倍。
应用到整个集群，索引数和分片数量将大幅度的减少，从而可减轻ES集群不小的压力。
2. 减少监控采集频率
查看日志会发现ES监控索引数据写入被拒绝，监控这块的写入比较大。
查看监控索引大小，居然能达到40G以上，这对ES的压力可想而知还是比较大的。
ES默认的采集频率为10S，我们将调整采集频率调整为60S，减少监控对ES产生的压力。
curl  -u elastic:elastic -H Content-Type: application/json -XPUT 
http://XXX.XXX.XXX.101:9206/_cluster/settings  -d {"persistent": {"xpack.monitoring.collection.interval":"60s"}}
ES在7.0后需要在kibana.yml配置文件中加入xpack.monitoring.min_interval_seconds参数，需与ES集群配置的采集频率相同，加了之后可别忘了重启kibana。
必要的话也可以放弃对索引的监控，只收集集群元数据，调整参数xpack.monitoring.collection.indices":".*"，指定需要监控的索引，默认是监控所有索引。





查询优化



ES集群压力如此之大，当时在跑什么查询？
我们可以通过查看慢查询日志，查看当时的查询情况。
/*
慢查询日志添加方式,时间级别可根据实际情况而定。
PUT _all/_settings {
"index.indexing.slowlog.threshold.index.warn": "10s",
"index.indexing.slowlog.threshold.index.info": "5s",
"index.indexing.slowlog.threshold.index.debug": "2s",
"index.indexing.slowlog.threshold.index.trace": "500ms",
"index.indexing.slowlog.level": "info",
"index.indexing.slowlog.source": "true"
}
**/
通过慢日志，我们可以发现当时主要语句为:
以上查询使用用了ES中的in查询，in中id数量远超1024，默认情况下参数indices.query.bool.max_clause_count值为1024，此参数限制大查询占用过多的CPU和内存，此查询远超此限制将占用大量的CPU和内存资源。
整改方法：采用循环查询，一次取100个id的 数据，经测试查询总耗时与原方法无较大差异，资源消耗却大大减少。
并且针对大索引的查询，应用程序之前是使用from-size，from-size的工作原理是：如size=10&from=100，那么ElasticSearch会从每个Shard里取出100条数据，然后再排序，取出前10条。
由此观之，当索引非常大时，from-size查询对集群的压力会特别高，相对于from和size的分页来说，使用scroll可以模拟一个传统数据的游标，记录当前读取的文档信息位置。所以scroll查询能大大降低集群的压力。

本文作者：刘 能（上海新炬王翦团队）

本文来源：“IT那活儿”公众号

GPU云服务器 云服务器 设计浅谈 浅谈javascript 搭建平台优化服务器 浅谈sdwan解决方案

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129401.html

相关文章

  • 乐心医疗的 Kubernetes云平台建设实践

    摘要：宋体自年被开源以来，很快便成为了容器编排领域的标准。宋体年月，乐心医疗的第一个生产用集群正式上线。所以于年推出后，乐心医疗的运维团队在开会讨论之后一致决定尽快迁移到。Kubernetes 自 2014 年被 Google 开源以来，很快便成为了容器编排领域的标准。因其支持自动化部署、大规模可伸缩和容器化管理等天然优势，已经被广泛接纳。但由于 Kubernetes 本身的复杂性，也让很多企业的...

    testHs 评论0 收藏0

  • 某熊的技术之路指北 ☯

    某熊的技术之路指北 ☯ 当我们站在技术之路的原点，未来可能充满了迷茫，也存在着很多不同的可能；我们可能成为 Web/(大)前端/终端工程师、服务端架构工程师、测试/运维/安全工程师等质量保障、可用性保障相关的工程师、大数据/云计算/虚拟化工程师、算法工程师、产品经理等等某个或者某几个角色。某熊的技术之路系列文章/书籍/视频/代码即是笔者蹒跚行进于这条路上的点滴印记，包含了笔者作为程序员的技术视野、...

    shadowbook 评论0 收藏0

  • 前端资源收集整理

    摘要：工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 Github版本：Front-End Resource Collection 前端相关资源汇总 学习指导 精华文章 Web前端的路该怎么走？：文章超长，但是干货超级多，值得反复精读！ 听说2017你想写前端？：适合于已经度过了小白阶...

    awesome23 评论0 收藏0

  • 前端资源收集整理

    摘要：工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 Github版本：Front-End Resource Collection 前端相关资源汇总 学习指导 精华文章 Web前端的路该怎么走？：文章超长，但是干货超级多，值得反复精读！ 听说2017你想写前端？：适合于已经度过了小白阶...

    antyiwei 评论0 收藏0

  • 前端资源收集整理

    摘要：工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 工作原因，最近一年断断续续写了一点前端代码，收集整理了一些资料，和大家共享。 Github版本：Front-End Resource Collection 前端相关资源汇总 学习指导 精华文章 Web前端的路该怎么走？：文章超长，但是干货超级多，值得反复精读！ 听说2017你想写前端？：适合于已经度过了小白阶...

    KavenFan 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<