作者： tidb 菜鸟一只原文来源：https://tidb.net/blog/76db401a

现象

在我一次对数据库 sysbench 压测的时候，对数据库准备压测的数据时，居然报[9005]; Region is unavailable

以下是 sysbench 的 config 文件

mysql-host=10.11.142.246mysql-port=3806mysql-user=rootmysql-password=1111mysql-db=sbtesttime=120threads=300report-interval=10db-driver=mysql

以下是 sysbench 准备数据的命令，大概是准备 16 张表，每张表数据量 1000W.

/usr/local/sysbench/bin/sysbench --config-file=config oltp_point_select --tables=16 --table-size=10000000 prepare

分析原因

参照官方文档的集群问题导图对Region is Unavailable的问题导图进行了核查

https://docs.pingcap.com/zh/tidb/v6.5/tidb-troubleshooting-map#11-%E5%AE%A2%E6%88%B7%E7%AB%AF%E6%8A%A5-region-is-unavailable-%E9%94%99%E8%AF%AF

首先在 tikv 的日志中发现如下报错

和

在 tidb 中发下如下报错：

基本可以确定时第一种情况或者第五种情况。

第一种情况主要时 tidb 在往 tikv 上面并发写入大量数据时，因为 tikv 因为资源紧张导致not leader或者epoch not match 原因被打回；又或者请求 TiKV 超时等），TiDB 内部会进行 backoff 重试。backoff 的时间超过一定阈值（默认 20s）后就会报错给客户端。

但是查看 grafana 的监控，tikv 节点在对应时间段的 cpu、内存和 io 以及网络都不算特别忙碌

tidb-smk-overview→system info

tidb-smk-tikv-details→cluster

这是怀疑是第五种情况，同时参照了case-958，查看了 grafana 对应的监控

tidb-smk-tikv-details→Raft IO→apply log duration

和 tidb-smk-tikv-details→Raft propose→apply wait duration

发现 apply log duration 并不高，但是 apply wait duration 非常高，这时结合 tidb 集群问题导图中的 tikv 写入慢中 apply 慢的问题诊断步骤

https://docs.pingcap.com/zh/tidb/v6.5/tidb-troubleshooting-map#45-tikv-%E5%86%99%E5%85%A5%E6%85%A2

查看 grafana 中对应监控

tidb-smk-tikv-details→Thread CPU→asyncapply cpu

发现 apply 线程的 cpu 使用程度已经达到了惊人的 196%，而默认的 apply-pool-size 参数就是 2，这也就意味着 apply 线程已经是在满负荷运行了，看了必须要调整 apply-pool-size 参数了

处理方法

通过在线修改 tikv 的 apply-pool-size 参数为 4，即 apply 线程默认最多使用 4 颗 cpu

SHOW config WHERE NAME LIKE '%apply-pool-size%';SET config tikv raftstore.apply-pool-size='4';

最终效果

重新生成数据库准备压测的数据，不再报[9005]; Region is unavailable 错，同时监控 apply 进程相关的 grafana 监控

tidb-smk-tikv-details→Thread CPU→asyncapply cpu

tidb-smk-tikv-details→Raft IO→apply log duration

和 tidb-smk-tikv-details→Raft propose→apply wait duration

发现 apply 线程的 cpu 使用程度最多也只到 376%，没有到极限，apply log duration 并不高，但是 apply wait duration 还是有点高，但是相对于 apply-pool-size=‘2’ 时，已经降低了很多了。

总结

基本官方文档里面的集群问题导图，进行分析，一般问题都能解决，排查问题要细心。https://docs.pingcap.com/zh/tidb/v6.5/tidb-troubleshooting-map#tidb-%E9%9B%86%E7%BE%A4%E9%97%AE%E9%A2%98%E5%AF%BC%E5%9B%BE

另外考虑此次异常的底层原因，由于原来在一个三台 16C64G 的云主机搭配垃圾存储的部署的集群也做过类似的数据生成，但是并没有报错，这次反而是在一个三台 32C128G 的物理机搭配 ssd 存储的部署的集群出现了问题，感觉是 tikv 的 apply-pool-size 参数的默认值 2 在应对高速磁盘写入时无法受限于 apply 线程的 cpu 无法及时的进行 apply log，故导致此故障，所以如果使用的磁盘 io 性能更好时，应该适当的调大此值。