乐趣区

关于性能优化:TiDB-性能分析amp性能调优amp优化实践大全

jiezi

本文蕴含：

  • TiDB 性能优化概述
  • TiDB 性能剖析和优化
  • OLTP 负载性能优化实际
  • Performance Overview 面板重要监控指标详解

1、TiDB 性能优化概述

https://tidb.net/blog/1731b977

2、TiDB 性能剖析和优化

本文介绍了基于数据库工夫的系统优化办法，以及如何利用 TiDB Performance Overview 面板进行性能剖析和优化。

通过本文中介绍的办法，你能够从全局、自顶向下的角度剖析用户响应工夫和数据库工夫，确认用户响应工夫的瓶颈是否在数据库中。如果瓶颈在数据库中，你能够通过数据库工夫概览和 SQL 提早的合成，定位数据库外部的瓶颈点，并进行针对性的优化。

基于数据库工夫的性能优化办法

TiDB 对 SQL 的解决门路和数据库工夫进行了欠缺的测量和记录，不便定位数据库的性能瓶颈。即便在用户响应工夫的性能数据缺失的状况下，基于 TiDB 数据库工夫的相干性能指标，你也能够达到以下两个性能剖析指标：

  1. 通过比照 SQL 解决均匀提早和事务中 TiDB 连贯的闲暇工夫，确定整个零碎的瓶颈是否在 TiDB 中。
  2. 如果瓶颈在 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-txn 171 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 中，从输出查问文本到返回后果的典型解决流程。

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 是 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 线程会告诉外层申请写申请曾经实现。

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、OLTP 负载性能优化实际

https://tidb.net/blog/f1637cfd

4、Performance Overview 面板重要监控指标详解

https://tidb.net/blog/90492e9b

<div data-theme-toc=”true”> </div>

退出移动版