ES7.5升级7.17后在写多读少场景下CPU、IO飙升

简介: ES PAAS管理的集群升级了100+,从7.5升级到7.17 (保证每个大版本最终仅维护一个小版本集群),由于业务使用差异大,也出了不少问题,前面的文章也有提到过Integer类型字段使用terms查询效率低的情况...

背景

1.ES PAAS管理的集群升级了100+,从7.5升级到7.17 (保证每个大版本最终仅维护一个小版本集群)


2.由于业务使用差异大,也出了不少问题,前面的文章也有提到过Integer类型字段使用terms查询效率低的情况


3.这里再分析一个CPU、IO飙升的场景


现象

1.用户报障:“ES集群写入吞吐量变小了”


2.观察下来发现确实CPU高了,IO也有明显抖动

1.png

2.png


排查与分析

1.发现YoungGC频率变高了一些,猜测可能是G1GC的问题(我们使用JDK11重新打了ES镜像),经过版本替换,没有明显变化。


参考issue:Fix G1 GC default IHOP by henningandersen · Pull Request #46169 · elastic/elasticsearch · GitHub


这可能是另一个场景的case,经过测试,不属于我们的场景。


2.多次执行hot_threads API观察, 发现时不时会出现 update相关函数 消耗的 CPU多。


3.继续使用arthas抓取一段时间的数据,发现是 FST、DocID 读取慢

3.png

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。


4.集群写多读少,使用的是niofs。可知,7.5版本的FST是在堆外,但是_id字段是在堆内。升级到7.17版本后,FST在堆外,该字段也放到了堆外(官方版本应该是7.9就开始放到堆外了)。数据放到堆外,其实也就是文件放到磁盘,读一次之后放到pagecache。


这样也就可以解释了,在upsert类请求多的时候会频繁查询docId,此时如果_id字段没有进入pageCache或者被踢出pageCache,那么就会出现响应慢,并且CPU高、IO高的情况。


5.mmapfs、hybridfs实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障。


测试验证

将FST、BKD等全部改成放到堆内(开源版需要改造)

4.png


可以看到,CPU有显著下降,也相对均衡。(之前蓝色线高,是因为该节点有大量的主分片)


结论

1.update、upsert、get等请求如果十分频繁,_id使用offheap将不会是个好的选择,除非给足够的堆外内存,并且保证尽可能常驻内存。


2.不同的业务场景下使用ES的同一版本也会有不一样的效果。


3.mmapfs、hybridfs在频繁update情况下,实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障,可能不会有这么明显的差距。(官方描述写入速度仅降低了1.8%)


4.最后吐槽一下,写入不停的情况下,translog的恢复实在是太慢了,由于大分片恢复/rebalance时,translog不会被清理,导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。



相关文章
|
12月前
|
并行计算 数据处理 Python
Python并发编程迷雾:IO密集型为何偏爱异步?CPU密集型又该如何应对?
在Python的并发编程世界中,没有万能的解决方案,只有最适合特定场景的方法。希望本文能够为你拨开迷雾,找到那条通往高效并发编程的光明大道。
157 2
|
开发框架 并行计算 算法
揭秘Python并发神器:IO密集型与CPU密集型任务的异步革命,你竟还傻傻分不清?
揭秘Python并发神器:IO密集型与CPU密集型任务的异步革命,你竟还傻傻分不清?
144 4
|
7月前
|
存储 监控 算法
taosd 写入与查询场景下压缩解压及加密解密的 CPU 占用分析
在当今大数据时代,时序数据库的应用越来越广泛,尤其是在物联网、工业监控、金融分析等领域。TDengine 作为一款高性能的时序数据库,凭借独特的存储架构和高效的压缩算法,在存储和查询效率上表现出色。然而,随着数据规模的不断增长,在保证数据安全性和存储效率的同时,如何优化 CPU 的资源占用,成为了一个值得深入讨论的问题。
127 1
|
12月前
|
监控 并行计算 数据处理
构建高效Python应用:并发与异步编程的实战秘籍,IO与CPU密集型任务一网打尽!
在Python编程的征途中,面对日益增长的性能需求,如何构建高效的应用成为了每位开发者必须面对的课题。并发与异步编程作为提升程序性能的两大法宝,在处理IO密集型与CPU密集型任务时展现出了巨大的潜力。今天,我们将深入探讨这些技术的最佳实践,助你打造高效Python应用。
171 0
|
8月前
|
监控 关系型数据库 MySQL
如何解决 MySQL 数据库服务器 CPU 飙升的情况
大家好,我是 V 哥。当 MySQL 数据库服务器 CPU 飙升时,如何快速定位和解决问题至关重要。本文整理了一套实用的排查和优化套路,包括使用系统监控工具、分析慢查询日志、优化 SQL 查询、调整 MySQL 配置参数、优化数据库架构及检查硬件资源等步骤。通过一个电商业务系统的案例,详细展示了从问题发现到解决的全过程,帮助你有效降低 CPU 使用率,提升系统性能。关注 V 哥,掌握更多技术干货。
1053 0
|
9月前
|
SQL 监控 测试技术
一次压测引发的数据库CPU飙升...
一次压测过程中,当数据库的qps和tps都正常时,如果cpu利用率异常的高,应该如何排查?希望通过这篇文章,给你一些启发。
|
11月前
|
缓存 图形学
选择合适的CPU进行升级
【10月更文挑战第30天】选择合适的CPU进行升级
301 3
|
11月前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
4644 2
|
12月前
|
Java Linux
【网络】高并发场景处理:线程池和IO多路复用
【网络】高并发场景处理:线程池和IO多路复用
286 2
|
12月前
|
开发框架 并行计算 .NET
脑洞大开!Python并发与异步编程的哲学思考:IO密集型与CPU密集型任务的智慧选择!
脑洞大开!Python并发与异步编程的哲学思考:IO密集型与CPU密集型任务的智慧选择!
119 1