ShawU
(Hacker Xs3n44 Go)
1
为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
TiDB V6.1
TiKV 配置 16 vCPU 64 GiB （I/O优化）本地盘SSD：1788 GiB
【概述】 场景 + 问题概述
3TiDB+3TiKV集群，同样的高频数据写入，在MySQL没延迟，在TiDB有延迟。通过监控查看，Disk IO Utilization一直100%；通过把ESSD云盘换成NVMe SSD，问题依旧；通过增加1台TiKV节点，问题依旧。
【背景】 做过哪些操作
什么都没做，全新部署的集群。
【现象】 业务和数据库现象
业务表数据延迟，数据库Disk IO Utilization 几乎100%
【问题】 当前遇到的问题
如何优化，解决数据写入到数据库，入库时间时延和Mysql相当。同时，使得IO资源下降，能达到单机MySQL的水平（85%）
【业务影响】
数据延迟
【TiDB 版本】
V6.1
【应用软件及版本】
【附件】 相关日志及配置信息
- TiUP Cluster Display 信息
- TiUP CLuster Edit config 信息
监控（https://metricstool.pingcap.com/)
- TiDB-Overview Grafana监控
- TiDB Grafana 监控
- TiKV Grafana 监控
- PD Grafana 监控
- 对应模块日志（包含问题前后 1 小时日志）
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
还有 你这io满是一台tikv满 还是每台tikv都io满了
如果只有一台满的话是写入热点问题 你再继续操作
对此，在进行TiDB优化时，我们从表结构入手，对以自增ID作为主键的表进行重建，删除自增ID，使用TiDB隐式的_tidb_rowid列作为主键，将
create table t (a int primary key auto_increment, b int)；
改为：
create table t (a int, b int)SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=2
Mark
(Mark)
9
正常机器的IO使用率90%+ 不一定代表性能有问题，只能说磁盘io操作繁忙，一般ssd r/s w/s 只要不超过2000 r_await和w_await不超过10毫秒 ，可以根据实际的ssd性能上限判断是否io存在瓶颈
Mark
(Mark)
11
我觉得可以通过监控看下具体慢在哪了
Grafana监控tikv detail-raft IO append log duration : raft log 写入本地rocksdb 和发给其他角色
Grafana监控tikv detail-raft IO commit log duration : raft log 写入本地rocksdb 和发给其他角色 ，可适当调整 raft-maxinflight-msgs
Grafana监控tikv detail-raft IO apply log duration : 真正执行raftlog 把数据写入rocksdb kv 中的，如果高排查rocksdb kv是否写入慢或出现流控
h5n1
(H5n1)
14
高频写入达到什么样的写入频率， tidb的写入路径比较长，写入操作会转换为raft日志，raft日志要写入raftdb，raft日志还要被apply写入到kv db，加锁、删锁操作也是写入数据持久化，还有rocksdb 内部的compaction，索引高频写入时IO利用率要高。另外磁盘性能参考如下：
“IOPS 分为读写两部分，云盘标称的高 IOPS 大都是利用缓存获得提升的读 IOPS；磁盘的性能还包括带宽和 fdatasync，TiKV 在数据写入时需要进行磁盘的 sync 操作，以确保数据已经从缓冲区刷到硬件，再返回给业务侧，具体为 fdatasync 的操作系统调用。
TiKV 磁盘的建议 2GB/s 以上的写带宽，20K 次/s 以上的 fdatasync，在 4KB 高并发 direct 写的测试中 P99.99 低于 3ms；可以使用 fio 新版、或者 pg_test_fsync 工具进行测试。可以加上 -fdatasync=1 选项测一下，例如 大并发每次写4k而且每次 fsync
fio -direct=0 -fdatasync=1 -iodepth=4 -thread=4 -rw=write -ioengine=libaio -bs=4k -filename=./fio_test -size=20G -runtime=60 -group_reporting -name=write_test
fdatasync的性能参考
参考值一：非 NVMe 的 SSD 的 fdatasync/s 约 5~8K/s
参考值二：中早期 NVMe 的 fdatasync/s 约 20~50K/s
参考值三：当前成熟的 PCIE 3 的 NVMe 约 200~500K/s
”
我是咖啡哥
15
能否把具体的测试场景再描述细点？建表语句什么样的？相关监控图？io until很高，写入速度怎么样？跟MySQL比相差多少？
ShawU
(Hacker Xs3n44 Go)
16
场景就是时序数据点更新，见截图。3000条数据大概10ms左右入库，这个效率不知是否有问题呢？最终库里查询，业务时间和当前系统时间差是10几秒以上了。
ShawU
(Hacker Xs3n44 Go)
17
目前用的是阿里云的 NVMe SSD ，读写分别是6GB/s 和 3GB/s。
h5n1
(H5n1)
18
参考下写入流程慢排查，3000条 10ms这速度可以吧
ShawU
(Hacker Xs3n44 Go)
19
