【 TiDB 使用环境】 测试
【 TiDB 版本】V6.1
环境配置：
服务数量：
tidb service：1
pd：1
tikv：6
配置：
共三个节点，每个节点配置：12C64G
网卡：万兆
部署方式：
K8S部署
底层存储：
ceph
【遇到的问题：问题现象及影响】
1、环境为新部署环境
2、老环境中存在2张大表，一张100G，一张900G，还有其他零星的业务数据，加起来500G，一共约1.5T的数据，使用BR工具对老数据进行备份与导入新环境操作，500G的数据，导入耗时约2h，整体数据导入效率较高，因此未注意具体的写入速度
3、新数据导入完毕后，执行算法测试（使用tispark从一个50g的表里面读取数据，然后加了一列，重新写入一张新表），新数据写入等操作
4、执行步骤3时，明显感觉数据在写入时，效率很低
5、部署grafana后关注tikv读写情况，发现tikv的读写效率很低
【资源配置】
【附件：截图/日志/监控】
老环境存储磁盘什么类型？ 看append/commit/apply duration 好像磁盘性能很差。
老环境是HDD磁盘，K8S使用的local path存储
可以看下 disk_performance页 或node_exporter中磁盘性能，官方都建议ssd
新环境的ceph存储，是使用SSD+HDD组合，测出来的IO能达到400-500MB/s
除了吞吐量还跟延迟有关，4、5百M的速度也不算高，先看下监控数据吧
可以从哪些监控指标去看啊？
参考下这个指标
底层的IO经过fio和sysbench等工具的测试，可以确认应该不会存在明显异常
grafana页面
没有明显异常不等于存储性能达标
单个tikv实例上，有1.4万个region，还有涉及的全表读取、写入操作，这个对集群的使用是不是影响很大
region 也有海量的案例，这个不会有影响的
如果有热点问题，则会有影响… （就写倾斜和读倾斜）
单个tikv实例，12c 64g，region个数有没有推荐值呢
region 合理区间 2w - 3W， 如果大于这个数量，则需要参考最佳实践，海量region调度的文章进行优化了
好的那
看你的applylog和commitlog时间比较长。基本上就是磁盘IO比较慢了。
硬件条件没法提升的话，想尽可能提高tidb的吞吐，
可以这样的思路调整配置：
对应的攒批配置可调相关参数： https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#max-batch-wait-time
对应的rocksdb的压缩率，可调：https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#compression-per-level
对应的缓存，有tidb层的，也有tikv层的：
tikv层的： https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#write-buffer-size
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#max-write-buffer-number
tidb层的： https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#tikv-clientcopr-cache-从-v400-版本开始引入
tikv的缓存主要2个：memtable的size和个数，blockcache的大小。其中memtable的大小和个数主要影响写，也影响写后立刻读，blockcache主要影响读取。这俩有监控指标，看rocksdb-kv里面的cache命中率。
tidb的缓存主要是 缓存coprocessor读取的结果，还有个小表缓存，配置你找找吧。
天下没有免费的午餐，HDD 想要提高性能就要从其他方面牺牲一些，比如说多用内存，多用CPU。
慢慢调吧，好玩着呢，上面的参数是列的几个例子，还有很多手段，比如说调大region，减少网络raft交互占用 的带宽，但是调大region又容易有热点，各方面权衡。tidb就像瑞士军刀，花里胡哨的配置挺多。
关于配置1，想请教一下：
是设置 max-batch-wait-time么？
通过这个值，如何去控制每次发送的数据量？比如我想让一次的IO写4M，该如何设置这个值
