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 867127831 <86...@qq.com> on 2020/12/22 11:00:12 UTC
回复: flink 1.11 interval join场景下rocksdb内存超用问题
上面是一个slot上的rocksdb block_cache_usage的使用量,从图中可以看出,usage一直在增加,达到block_cache_capacity上限后,就保持水平了,没有丝毫下降的趋势。
上图是此时间段内mem table size的趋势图。
------------------ 原始邮件 ------------------
发件人: "user-zh" <pr123shadow@gmail.com>;
发送时间: 2020年12月19日(星期六) 中午12:50
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: Re: flink 1.11 interval join场景下rocksdb内存超用问题
你好,能否把 promethus上metrics, rocksdb_block_cache_usage的大小不断上升的
截图发一下,其它rocksdb 的内存图 如果有的话,也发一下
开始时间 到 结束时间 3个 小时的。
867127831 <867127831@qq.com> 于2020年12月18日周五 下午3:15写道:
> Hi,
>
>
> 我在flink 1.11 on k8s上运行了一个双流join的sql,使用rocksdb作为backend,flink
> managed部分的内存由flink托管(state.backend.rocksdb.memory.managed=true),但是发现k8s的pod的内存消耗一直在增加。具体情况如下:
>
>
> flink sql:
>
>
> insert into console_sink
> select t1.*, t2.*
> from t1 left join t2
> on t1.unique_id = t2.unique_id
> and t1.event_time BETWEEN t2.event_time - INTERVAL '1' HOUR AND
> t2.event_time + INTERVAL '1' HOUR
>
>
>
> 属性配置:
> state.backend=rocksdb;
> state.backend.incremental=false;
> state.backend.rocksdb.memory.managed=true
> state.idle.retention.mintime='10 min';
> state.idle.retention.maxtime='20 min';
> checkpoint.time.interval='15 min';
> source.idle-timeout='60000 ms';
>
> taskmanager.memory.flink.size =55 gb
> taskmanager.memory.managed.fraction=0.85
>
>
>
>
>
>
> 运行现象:
> 1. checkpoint的size稳定在200G左右,说明state是有过期释放的。
> 2. k8s pod的使用内存不断增加,没有下降下来的趋势,最终整个pod的内存使用量超过pod内存上限,导致pod被杀掉。
> 3. 通过采集promethus上metrics,
> 发现rocksdb_block_cache_usage的大小不断上升,最终达到rocksdb_block_cache_capacity的上限。并且rocksdb_block_cache_usage的大小远远超过了flink
> managed部分内存的大小。
>
>
> 想知道,为什么在flink全托管rocksdb的情况下,为什么会出现rocksdb_block_cache_usage这个指标一直增长而不降低呢?