Hi, 感谢两位前辈的经验分享，我会细细拜读这里的优化方式，也衷心期待 Flink 1.10 可以早日顺利发布。
再次感谢你们的贡献 ：） Sincerely, Weike On Tue, Jan 14, 2020 at 8:54 PM Yu Li <car...@gmail.com> wrote: > Hi， > > 如唐云所述，FLINK-7289 [1] > 所有的开发工作已经完成，目前剩余的工作是补充end-to-end测试以及完善文档，因此release-1.10分支的代码功能已经完全可用了 > > > 我们建议使用FLINK-7289实现的方式来控制rocksdb内存，这将极大的简化用户所需的配置，只需要设置"state.backend.rocksdb.memory.managed"为true并调整managed > memory大小，或者通过"state.backend.rocksdb.memory.fixed-per-slot" 配置对应单个slot > RocksDB可使用的最大内存即可 > > 如果生产上确实比较紧急，无法等待1.10.0版本的发布，也可以参考之前英文邮件列表里相关讨论 [2] > 给出的公式和设置来尝试对rocksdb内存进行限制 > > 希望这些信息有所帮助 > > Best Regards, > Yu > > [1] https://issues.apache.org/jira/browse/FLINK-7289 > [2] > > http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Memory-constrains-running-Flink-on-Kubernetes-tt28954.html > > > On Tue, 14 Jan 2020 at 11:15, Yun Tang <myas...@live.com> wrote: > > > Hi Dong > > > > RocksDB无论如何都是要使用native内存的，您的YARN pmem-check相比JVM heap的buffer空间是多少，是否合适呢？ > > > > FLINK-7289的基本所需task都已经完成在release-1.10 分支中了，您可以直接使用release-1.10 > > 分支打包，最近也要发布1.10的rc版本，欢迎试用该功能。 > > > > 如果你的所有checkpoint size是50GB，其实不是很大，但是如果单个state > > backend有50GB的话，对于Flink这种低延迟流式场景是稍大的，建议降低单并发state数据量。 > > > > 至于目前的问题，也就是您加了相关参数，但是内存用量仍然在涨，可以用以下思路排查一下： > > > > 1. 首先，确保使用release-1.10 分支 > > 2. 开启 size-all-mem-tables [1] 和 block-cache-usage [2]的metrics监控 > > 3. 在默认没有enable "state.backend.rocksdb.memory.managed" [3] 的情况下，对column > > family进行如下配置，核心思路就是将主要的内存使用都放在cache中，方便观察内存使用： > > > > rocksDBStateBackend.setOptions(new OptionsFactory() { > > @Override > > public DBOptions createDBOptions(DBOptions currentOptions) { > > return currentOptions; > > } > > > > @Override > > public ColumnFamilyOptions createColumnOptions(ColumnFamilyOptions > > currentOptions) { > > BlockBasedTableConfig blockBasedTableConfig = new > > BlockBasedTableConfig(); > > blockBasedTableConfig.setCacheIndexAndFilterBlocks(true); > > blockBasedTableConfig.pinL0FilterAndIndexBlocksInCache(); > > currentOptions.setTableFormatConfig(blockBasedTableConfig); > > return currentOptions; > > } > > }); > > > > 4. 由于没有enable cache共享，所以需要将每个column > > > family的size-all-mem-tables和block-cache-usage进行相加，观察相关指数变化，看是否超过了你的pmem-check > > 限制。 > > > > 相应地，您也可以启用"state.backend.rocksdb.memory.managed" [3] 该功能 或者 自行配置 > > "state.backend.rocksdb.memory.fixed-per-slot" [4] 设置期望的rocksDB per slot > > memory size，此时只需要观察block-cache-usage的指标，由于这里使用共享cache的逻辑，所以并不需要相加，只要观察per > > slot的情况即可（同一个TM内，相同subtask index的rocksDB > state其实是用的同一块cache），观察内存限制功能是否生效。 > > > > [1] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-size-all-mem-tables > > [2] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-block-cache-usage > > [3] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-memory-managed > > [4] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-memory-fixed-per-slot > > > > > > 祝好 > > 唐云 > > > > ________________________________ > > From: DONG, Weike <kyled...@connect.hku.hk> > > Sent: Tuesday, January 14, 2020 10:02 > > To: user-zh@flink.apache.org <user-zh@flink.apache.org> > > Subject: 咨询一下 RocksDB 状态后端的调优经验 > > > > 大家好， > > > > 我们在 YARN 容器内运行以 RocksDB 作为 State Backend 的 Flink 作业，状态数据比较大（50G > > 以上，难以放到内存中）。但是由于 YARN 本身的 pmem-check 限制，经常会因为内存用量的不受控而导致整个 Container 被强制 > > KILL. > > > > 目前调研了 https://issues.apache.org/jira/browse/FLINK-7289 这个提议，但是目前还未完全实现。 > > 也按照 RocksDB 官方的调优指南 > > https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide 设置了 > > state.backend.rocksdb.writebuffer.size > > state.backend.rocksdb.writebuffer.count > > state.backend.rocksdb.block.cache-size > > state.backend.rocksdb.files.open > > 等等参数，但是目前观察到效果并不太明显，内存用量还是会不受控地越来越多。 > > > > 请问各位是否有 RocksDB 作为状态后端的调优经验，例如在内存受限的情况下，尽量确保 RocksDB 的内存用量可控在一个封顶范围呢？ > > > > 另外还有一个场景，假设内存够用的情况下，有哪些增加读写性能方面的建议呢？目前尝试使用 SSD 来存放 sst 文件，但是性能提升也不明显。 > > > > 感谢 ：） > > >
