# [Know Issue] 关于 TiKV 实例 Storage ReadPool CPU 打满导致应用报错 Information schema is out of date: schema failed to update in 1 lease, please make sure TiDB can connect to TiKV

## Key Words

TiKV, CPU, Storage ReadPool CPU, Information schema is out of date, seek_tombstone, scheduler scan details

## Description

应用偶发报错导致业务无法访问，某些 TiKV CPU 使用率飙升，Storage ReadPool CPU 打满，重启问题 TiKV 以后并没有彻底解决偶发性报错问题。

应用报错日志

```java
2022-10-26 14:20:41.877 ERROR CADOC com.sf.ciam.common.service.doc.impl.TmCfgNumRangeServiceImpl [649] - genNewDocNumberList error client=800|numRange=I164 org.springframework.orm.jpa.JpaSystemException: java.sql.SQLException: Information schema is out of date: schema failed to update in 1 lease, please make sure TiDB can connect to TiKV; nested exception is javax.persistence.PersistenceException: java.sql.SQLException: Information schema is out of date: schema failed to update in 1 lease, please make sure TiDB can connect to TiKV
```

通过 TiKV-details 监控面板看到 TiKV 个别实例的 CPU 使用率明显飙高，同时对应的 Thread CPU 面板看到 Storage ReadPool CPU 已经打满。

## Root Cause

TiKV 实例删除数据后，大量的 Tombstone key 没有完成 Compaction 操作，导致大量 SQL 扫描大量无用数据，导致 TiKV 的 Storage ReadPool CPU 被打满，最终导致 TiKV 繁忙，处理请求响应缓慢。
由于 TiKV 繁忙，当业务执行 DML 时，有一段时间连不上出现异常的 TiKV，导致 TiDB 超过一个 DDL lease 时间（默认 45s），没能加载最新的 Schema 元信息可能会报 “Information schema is out of date 的错误，个别情况也会导致 TiDB 断开与 PD 之间 keeplive 设置连接，会报错 ”Encounte ERRO"

## Diagnostic Steps

1. 分析 TiKV CPU 异常和 引用报错是否有关联：通过应用报错对应 TiDB Server 查询集群的元数据 Region 是否在出现 CPU 异常的 TiKV 实例上面，操作命令如下

      ```shell
      # 执行命令结果输出对应的 Store_id 来定位是否和异常 TiKV 实例有关
      curl http://{TiDBIP}:10080/regions/meta
      ```

2. 分析 TiKV CPU 使用情况：通过 Grafana 监控 TiKV-details Dashboard 中的 Thread CPU 面板下面 Storage ReadPool CPU  监控排查 ReadPool 的 Normal、High、Low 3 个线程的 CPU 使用率情况，结合 TiKV 的配置文件中 readpool.storage.high-concurrency，readpool.storage.low-concurrency，readpool.storage.normal-concurrency 的参数值判断 CPU 是否已经打满；

3. 排查是否存在 Tombstone key 数据较多：如果判断 CPU 已经打满，可以通过重启对应 TiKV 异常的实例，可以缓解应用请求报错问题。接下来通过 TiKV-details -> Scheduler Batch get 面板中的 scheduler scan details 监控判断 seek_tombstone 是否很高，如果达到 Mil 既百万级别情况下，说明数据的版本较多（包括删除、更新操作导致的）。

4. 发现 MVCC 版本较多的 TiKV 实例：可以通过 Grafana 的查询语句，将 scheduler scan details 调整为实例级别，以此来判断是否异常 TiKV 实例存在较多 tombsone key。查询语句如下：
  
      ```text
      sum(rate(tikv_scheduler_kv_scan_details{k8s_cluster="",tidb_cluster="",instance=~".*",req="batch_get"}[1m])) by (instance)
      ```

5. 分析 MVCC 版本较多的原因：通过 TiDB Dashboard 的 QPS 监控判断一下是否存在大量的 Delete 和 Update 操作，可以初步判断是否对齐上面现象；

## Workaround

1. 在 TiKV CPU 充足情况下，可以调整 ReadPool.storage 的并发配置；
2. 临时将集群的元信息 Region 通过 Leader transfer 调整到正常的 TiKV 上面，避免应用报错；
3. 通过调整 Compaction 触发几率，默认 30%，调整为 20% 以此加快 Tombestone key 处理频率，但会占用大量的 CPU 资源；

## Resolution

将集群升级到最新的分支版本，通过 <https://github.com/TiKV/TiKV/issues/8486> 修复，缓解 "Tombestone key scan" 资源消耗导致的读请求延迟问题

## Affected Versions

< 4.0.16