sst文件大小问题

[h5n1]

【问题】：目前库大小4.7T, 7.7万个region , SST文件数量已接近28W ， 后续数据量还会增加，是否有必要增加单个sst文件的大小以减少文件数量？tidb选择8M的SST文件大小的考虑是什么？

rocksdb.defaultcf.write-buffer-size | 128MiB
rocksdb.writecf.write-buffer-size | 128MiB

rocksdb.defaultcf.target-file-size-base | 8MiB
rocksdb.writecf.target-file-size-base | 8MiB

可能索引或<255的记录比较多或者mvcc版本较多，write CF大小比default还大，这种情况持续增长的话会不会造成什么影响？如何查看wirteCF各类型key大小 及 block cache内各CF占的大小？

[qizheng]

sst 数量较多可能在 sst ingesttion 时 block raftstore 导致临时的 write duration 延迟抖动

确认是否有这个问题需要临时打开 rocksdb 的 perf context（ 3.0.x 或 4.0.x 较新的版本支持，设置参数 raftstore.perf-level = 5），检查 mutex 耗时，一般不超过 1ms，如果比较高，应该是 sst 数量较多导致

缓解办法是把 defaultcf 或 writecf 的 target-file-size-base = “8MB” 调大，比如 32MB

注意调大 target-file-size-base 可能导致调度时的写入增加影响业务延迟，可以调小 pd 调度 schedule-limit

[qizheng]

writecf 较大可能是索引比较多或一些列宽（value）小于 255 的窄表，可以先看看能否删掉一些不必要的冗余索引，后续 tidb 也会支持统计 index 使用情况 https://github.com/pingcap/tidb/issues/19209

如果是索引 value 存储 rowid，通常大小是固定的，比如 tidb 内部生成的 rowid 长度为 uint64，block cache 需要关闭 shared block cache ，然后从监控（ RocksDB - kv Block cache size）可以看到各个 cf 的大小

[h5n1]

1. 目前有没有生产中调整target-file-size-base 的案例。调整原则是什么？
2. write CF过大的话会带来哪些影响？ 谢谢

[qizheng]

1. 主要通过监控看是不是 mutex 耗时比较高（需要提前设置 tikv 参数 raftstore.perf-level = 5），Rocksdb Propose 面板下的 Perf Context Duration
   https://github.com/tikv/tikv/pull/8467 ，有在生产上调过，如果 write duration 相对平稳，可以不用调整
2. write cf 过大没有特别的影响，不过如果是索引较多的情况，在写入或更新时会有额外的开销

[h5n1]

感谢！