记录一次 TiKV page cache 调优

最近在做 TiKV 的插入提速的时候遇到了一个非常奇怪的问题。因为 TiKV 底层是使用 RocksDB，RocksDB 会首先将数据写到 WAL，然后在写到 memtable，再在后台 flush 到 disk，然后进行 compaction 处理。

因为我们在写入 WAL 的时候并没有打开 sync 标记，照理写 WAL 只会写到操作系统的 page cache，是一个异步写，这个速度应该是非常快的。最开始我们一直这么认为，但当我们将 WAL 放在另一个盘上面的时候，突然发现，TiKV 的写入性能竟然提升了 10% 以上，这个发现让我开始思考，写 WAL 真的是异步的吗。

通常，对于操作系统的 write 来说，它首先会将数据写到 page cache，当 page cache 的 dirty page 积累到一定程度，则开始将其 flush 到磁盘。如果 dirty page 超过了一个阈值，则 write 操作的进程就会进行强制刷 dirty page 的操作，即使这些 dirty page 并不是这个进程产生的。

在 Linux 里面，控制 dirty flush 的就是 dirty_background_ratio 和 dirty_ratio，然后我看了看我们自己系统的配置，发现 background ratio 是 10，而 dirty ratio 竟然只有坑爹的 20，也就是如果我们的写入压力很大（主要是 RocksDB 做 compaction），那么就很容易超过 dirty ratio，自然写 WAL 的时候就变成同步写了。

因为现代 Linux 已经对不同盘的 dirty page 做了优化，能保证一个盘的高 IO 操作不会过多的影响到另一个盘，所以将 WAL 移到另一个盘，明显就能发现性能提升。

如果只有一个盘，那就需要调整 dirty ratio 了，我将 dirty ratio 调整到 50 之后，发现写入性能也提升，但时不时会因为 compaction 导致 QPS 抖动。

对于 RocksDB 来说，大量的 dirty page 是由 compaction 产生的，那么如果我们使用 direct IO，就应该能减少 dirty page，设置之后，明显发现写入 TiKV 的 QPS 曲线平滑了很多。

这次调优也算是误打误撞，至少让我进一步加深了对 Linux 的理解，后面还需要恶补相关的操作系统知识。