无论才能、知识多么卓著,如果缺乏热情,则无异纸上画饼充饥,无补于事。

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

Elasticsearch | 作者 zmc | 发布于2022年10月09日 | | 阅读数:2326

背景

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:https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的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不会被清理,导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。


[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/14743


0 个评论

要回复文章请先登录注册