依据目前提供的信息，raw_batch_get 的长尾延迟主要是 raw_batch_put 引起 CPU 使用率上升导致的。其中：
-
按照经验，如果需要保持长尾延迟稳定，CPU 的使用应当控制在 40% 以下。此外，vCore 实际上并不能达到物理 core 的 2 倍性能，通常只有 1.5 倍左右，并且由于同一个物理 core 的 vCore 间共享寄存器、cache 等硬件，提高吞吐的同时长尾延迟会增加（参考 https://www.sciencedirect.com/science/article/pii/S0167739X22000334?via%3Dihub ）。因此，对于 24 (48 vCore) 机型，有条件的话建议 CPU 利用率控制在 1200% 以下，甚至关闭 hyper threading
-
存在异构混合部署，长尾延迟可能会集中在 16 (32 vCore) 机型上，监控上看到其中一台 CPU 使用率已超过 1300%。建议确认一下长尾延迟是否集中在少量机器
-
监控中观察到的 snapshot 流程中涉及 read index（见 TiKV 源码解析系列文章（十九）read index 和 local read 情景分析 | PingCAP ），主要在 Raftstore 中处理，对于 CPU 使用率和网络延迟敏感
-
增加 region size 有可能对于长尾延迟是负面影响，因为同一个 region 内的 Raft 只能串行处理，数据量增大反而增加长尾延迟
建议：
-
raw_batch_put 削峰，CPU 使用率（以物理 core 计算）控制在 50% 以下。此外，有条件的话 raw_batch_put 尽量打散写入，同一时间不要集中在少量 region
-
TiKV 独立部署并采用相同机型
-
建议调整机型配置，目前机型的 CPU 相比内存太小。TiKV 一般建议 CPU : Memory = 1 : 4。当采用 NVMe 时，大容量 block cache 的效果不会很显著。相近成本下如果调整为 32C/128GB，相信长尾延迟会有改善。