TIDB针对 Write Stall机制的优化

       当RocksDB的flush或compact 速度落后于数据写入速度就会增加空间放大和读放大，可能导致磁盘空间被撑满或严重的读性能下降，为此则需要限制数据写入速度或者完全停止写入，这个限制就是write  stall， write stall触发原因有：1、 memtable数量过多 2、L0文件数量过多 3、 待compact的数据量过多。

• memtable数量过多

       当memtable数量达到min-write-buffer-number-to-merge(默认值为1)

参数个时会触发flsush，Flush慢主要由于磁盘性能问题引起，当等待flush的memetable数量达到参数max-write-buffer-number时会完全停止写入。当max-write-buffer-number>3且等待flush的memetable数量>=参数max-write-buffer-number-1时会降低写入速度。

       当由于memtable数量引起write stall时，内存充足的情况下可尝试调大max-write-buffer-number、max_background_jobs 、write_buffer_size 进行缓解。

• L0数量过多

       当L0 sst文件数达到level0_slowdown_writes_trigger后会触发write stall 降低写入速度，当达到level0_stop_writes_trigger则完全停止写入。

       当由于memtable数量引起write stall时，内存充足的情况下可尝试调大max_background_jobs 、write_buffer_size、min-write-buffer-number-to-merge进行缓解。

• 待compact的数据量过多

       当需要compact的文件数量达到soft_pending_compaction_byte参数值时会触发write stall，降低写入速度，当达到hard_pending_compaction_byte时会完全停止写入.

       TiKV内提供了相关监控用于观察compact的相关活动，可通过TiKV Detail -> RockDB KV/rfat 中相关面板查看。

       触发write stall的原因可通过Write Stall Reason面板查看。

       等待compact的文件大小：

       Compact的读写速度：

       5.2版本开始，tidb优化流控机制，在scheduler层进行流控代替rocksdb的wrtie stall机制，可以避免 write stall 机制卡住 Raftstore 或 Apply 线程导致的次生问题，该功能通过storage.flow-control控制是否开启流量控制机制。开启后，TiKV 会自动关闭 KV DB 的 write stall 机制，还会关闭 RaftDB 中除 memtable 以外的 write stall 机制，除此之外还可以使用memtables-threshold、l0-files-threshold、soft-pending-compaction-bytes-limit、hard-pending-compaction-bytes-limit等参数来进行控制。