关于在读和写频率都很高的情况下怎么优化rocksDB
Hi 大家好：这边遇到一个有关rocksDB优化的问题，我这里系统平均tps为10w，几乎每条数据都会出发读写rocksDB，下面是我用sar -dp 命令统计的io情况：
Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
Average: sda 285.36 2152.91 88322.99 317.06 21.48 75.27 0.58 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的过期处理。
这个问题困扰好久了，大家有什么好的优化方案吗。*来自志愿者整理的flink邮件归档
写回答
-
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*来自志愿者整理的FLINK邮件归档
2021-12-03 10:48:55赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
