nt: Tuesday, March 29, 2022 20:27
> To: user-zh
> Subject: Re: RocksDB 读 cpu 100% 如何调优
>
> 如果rocksDB的状态很大呢？例如：200G，这种开了火焰图经常发现瓶颈也是在rocksDB的get（），这种有优化思路么？
>
> Yun Tang 于2022年3月21日周一 14:42写道：
>
> > Hi,
> >
> > RocksDB 的CPU栈能卡在100%，很有可能是大量解压缩 index/filter block
He
> Sent: Friday, March 18, 2022 20:16
> To: user-zh@flink.apache.org
> Subject: Re: RocksDB 读 cpu 100% 如何调优
>
> OK，我这边加个metric，先观察下
>
> yue ma 于2022年3月18日周五 12:23写道：
>
> > hi
> > 我觉得这里可以注意两地方
> > 首先 你可以观察一下这个时候 task 的吞吐量是多少 ，如果 qps 特别高 ，比如作业重最旧的offset 消费，我觉得这个
://developer.aliyun.com/article/784995 《Flink 1.13，State Backend
优化及生产实践分享》
祝好
唐云
From: Peihui He
Sent: Friday, March 18, 2022 20:16
To: user-zh@flink.apache.org
Subject: Re: RocksDB 读 cpu 100% 如何调优
OK，我这边加个metric，先观察下
yue ma 于2022年3月18日周五 12:23写道：
> hi
> 我觉得这里可以注意两地方
&g
OK，我这边加个metric，先观察下
yue ma 于2022年3月18日周五 12:23写道：
> hi
> 我觉得这里可以注意两地方
> 首先 你可以观察一下这个时候 task 的吞吐量是多少 ，如果 qps 特别高 ，比如作业重最旧的offset 消费，我觉得这个时候 cpu 100%
> 是符合预期的。
> 其次 你可以在代码中加一些内存缓存的逻辑 类似于 mini-batch， 来减少和 state 交互的频率，也许这样能缓解一部分问题。
>
> deng xuezhao 于2022年3月18日周五 11:19写道：
>
> > 退订
> >
> >
> >
> > 在
状态还是比较大的，应该有几个g的
Jiangang Liu 于2022年3月18日周五 14:36写道：
> 如果状态比较小，可以直接考虑使用filesystem，这种perRecord的操作还是比较耗时的。
>
> yue ma 于2022年3月18日周五 12:23写道：
>
> > hi
> > 我觉得这里可以注意两地方
> > 首先 你可以观察一下这个时候 task 的吞吐量是多少 ，如果 qps 特别高 ，比如作业重最旧的offset 消费，我觉得这个时候 cpu
> 100%
> > 是符合预期的。
> > 其次 你可以在代码中加一些内存缓存的逻辑 类似于
hi
我觉得这里可以注意两地方
首先 你可以观察一下这个时候 task 的吞吐量是多少 ，如果 qps 特别高 ，比如作业重最旧的offset 消费，我觉得这个时候 cpu 100%
是符合预期的。
其次 你可以在代码中加一些内存缓存的逻辑 类似于 mini-batch， 来减少和 state 交互的频率，也许这样能缓解一部分问题。
deng xuezhao 于2022年3月18日周五 11:19写道：
> 退订
>
>
>
> 在 Peihui He ，2022年3月18日 上午11:18写道：
>
> Hi, all
>
> 如题，flink 任务使用rocksdb
如果状态比较小，可以直接考虑使用filesystem，这种perRecord的操作还是比较耗时的。
deng xuezhao 于2022年3月18日周五 11:19写道：
> 退订
>
>
>
> 在 Peihui He ，2022年3月18日 上午11:18写道：
>
> Hi, all
>
> 如题，flink 任务使用rocksdb 做为状态后端，任务逻辑大概意思是：
> 来一条数据先判断该数据的key 是否再mapstat 中， 然后再将该key 写入mapstat中。
>
> 产生问题是当数据跑一段时间后，判断是否存在线程cpu总是100%，堆栈如下：
>
>
Hi, all
如题，flink 任务使用rocksdb 做为状态后端，任务逻辑大概意思是：
来一条数据先判断该数据的key 是否再mapstat 中， 然后再将该key 写入mapstat中。
产生问题是当数据跑一段时间后，判断是否存在线程cpu总是100%，堆栈如下：
"process (6/18)#0" Id=80 RUNNABLE (in native)
at org.rocksdb.RocksDB.get(Native Method)
at org.rocksdb.RocksDB.get(RocksDB.java:2084)
at
