【 TiDB 使用环境】生产环境 ，24个节点，共500T存储，已使用5%。region共10万。
CPU 64vcore。内存512G。4块SSD对应4个tikv实例。
【复现路径】
每十分钟写入1200万数据，现在每次在写入时集群延迟非常高，还会很诡异的不时出现在查询表时
table not found ， pd不定时切换。
作为实时引擎使用，主要是实时写入，直接读请求很少，主要用tispark分析。
写入时数据经过预处理，无锁冲突。
主要想通过优化apply-pool-size提升。目前是默认值2.
【遇到的问题：问题现象及影响】
TiKV Details 下 Raft propose 的 Apply wait duration 表示 apply 的等待时间，目前15s左右。
TiKV Details 下 Storage 的 Storage async write duration 异步写所花费的时间超长，目前15s左右。
【附件：截图/日志/监控】
集群tik的io利用率怎么样
数据库什么版本？
看看grafana的Performance-Overview,然后系统监控cpu io 内存等。
还有看看日志有什么问题吗
看下这个排查流程
上面有标。 V5.2.1
cpu高并不一定是cpu真的不够用
还有一种可能cpu也在等某些资源
经验上看这种cpu高基本上都是在等io
集群怎么搭建的？混合部署么？发出来看看
你这个延时这么大，都到秒级了，每个tikv几点多少region啊
不是混布的。数据节点都是SSD。24个节点。每个上面4个裸盘ssd,对应4个tikv实例。tikv实例就是24*4 = 96个。没有使用tiflash。6个tidb server和5个PD另外部署在6台机器管理节点上。
我看tikv写入时确实有热点，我们通过预分配region解决下。
很可能是写入热点呀
Raft propose 的 Apply wait duration 相对高，要10几s。
commit log 和appand log 相对正常。
write_stall正常。都是0
