本文包括：
- TiDB 功能优化概述
- TiDB 功能剖析和优化
- OLTP 负载功能优化实践
- Performance Overview 面板重要监控目标详解
1、TiDB 功能优化概述
tidb.net/blog/1731b9…
2、TiDB 功能剖析和优化
本文介绍了依据数据库时刻的体系优化办法，以及怎么利用 TiDBPerformance Overview 面板进行功能剖析和优化。
经过本文中介绍的办法，你能够从大局、自顶向下的视点剖析用户呼应时刻和数据库时刻，承认用户呼应时刻的瓶颈是否在数据库中。假如瓶颈在数据库中，你能够经过数据库时刻概览和 SQL 推迟的分化，定位数据库内部的瓶颈点，并进行针对性的优化。
依据数据库时刻的功能优化办法
TiDB 对 SQL 的处理途径和数据库时刻进行了完善的丈量和记载，方便定位数据库的功能瓶颈。即便在用户呼应时刻的功能数据缺失的状况下，依据 TiDB 数据库时刻的相关功能目标，你也能够到达以下两个功能剖析方针：
- 经过比照 SQL 处理均匀推迟和业务中 TiDB 衔接的闲暇时刻，承认整个体系的瓶颈是否在 TiDB 中。
- 假如瓶颈在 TiDB 内部，依据数据库时刻概览、色彩优化法、要害目标和资源利用率、自上而下的推迟分化，定位到功能瓶颈具体在整个散布式体系的哪个模块。
承认整个体系的瓶颈是否在 TiDB 中
- 假如业务中 TiDB 衔接的均匀闲暇时刻比 SQL 均匀处理推迟高，阐明运用的业务处理中，首要的推迟不在数据库中，数据库时刻占用户呼应时刻比例小，能够承认瓶颈不在数据库中。在这种状况下，需求重视数据库外部的组件，比方运用服务器硬件资源是否存在瓶颈，运用到数据库的网络推迟是否过高等。
- 假如 SQL 均匀处理推迟比业务中 TiDB 衔接的均匀闲暇时刻高，阐明业务中首要的瓶颈在 TiDB 内部，数据库时刻占用户呼应时刻比例大。
假如瓶颈在 TiDB 内部，怎么定位
一个典型的 SQL 的处理流程如下所示，TiDB 的功能目标覆盖了绝大部分的处理途径，对数据库时刻进行不同维度的分化和上色，用户能够快速的了解负载特性和数据库内部的瓶颈。
数据库时刻是一切 SQL 处理时刻的总和。经过以下三个维度对数据库时刻进行分化，能够协助你快速定位 TiDB 内部瓶颈：
- 按 SQL 处理类型分化，判别哪种类型的 SQL 句子耗费数据库时刻最多。对应的分化公式为：
DB Time = Select Time + Insert Time + Update Time + Delete Time + Commit Time + ... - 按 SQL 处理的 4 个过程（即 get_token/parse/compile/execute）分化，判别哪个过程耗费的时刻最多。对应的分化公式为：
DB Time = Get Token Time + Parse Time + Comiple Time + Execute Time - 关于 execute 耗时，按照 TiDB 履行器自身的时刻、TSO 等候时刻、KV 恳求时刻和重试的履行时刻，判别履行阶段的瓶颈。对应的分化公式为：
Execute Time ~= TiDB Executor Time + KV Request Time + PD TSO Wait Time + Retried execution time
利用 Performance Overview 面板进行功能剖析和优化
本章介绍怎么利用 Grafana 中的 Performance Overview 面板进行依据数据库时刻的功能剖析和优化。
Performance Overview 面板按总分结构对 TiDB、TiKV、PD 的功能目标进行编排安排，包括以下三个部分：
- 数据库时刻和 SQL 履行时刻概览：经过色彩符号不同 SQL 类型，SQL 不同履行阶段、不同恳求的数据库时刻，协助你快速辨认数据库负载特征和功能瓶颈。
- 要害目标和资源利用率：包括数据库 QPS、运用和数据库的衔接信息和恳求指令类型、数据库内部 TSO 和 KV 恳求 OPS、TiDB 和 TiKV 的资源运用概略。
- 自上而下的推迟分化：包括 Query 推迟和衔接闲暇时刻比照、Query 推迟分化、execute 阶段 TSO 恳求和 KV 恳求的推迟、TiKV 内部写推迟的分化等。
数据库时刻和 SQL 履行时刻概览
Database Time 目标为 TiDB 每秒处理 SQL 的推迟总和，即 TiDB 集群每秒并发处理运用 SQL 恳求的总时刻(等于活泼衔接数)。
Performance Overview 面板提供了以下三个面积堆叠图，协助你了解数据库负载的类型，快速定位数据库时刻的瓶颈首要是处理什么句子，集中在哪个履行阶段，SQL 履行阶段首要等候 TiKV 或许 PD 哪种恳求类型。
- Database Time By SQL Type
- Database Time By SQL Phase
- SQL Execute Time Overview
色彩优化法
经过调查数据库时刻分化图和履行时刻概览图，你能够直观区域别正常或许反常的时刻耗费，快速定位集群的反常瓶颈点，高效了解集群的负载特征。关于正常的时刻耗费和恳求类型，图中显示色彩为绿色系或蓝色系。假如非绿色或蓝色系的色彩在这两张图中占有了显着的比例，意味着数据库时刻的散布不合理。
- Database Time By SQL Type：蓝色标识代表 Select 句子，绿色标识代表 Update、Insert、Commit 等 DML 句子。赤色标识代表 General 类型，包括 StmtPrepare、StmtReset、StmtFetch、StmtClose 等指令。
- Database Time By SQL Phase：execute 履行阶段为绿色，其他三个阶段偏赤色系，假如非绿色的色彩占比显着，意味着在履行阶段之外数据库耗费了过多时刻，需求进一步剖析本源。一个常见的场景是由于无法运用履行计划缓存，导致 compile 阶段的橙色占比显着。
- SQL Execute Time Overview：绿色系标识代表惯例的写 KV 恳求（例如 Prewrite 和 Commit），蓝色系标识代表惯例的读 KV 恳求（例如 Cop 和 Get），其他色系标识需求留意的问题。例如，失望锁加锁恳求为赤色，TSO 等候为深褐色。假如非蓝色系或许非绿色系占比显着，意味着履行阶段存在反常的瓶颈。例如，当产生严峻锁抵触时，赤色的失望锁时刻会占比显着；当负载中 TSO 等候的耗费时刻过长时，深褐色会占比显着。
示例 1：TPC-C 负载
Database Time by SQL Type：首要耗费时刻的句子为 commit、update、select 和 insert 句子。
- Database Time by SQL Phase：首要耗费时刻的阶段为绿色的 execute 阶段。
- SQL Execute Time Overview：履行阶段首要耗费时刻的 KV 恳求为绿色的 Prewrite 和 Commit。
留意
- KV 恳求的总时刻大于 execute time 为正常现象，由于 TiDB 履行器或许并发向多个 TiKV 发送 KV 恳求，导致总的 KV 恳求等候时刻大于 execute time。TPC-C 负载中，业务提交时，TiDB 会向多个 TiKV 并行发送 Prewrite 和 Commit 恳求，所以这个比方中 Prewrite、Commit 和 PessimisticsLock 恳求的总时刻显着大于 execute time。
- execute time 也或许显着大于 KV 恳求的总时刻加上 tso_wait 的时刻，这意味着 SQL 履行阶段首要时刻花在 TiDB 履行器内部。两种常见的比方：
-
- 例 1：TiDB 履行器从 TiKV 读取许大都据之后，需求在 TiDB 内部进行杂乱的相关和聚合，耗费许多时刻。
- 例 2：运用的写句子锁抵触严峻，频繁锁重试导致
Retried execution time过长。
示例 2：OLTP 读密布负载
Database Time by SQL Type：首要耗费时刻的句子为 select、commit、update和 insert 句子。其间，select 占有绝大部分的数据库时刻。
- Database Time by SQL Phase：首要耗费时刻的阶段为绿色的 execute 阶段。
- SQL Execute Time Overview：履行阶段首要耗费时刻为深褐色的 pd tso_wait、蓝色的 KV Get 和绿色的 Prewrite 和 Commit。
示例 3：只读 OLTP 负载
- Database Time by SQL Type：几乎一切句子为 select。
- Database Time by SQL Phase：首要耗费时刻的阶段为橙色的 compile 和绿色的 execute 阶段。compile 阶段推迟最高，代表着 TiDB 生成履行计划的过程耗时过长，需求依据后续的功能数据进一步承认本源。
- SQL Execute Time Overview：履行阶段首要耗费时刻的 KV 恳求为蓝色 BatchGet。
留意
示例 3 select 句子需求从多个 TiKV 并行读取几千行数据，BatchGet 恳求的总时刻远大于履行时刻。
示例 4： 锁争用负载
Database Time by SQL Type：首要为 Update 句子。
- Database Time by SQL Phase：首要耗费时刻的阶段为绿色的 execute 阶段。
- SQL Execute Time Overview：履行阶段首要耗费时刻的 KV 恳求为赤色的失望锁 PessimisticLock，execute time 显着大于 KV 恳求的总时刻，这是由于运用的写句子锁抵触严峻，频繁锁重试导致
Retried execution time过长。目前Retried execution time耗费的时刻，TiDB 没有进行丈量。
TiDB 要害目标和集群资源利用率
Query Per Second、Command Per Second 和 Prepared-Plan-Cache
经过调查 Performance Overview 里的以下三个面板，能够了解运用的负载类型，与 TiDB 的交互方法，以及是否能有效地利用 TiDB 的履行计划缓存。
- QPS：表示 Query Per Second，包括运用的 SQL 句子类型履行次数散布。
- CPS By Type：CPS 表示 Command Per Second，Command 代表 MySQL 协议的指令类型。相同一个查询句子能够经过 query 或许 prepared statement 的指令类型发送到 TiDB。
- Queries Using Plan Cache OPS：TiDB 集群每秒射中履行计划缓存的次数。履行计划缓存只支撑 prepared statement 指令。TiDB 敞开履行计划缓存的状况下，存在三种运用状况：
-
- 彻底无法射中履行计划缓存：每秒射中次数为 0，由于运用运用 query 指令，或许每次 StmtExecute 履行之后调用 StmtClose 指令，导致缓存的履行计划被整理。
- 彻底射中履行计划缓存：每秒射中次数等于 StmtExecute 指令每秒履行次数。
- 部分射中履行计划缓存：每秒射中次数小于 StmtExecute 指令每秒履行次数，履行计划缓存目前存在一些约束，比方不支撑子查询，该类型的 SQL 履行计划无法被缓存。
示例 1：TPC-C 负载
TPC-C 负载类型首要以 Update、Select 和 Insert 句子为主。总的 QPS 等于每秒 StmtExecute 的次数，并且 StmtExecute 每秒的数据基本等于 Queries Using Plan Cache OPS。这是 OLTP 负载抱负的状况，客户端履行运用 prepared statement，并且在客户端缓存了 prepared statement 目标，履行每条 SQL 句子时直接调用 statement 履行。履行时都射中履行计划缓存，不需求从头 compile 生成履行计划。
示例 2：只读 OLTP 负载，运用 query 指令无法运用履行计划缓存
这个负载中， Commit QPS = Rollback QPS = Select QPS。运用敞开了 auto-commit 并发，每次从衔接池获取衔接都会履行 rollback，因此这三种句子的履行次数是相同的。
QPS 面板中呈现的赤色加粗线为 Failed Query，坐标的值为右边的 Y 轴。非 0 代表此负载中存在过错句子。
- 总的 QPS 等于 CPS By Type 面板中的 Query，阐明运用中运用了 query 指令。
- Queries Using Plan Cache OPS 面板没有数据，由于不运用 prepared statement 接口，无法运用 TiDB 的履行计划缓存， 意味着运用的每一条 query，TiDB 都需求从头解析，从头生成履行计划。一般会导致 compile 时刻变长以及 TiDB CPU 耗费的添加。
示例 3：OLTP 负载，运用 prepared statement 接口无法运用履行计划缓存
StmtPreare 次数 = StmtExecute 次数 = StmtClose 次数 ~= StmtFetch 次数，运用运用了 prepare > execute > fetch > close 的 loop，许多结构都会在 execute 之后调用 close，确保资源不会泄露。这会带来两个问题：
- 履行每条 SQL 句子需求 4 个指令，以及 4 次网络往复。
- Queries Using Plan Cache OPS 为 0， 无法射中履行计划缓存。StmtClose 指令默许会整理缓存的履行计划，导致下一次 StmtPreare 指令需求从头生成履行计划。
留意
从 TiDB v6.0.0 起，你能够经过大局变量 (set global tidb_ignore_prepared_cache_close_stmt=on;) 操控 StmtClose 指令不整理已被缓存的履行计划，使得下一次的 SQL 的履行不需求从头生成履行计划。
KV/TSO Request OPS 和衔接信息
在 KV/TSO Request OPS 面板中，你能够检查 KV 和 TSO 每秒恳求的数据计算。其间，kv request total代表 TiDB 到 TiKV 一切恳求的总和。经过调查 TiDB 到 PD 和 TiKV 的恳求类型，能够了解集群内部的负载特征。
在 Connection Count （衔接信息）面板中，你能够检查总的衔接数和每个 TiDB 的衔接数，并由此判别衔接总数是否正常，每个 TiDB 的衔接数是否不均衡。active connections记载着活泼衔接数，等于每秒的数据库时刻。
示例 1：繁忙的负载
在此 TPC-C 负载中：
- 每秒总的 KV 恳求的数量为 104.2k。按恳求数量排序，最高的恳求类型为
PessimisticsLock、Prewrite、Commit和BatchGet等。 - 总的衔接数为 810，三个 TiDB 实例的衔接数大体均衡。活泼的衔接数为 787.1。比照活泼衔接数和总衔接数，97% 的衔接都是活泼的，一般意味着数据库是这个运用体系的功能瓶颈。
示例 2：闲暇的负载
在此负载中：
- 每秒总的 KV 恳求数据是 2.6 K，TSO 恳求次数是每秒 1.1 K。
- 总的衔接数为 410，衔接数在三个 TiDB 中相对均衡。活泼衔接数只要 2.5，阐明数据库体系十分闲暇。
TiDB CPU，以及 TiKV CPU 和 IO 运用状况
在 TiDB CPU 和 TiKV CPU/IO MBps 这两个面板中，你能够调查到 TiDB 和 TiKV 的逻辑 CPU 运用率和 IO 吞吐，包括均匀、最大和 delta（最大 CPU 运用率减去最小 CPU 运用率），然后用来判定 TiDB 和 TiKV 总体的 CPU 运用率。
- 经过
delta值，你能够判别 TiDB 是否存在 CPU 运用负载不均衡（一般伴随着运用衔接不均衡），TiKV 是否存在热点。 - 经过 TiDB 和 TiKV 的资源运用概览，你能够快速判别集群是否存在资源瓶颈，最需求扩容的组件是 TiDB 仍是 TiKV。
示例 1：TiDB 资源运用率高
下图负载中，每个 TiDB 和 TiKV 装备 8 CPU。
- TiDB 均匀 CPU 为 575%。最大 CPU 为 643%，delta CPU 为 136%。
- TiKV 均匀 CPU 为 146%，最大 CPU 215%。delta CPU 为 118%。TiKV 的均匀 IO 吞吐为 9.06 MB/s，最大 IO 吞吐为 19.7 MB/s，delta IO 吞吐 为 17.1 MB/s。
由此能够判别，TiDB 的 CPU 耗费显着更高，并接近于 8 CPU 的瓶颈，能够考虑扩容 TiDB。
示例 2：TiKV 资源运用率高
下图 TPC-C 负载中，每个 TiDB 和 TiKV 装备 16 CPU。
- TiDB 均匀 CPU 为 883%。最大 CPU 为 962%，delta CPU 为 153%。
- TiKV 均匀 CPU 为 1288%，最大 CPU 1360%。delta CPU 为 126%。TiKV 的均匀 IO 吞吐为130 MB/s，最大 IO 吞吐为 153 MB/s，delta IO 吞吐为 53.7 MB/s。
由此能够判别，TiKV 的 CPU 耗费更高，由于 TPC-C 是一个写密布场景，这是正常现象，能够考虑扩容 TiKV 节点提升功能。
Query 推迟分化和要害的推迟目标
推迟面板一般包括均匀值和 99 分位数，均匀值用来定位总体的瓶颈，99 分位数用来判别是否存在推迟严峻颤动的状况。判别功能颤动规模时，或许还需求需求凭借 999 分位数。
Duration 和 Connection Idle Duration
Duration 面板包括了一切句子的 99 推迟和每种 SQL 类型的均匀推迟。Connection Idle Duration 面板包括衔接闲暇的均匀和 99 推迟，衔接闲暇时包括两种状况：
- in-txn：代表业务中衔接的闲暇时刻，即当衔接处于业务中时，处理完上一条 SQL 之后，收到下一条 SQL 句子的间隔时刻。
- not-in-txn：当衔接没有处于业务中，处理完上一条 SQL 之后，收到下一条 SQL 句子的间隔时刻。
运用进行数据库业务时，一般运用同一个数据库衔接。比照 query 的均匀推迟和 connection idle duration 的推迟，能够判别整个体系功能瓶颈或许用户呼应时刻的颤动是否是由 TiDB 导致的。
- 假如运用负载不是只读的，包括业务，比照 query 均匀推迟和
avg-in-txn能够判别运用处理业务时，首要的时刻是花在数据库内部仍是在数据库外面，借此定位用户呼应时刻的瓶颈。 - 假如是只读负载，不存在
avg-in-txn目标，能够比照 query 均匀推迟和avg-not-in-txn目标。
现实的客户负载中，瓶颈在数据库外面的状况并不少见，例如：
- 客户端服务器装备过低，CPU 资源不行。
- 运用 HAProxy 作为 TiDB 集群署理，可是 HAProxy CPU 资源不行。
- 运用 HAProxy 作为 TiDB 集群署理，可是高负载下 HAProxy 服务器的网络带宽被打满。
- 运用服务器到数据库推迟过高，比方公有云环境运用和 TiDB 集群不在同一个区域，比方数据库的 DNS 均衡器和 TiDB 集群不在同一个区域。
- 客户端程序存在瓶颈，无法充分利用服务器的多 CPU 核或许多 Numa 资源，比方运用只运用一个 JVM 向 TiDB 树立上千个 JDBC 衔接。
示例 1：用户呼应时刻的瓶颈在 TiDB 中
在此 TPC-C 负载中：
- 一切 SQL 句子的均匀推迟 477 us，99 推迟 3.13ms。均匀 commit 句子 2.02ms，均匀 insert 句子 609ms，均匀查询句子 468us。
- 业务中衔接闲暇时刻
avg-in-txn171 us。
由此能够判别，均匀的 query 推迟显着大于avg-in-txn，阐明业务处理中，首要的瓶颈在数据库内部。
示例 2：用户呼应时刻的瓶颈不在 TiDB 中
在此负载中，均匀 query 推迟为 1.69ms，业务中衔接闲暇时刻avg-in-txn为 18ms。阐明业务中，TiDB 均匀花了 1.69ms 处理完一个 SQL 句子之后，需求等候 18ms 才干收到下一条句子。
由此能够判别，用户呼应时刻的瓶颈不在 TiDB 中。这个比方是在一个公有云环境下，由于运用和数据库不在同一个区域，运用和数据库之间的网络推迟高导致了超高的衔接闲暇时刻。
Parse、Compile 和 Execute Duration
在 TiDB 中，从输入查询文本到回来结果的典型处理流程 1。
SQL 在 TiDB 内部的处理分为四个阶段，get token、parse、compile 和 execute：
- get token 阶段：一般只要几微秒的时刻，能够疏忽。除非 TiDB 单个实例的衔接数到达的token-limit的约束，创建衔接的时分被限流。
- parse 阶段：query 句子解析为笼统语法树 abstract syntax tree (AST)。
- compile 阶段：依据 parse 阶段输出的 AST 和计算信息，编译出履行计划。整个过程首要过程为逻辑优化与物理优化，前者经过一些规矩对查询计划进行优化，例如依据联系代数的列裁剪等，后者经过计算信息和依据本钱的优化器，对履行计划的本钱进行估算，并挑选全体本钱最小的物理履行计划。
- execute 阶段：时刻耗费视状况，先等候大局仅有的时刻戳 TSO，之后履行器依据履行计划中算子触及的 Key 规模，构建出 TiKV 的 API 恳求，分发到 TiKV。execute 时刻包括 TSO 等候时刻、KV 恳求的时刻和 TiDB 履行器自身处理数据的时刻。
假如运用统一运用 query 或许 StmtExecute MySQL 指令接口，能够运用以下公式来定位均匀推迟的瓶颈。
avg Query Duration = avg Get Token + avg Parse Duration + avg Compile Duration + avg Execute Duration
一般 execute 阶段会占 query 推迟的首要部分，在以下状况下，parse 和 compile 阶段也会占比显着。
- parse 阶段推迟占比显着：比方 query 句子很长，文本解析耗费许多的 CPU。
- compile 阶段推迟占比显着：假如运用没有运用履行计划缓存，每个句子都需求生成履行计划。compile 阶段的推迟或许到达几毫秒或许几十毫秒。假如无法射中履行计划缓存，compile 阶段需求进行逻辑优化和物理优化，这将耗费许多的 CPU 和内存，并给 Go Runtime 带来压力（由于 TiDB 是
href="https://go.dev/">Go 编写的），进一步影响 TiDB 其他组件的功能。这阐明，OLTP 负载在 TiDB 中是否能高效运转，履行计划缓扮演了重要的人物。
示例 1：数据库瓶颈在 compile 阶段
此图中 parse、compile 和 execute 阶段的均匀时刻分别为 17.1 us、729 us 和 681 us。由于运用运用 query 指令接口，无法运用履行计划缓存，所以 compile 阶段推迟高。
示例 2：数据库瓶颈在 execute 阶段
在此 TPC-C 负载中，parse、compile 和 execute 阶段的均匀时刻分别为 7.39us、38.1us 和 12.8ms。query 推迟的瓶颈在于 execute 阶段。
KV 和 TSO Request Duration
在 execute 阶段，TiDB 会跟 PD 和 TiKV 进行交互。如下图所示，当 TiDB 处理 SQL 句子恳求时，在进行 parse 和 compile 之前，假如需求获取 TSO，会先恳求生成 TSO。PD Client 不会堵塞调用者，而是直接回来一个TSFuture，并在后台异步处理 TSO 恳求的收发，一旦完结立即回来给 TSFuture，TSFuture 的持有者则需求调用 Wait 办法来获得最终的 TSO 结果。当 TiDB 完结 parse 和 compile 之后， 进入 execute 阶段，此刻存在两个状况：
- 假如 TSO 恳求现已完结，Wait 办法会马上回来一个可用的 TSO 或 error
- 假如 TSO 恳求还未完结，Wait 办法会 block 住等候一个可用的 TSO 或 error（阐明 gRPC 恳求已发送但没有收到回来结果，网络推迟较高）
TSO 等候的时刻记载为 TSO WAIT，TSO 恳求的网络时刻记载为 TSO RPC。TiDB TSO 等候完结之后，履行过程中一般需求和 TiKV 进行读写交互：
- 读的 KV 恳求常见类型：Get、BatchGet 和 Cop
- 写的 KV 恳求常见类型：PessimisticLock，二阶段提交的 Prewrite 和 Commit
这一部分的目标对应以下三个面板：
- Avg TiDB KV Request Duration：TiDB 丈量的 KV 恳求的均匀推迟
- Avg TiKV GRPC Duration：TiKV 内部 GRPC 音讯处理的均匀推迟
- PD TSO Wait/RPC Duration：TiDB 履行器等候 TSO 推迟 (wait) 和 TSO 恳求的网络推迟(rpc)。
其间，Avg TiDB KV Request Duration 和 Avg TiKV GRPC Duration 的联系如下
Avg TiDB KV Request Duration = Avg TiKV GRPC Duration + TiDB 与 TiKV 之间的网络推迟 + TiKV GRPC 处理时刻 + TiDB GRPC 处理时刻和调度推迟。
Avg TiDB KV Request Duration 和 Avg TiKV GRPC Duration 的差值跟网络流量和推迟，TiDB 和 TiKV 的资源运用状况密切相关。
- 同一个机房内，Avg TiDB KV Request Duration 和 Avg TiKV GRPC Duration 的差值一般应该小于 2 毫秒。
- 同一区域的不同可用区，Avg TiDB KV Request Duration 和 Avg TiKV GRPC Duration 的差值一般应该小于 5 毫秒。
示例 1：同机器低负载的集群
在此负载中，TiDB 侧均匀 Prewrite 恳求推迟为 925 us，TiKV 内部 kv_prewrite 均匀处理推迟为 720 us，相差 200 us 左右，是同机房内正常的推迟。TSO wait 均匀推迟 206 us，rpc 时刻为 144 us。
示例 2：公有云集群，负载正常
在此示例中，TiDB 集群布置在同一个区域的不同机房。TiDB 侧均匀 Commit 恳求推迟为 12.7 ms，TiKV 内部 kv_commit 均匀处理推迟为 10.2ms，相差 2.5ms 左右。TSO wait 均匀推迟为 3.12ms，rpc 时刻为 693us。
示例 3：公有云集群，资源严峻过载
在此示例中，TiDB 集群布置在同一个区域的不同机房，TiDB 网络和 CPU 资源严峻过载。TiDB 侧均匀 BatchGet 恳求推迟为 38.6 ms，TiKV 内部 kv_batch_get 均匀处理推迟为 6.15 ms，相差超越 32 ms，远高于正常值。TSO wait 均匀推迟为 9.45ms，rpc 时刻为 14.3ms。
Storage Async Write Duration、Store Duration 和 Apply Duration
TiKV 关于写恳求的处理流程如下图
-
scheduler worker会先处理写恳求，进行业务一致性检查，并把写恳求转化成键值对，发送到raftstore模块。 -
raftstore为 TiKV 的共识模块，运用 Raft 共识算法，使多个 TiKV 组成的存储层能够容错。Raftstore 分为 store 线程和 apply 线程。： -
- store 线程负载处理 Raft 音讯和新的
proposals。 当收到新的proposals时，leader 节点的 store 线程会写入本地 Raft DB，并将音讯仿制到多个 follower 节点。当这个proposals在大都实例耐久化成功之后，proposals成功被提交。 - apply 线程会负载将提交的内容写入到 KV DB 中。当写操作的内容被成功的写入 KV 数据库中，apply 线程会通知外层恳求写恳求现已完结。
- store 线程负载处理 Raft 音讯和新的
Storage Async Write Duration 目符号录写恳求进入 raftstore 之后的推迟，收集的粒度具体到每个恳求的等级。
Storage Async Write Duration 分为 Store Duration 和 Apply Duration。你能够经过以下公式定位写恳求的瓶颈首要是 在 Store 仍是 Apply 过程。
avg Storage Async Write Duration = avg Store Duration + avg Apply Duration
留意
Store Duration 和 Apply Duration 从 v5.3.0 版别开端支撑。
示例 1：同一个 OLTP 负载在 v5.3.0 和 v5.4.0 版别的比照
v5.4.0 版别，一个写密布的 OLTP 负载 QPS 比 v5.3.0 提升了 14%。运用以上公式
- v5.3.0：24.4 ms ~= 17.7 ms + 6.59 ms
- v5.4.0：21.4 ms ~= 14.0 ms + 7.33 ms
由于 v5.4.0 版别中，TiKV 对 gRPC 模块进行了优化，优化了 Raft 日志仿制速度， 比较 v5.3.0 降低了 Store Duration。
v5.3.0：
v5.4.0：
示例 2：Store Duration 瓶颈显着
运用以上公式：10.1 ms ~= 9.81 ms + 0.304 ms，阐明写恳求的推迟瓶颈在 Store Duration。
Commit Log Duration、Append Log Duration 和 Apply Log Duration
Commit Log Duration、Append Log Duration 和 Apply Log Duration 这三个推迟是 raftstore 内部要害操作的推迟记载。这些记载收集的粒度是 batch 操作等级的，每个操作会把多个写恳求合并在一起，因此不能直接对应上文的 Store Duration 和 Apply Duration。
- Commit Log Duration 和 Append Log Duration 均为 store 线程的操作。Commit Log Duration 包括仿制 Raft 日志到其他 TiKV 节点，保证 raft-log 的耐久化。一般包括两次 Append Log Duration，一次 leader，一次 follower 的。Commit Log Duration 推迟一般会显着高于 Append Log Duration，由于包括了经过网络仿制 Raft 日志到其他 TiKV 的时刻。
- Apply Log Duration 记载了 apply 线程 apply Raft 日志的推迟。
Commit Log Duration 慢的常见场景：
- TiKV CPU 资源存在瓶颈，调度推迟高
-
raftstore.store-pool-size设置过小或许过大（过大也或许导致功能下降） - IO 推迟高，导致 Append Log Duration 推迟高
- TiKV 之间的网络推迟比较高
- TiKV 的 gRPC 线程数设置过小或许多个 gRPC CPU 资源运用不均衡
Apply Log Duration 慢的常见场景：
- TiKV CPU 资源存在瓶颈，调度推迟高
-
raftstore.apply-pool-size设置过小或许过大（过大也或许导致功能下降） - IO 推迟比较高
示例 1：同一个 OLTP 负载在 v5.3.0 和 v5.4.0 版别的比照
v5.4.0 版别，一个写密布的 OLTP 负载 QPS 比 v5.3.0 提升了 14%。 比照这三个要害推迟：
| Avg Duration | v5.3.0(ms) | v5.4.0(ms) |
|---|---|---|
| Append Log Duration | 0.27 | 0.303 |
| Commit Log Duration | 13 | 8.68 |
| Apply Log Duration | 0.457 | 0.514 |
由于 v5.4.0 版别中，TiKV 对 gRPC 模块进行了优化，优化了 Raft 日志仿制速度， 比较 v5.3.0 降低了 Commit Log Duration 和 Store Duration。
v5.3.0：
v5.4.0：
示例 2：Commit Log Duration 瓶颈显着的比方
均匀 Append Log Duration = 4.38 ms
- 均匀 Commit Log Duration = 7.92 ms
- 均匀 Apply Log Duration = 172 us
Store 线程的 Commit Log Duration 显着比 Apply Log Duration 高，并且 Append Log Duration 比 Apply Log Duration 显着的高，阐明 Store 线程在 CPU 和 IO 都或许都存在瓶颈。或许降低 Commit Log Duration 和 Append Log Duration 的方法如下：
- 假如 TiKV CPU 资源足够，考虑添加 Store 线程，即
raftstore.store-pool-size。 - 假如 TiDB 为 v5.4.0 及之后的版别，考虑启用
Raft Engine，Raft Engine 具有更轻量的履行途径，在一些场景下显著减少 IO 写入量和写入恳求的长尾推迟，启用方法为设置：raft-engine.enable: true - 假如 TiKV CPU 资源足够，且 TiDB 为 v5.3.0 及之后的版别，考虑启用
StoreWriter。启用方法：raftstore.store-io-pool-size: 1。
低于 v6.1.0 的 TiDB 版别怎么运用 Performance overview 面板
从 v6.1.0 起，TiDB Grafana 组件默许内置了 Performance Overview 面板。Performance overview 面板兼容 TiDB v4.x 和 v5.x 版别。假如你的 TiDB 版别低于 v6.1.0，需求手动导入performance_overview.json 3。
导入办法如图所示：
3、OLTP 负载功能优化实践
tidb.net/blog/f1637c…
4、Performance Overview 面板重要监控目标详解
tidb.net/blog/90492e…
