You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by claylin <10...@qq.com> on 2020/02/27 01:53:12 UTC
回复: 关于在读和写频率都很高的情况下怎么优化rocksDB
我这个是在1.10版本上运行的
单节点状态大小,我看的是这个目录/data/hadoop/tmp/nm-local-dir/usercache/flink-user/appcache/application_1582163794765_0026/flink-io-21b91014-03a5-4d58-bafc-7e5b73f11ed0,总共2个节点一个43G,一个44G。
jstack看线程是在rocksdb读写,反压开始也是在读写那个算子开始反压的,而且我看到了rocksdb的线程rocksdb:low和rocksdb:high的CPU利用率超高,打满1个核,这个时候磁盘的tps达到了几千,io利用率就达到80以上,我现在把rocksdb相关线程数开启到了128个了。
如果要降低单个节点上的状态的话,这种情况下,我这里使用的是yarn资源调度,每个node是32核、128G内存,有5台机器,我的作业是32并发,这种情况下如何让5台机器上都运行作业,因为我现在看如果一个节点满足了作业资源需求就不会再去其他节点申请资源容器了,这样的话作业只会在一个节点上运行
------------------ 原始邮件 ------------------
发件人: "Yun Tang"<myasuka@live.com>;
发送时间: 2020年2月27日(星期四) 凌晨2:07
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: Re: 关于在读和写频率都很高的情况下怎么优化rocksDB
Hi
你的单节点rocksDB state size多大呢?(可以通过打开相关metrics [1] 或者登录到RocksDB所在机器观察一下RocksDB目录的size)
造成反压是如何确定一定是rocksDB 状态大导致的呢?看你的IO情况绝对值很大,但是百分比倒不是很高。是否用jstack观察过TM的进程,看一下是不是task主线程很容易打在RocksDB的get等读操作上。
RocksDB本质上还是面向磁盘的kv存储,如果是每次读写都更新的话,block cache发挥的作用会很有限。如果达到磁盘瓶颈,需要考虑提高磁盘性能或者想办法降低单个rocksDB实例的state大小。
最后,1.10 默认开启了RocksDB的内存限制功能,你这里提到的性能反压包括在之前版本上试验过么?
[1] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-total-sst-files-size
祝好
唐云
________________________________
From: claylin <1012539884@qq.com>
Sent: Wednesday, February 26, 2020 23:27
To: user-zh <user-zh@flink.apache.org>
Subject: 关于在读和写频率都很高的情况下怎么优化rocksDB
Hi 大家好:这边遇到一个有关rocksDB优化的问题,我这里系统平均tps为10w,几乎每条数据都会出发读写rocksDB,下面是我用sar -dp 命令统计的io情况:
Average:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DEV&nbsp; &nbsp; &nbsp; &nbsp;tps&nbsp; rd_sec/s&nbsp; wr_sec/s&nbsp; avgrq-sz&nbsp; avgqu-sz&nbsp; &nbsp; &nbsp;await&nbsp; &nbsp; &nbsp;svctm&nbsp; &nbsp; &nbsp;%util
Average:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sda&nbsp; &nbsp; 285.36&nbsp; &nbsp;2152.91&nbsp; 88322.99&nbsp; &nbsp; 317.06&nbsp; &nbsp; &nbsp;21.48&nbsp; &nbsp; &nbsp;75.27&nbsp; &nbsp; &nbsp; 0.58&nbsp; &nbsp; &nbsp;16.60
,运行时间长了就会严重造成反压,我按照这里https://ci.apache.org/projects/flink/flink-docs-stable/ops/state/large_state_tuning.html#tuning-rocksdb做了些调优,譬如增大Manager Memory,增大rocksDB的flush和compact线程数等,但还是一样,时间一长,状态变大就会造成反压,我也做了state的过期处理。
这个问题困扰好久了,大家有什么好的优化方案吗。