【 TiDB 使用环境】v 6.1.0
8核32G，磁盘IOPS 1.5W
【概述】 场景 + 问题概述
用sysbench压测，准备压测数据（测试时间:2022-08-21 19:00~2022-08-22 07:00）
sysbench --config-file=sysbench.cfg oltp_point_select --tables=32 --table-size=10000000 prepare
12小时数据写了不到2亿，而且越写越慢。看tikv.log没有锁，
【现象】 业务和数据库现象
【附件】 相关日志及配置信息
将数据追加写入内存 mem table。
write_buffer_size 控制memtable存放数据大小，一旦超过这个阈值，memtable 就会将数据转存
memtable 写满之后会将数据转存到immutable memtable中，immutable memtable有一个就开始往磁盘中刷数据
当数据写入过快时，immutable memtable一旦超过5个 lsm就会对memtable 做流控（write stall）
tikv 自身的就有流控机制
有什么优化办法吗？
1、 scheduler latch延迟高 可以看下thread cpu中的scheduler 线程利用率，考虑是否增加线程数，另外也可以考虑增加下 scheduler-concurrency参数
2、流控原因可以看下tikv detail中的write stall reason , 具体是哪一层导致
看起来是IO到达瓶颈了
https://metricstool.pingcap.com/#backup-with-dev-tools 按此导出下 overview ,pd,tidb,tikv的监控，要展开所有面板，等待数据加载完后再导出
这几张图看是没有磁盘瓶颈
set config tikv rocksdb.max-background-jobs=
set config tikv rocksdb.max-sub-compactions=
这2个加大试试呢
1、 12小时数据写了不到2亿， 这个是怎么统计的？
2、 sysbench.cfg 里如何写的，用了多少并发？从tidb连接数看只有10个连接
prepare的过程是建表，灌入数据，加索引sysbench完成，应该是8个线程的，从21号晚上7点左右执行prepare,到第2天早上7点查看，数据写入到第18张表(每张表1KW数据)，sbtest1-8为一批,9-16为一批，前2批已经写入完成，所以预估数据写入量在1.6-2亿之间。
主要是不明白为撒会触发流控。
后面的执行完了，admin show ddl jobs看下 ，从监控看没有write stall
表有索引吗？
kv 用的是SSD 磁盘吗？
还在建表建索引写数据的过程中，应该是先insert数据再创建索引。
