---
title: 'TiDB 可观测性 UP！UP！UP！ Performance Overview 面板开启 TiDB 性能调优自助服务时代'
date: '2022-06-30T00:00:00+08:00'
status: publish
permalink: /blog/performance-overview-dashboard-enable-self-service-for-tidb-performance-tuning
author:
- PingCAP
- PingCAP
- 宋昱颖
excerpt: 'Performance Overview 面板在 TiDB v6.1.0 正式发布，为所有 TiDB 用户提供一个系统级别的总体性能诊断入口。本文详细介绍了 Performance Overview 面板的设计理念及应用实践。'
type: post
id: 3141
category:
- 产品技术解读
tag:
- 'TiDB 性能调优'
post_format: []
profile:
- 宋昱颖
algolia_posts_post_records_count:
- '6'
---
Performance Overview 面板 —— 数据库人的浪漫：原本纷繁复杂的监控数据，被化繁为简。只此青绿间，系统瓶颈，一目了然。数据库性能调优，也可以很舒心写意。
Performance Overview 面板在 TiDB v6.1.0 正式发布，为所有 TiDB 用户提供一个系统级别的总体性能诊断入口。本文详细介绍了 Performance Overview 面板的设计理念及应用实践。
本文作者：**宋昱颖**，PingCAP 数据库性能测试工程师，Performance Overview 面板作者之一。有 5 年的数据库性能调优和性能诊断工具的设计开发经验，目前在 PingCAP 主要负责数据库性能测试服务化建设和数据库性能调优工作。 曾在 Oracle Real-World Performance 团队担任高级数据库性能工程师。
Highlight
---------
Performance Overview 面板，为所有 TiDB 用户提供一个系统级别的总体性能诊断入口。它是 TiDB 监控 Grafana 可视化组件中的一个新增面板，在 TiDB v6.1.0 正式发布，首次在 TiDB 中引入数据库时间的调优概念和颜色优化法。
作为 TiDB 的普通用户，我们终于不用在海量的监控数据中，苦苦挖掘自己想要用的性能指标了。Performance Overview 面板结合基于数据库时间分析法和颜色优化法，对 TiDB 的性能指标按照一种自上而下的性能分析方法论做了重新梳理并主要以青绿色系着色，为 TiDB 用户提供一个系统级别的总体性能诊断入口。只此青绿间，用户可以很直观地从颜色上一眼看到整个系统的性能瓶颈在哪里，只需 5分钟就能定位到问题的方向，数量级地缩短了性能诊断时间和减少了性能分析和诊断难度。数据库性能调优，也可以很舒心写意。
通过 Performance Overview 面板，我们建立 TiDB 性能优化的体系，并撰写了首版 TiDB 性能优化三部曲。从原理到实际案例，优化三部曲详细地介绍了 TiDB 性能诊断的方法论和 Performance Overview 面板的使用，并随 v6.1.0 发布。
一个用户的数据库时间分解图样例，远看似青峰叠嶂，绿水隐现。 透过此图，一眼可知系统负载为以读为主的读写混合负载。
用户问题
----
用户反馈：
- TiDB 监控数据太多，学习门槛高。
- 目前 TiDB 的 Grafana 监控面板多达十几个，主要是按 TiDB 的各个组件分类和编排，可谓十分全面。众多的指标都是 PingCAP 的研发和广大社区贡献者的心血和劳动结晶，却没有被很好的利用到性能调优工作中。究其原因，主要是众指标缺乏合理的编排而用户也缺少一种可靠的、可重复的方法论，从而导致 TiDB 性调优学习门槛很高，让用户望而生畏。
- 用户在使用 TiDB 的过程中基本只看 Dashboard 的 QPS 面板。
- 性能调优玄学化，缺乏可靠、可重复的方法论和配套的工具。
- 性能诊断耗时长，难度大，对专家依赖程度高。
解决方案
----
通过 Performance Overview，TiDB 落地了基于数据库时间的分析方法和颜色优化法。对于普通用户的意义在于，TiDB 性能分析和优化的难度、需要消耗的人力、对专家经验的依赖数量级的下降。
### 以数据库时间为基础，以颜色为标识，帮助快速定位性能瓶颈
一个典型的 SQL 的处理流程如下所示，TiDB 的性能指标覆盖了绝大部分的处理路径，Performance Overview 面板对数据库时间进行不同维度的分解和上色，用户可以快速的了解负载特性和数据库内部的瓶颈。
数据库时间分解图和执行时间概览图
如上图所示，数据库时间是所有 SQL 处理时间的总和。通过以下三个维度对数据库时间进行分解，Performance Overview 面板可以帮助你快速定位 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`
#### 颜色优化法
通过观察数据库时间分解图和执行时间概览图，你可以直观地区分正常或者异常的时间消耗，快速定位集群的异常瓶颈点，高效了解集群的负载特征。对于正常的时间消耗和请求类型，我们以令人舒心的青绿色系着色，即在图中显示为绿色系或蓝色系。灵感来源是北宋青绿山水画中的彪炳巨作《千里江山图》。**如果非青绿色系的颜色在这两张图中占据了明显的比例，比如出现大面积令人警醒的赤红色，意味着数据库时间的分布存在不合理，用户需要关注并及时处理。**
- 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 等待的消耗时间过长时，深褐色会占比明显。
《千里江山图》
### 化繁为简，精选关键性能指标
Performance Overview Dashboard 按总分结构对精心挑选的 TiDB、TiKV、PD 的性能指标进行编排组织，包含了以下三部分内容：
1. 总体概览：数据库时间和 SQL 执行时间概览，通过颜色优化法，快速识别数据库负载特征和性能瓶颈
2. 资源负载：关键指标和资源利用率，包含数据库 QPS、应用和数据库的连接信息和请求命令类型、数据库内部 tso 和 kv 请求 OPS、TiDB 和 TiKV 的资源使用概况。
3. 自上而下的延迟分解：Query 延迟和连接空闲时间对比、Query 延迟分解、execute 阶段 tso 请求和 kv 请求的延迟、TiKV 内部写延迟的分解等。
### 使用示例
#### 例子 1
**在缓存表的功能测试阶段：一眼定位负载瓶颈和找到产品改进方向**
在[缓存表](https://docs.pingcap.com/zh/tidb/dev/cached-tables)功能测试阶段，从上图可见两段负载，第一段是开启了缓存表功能的情况，第二段是关闭该功能的情况。通过对比 QPS 值，我们不难发现开启[缓存表](https://docs.pingcap.com/zh/tidb/dev/cached-tables)功能时性能还下降了。另外一眼可见第三幅图颜色异常，tso\_wait 占用数据库时间过长。后来诊断发现，代码开发阶段没有做相关的优化。通过 Performance Overview 面板，我们一下可以定位产品改进的方向。
#### 例子 2
**云上某客户订单系统：判断瓶颈是否在数据库内部**
平均 Query Duration 为 1.69ms，事务中连接空闲时间 (Connection Idle Duration) avg-in-txn 为 18ms。说明事务中，TiDB 平均花了 1.69ms 处理完一个 SQL 语句之后，需要等待 18ms 才能收到下一条语句。用户响应时间的瓶颈不在 TiDB 中。和客户沟通后发现，系统瓶颈是客户应用和数据库分别部署在相距 700 公里的两个不同的数据中心导致的网络延迟。
#### 例子 3
**云上某客户社交平台系统：定位两个时间段性能巨大差异的根源**
客户测试系统某天突然出现异常。通过对比系统正常和异常两个时间段的 SQL Execute Time Overview 面板，我们可以看到异常时间段负载中出现了超多的 Cop 请求，严重影响了正常的应用负载。进一步通过 tikv-detail 的面板，确认 Cop 请求来源于 analyze 操作。性能回退根源是业务高峰期出现了异常的统计信息收集操作。
系统正常时间段：
Performance Overview 面板
tikv-detail 的面板
系统异常时间段： 
Performance Overview 面板
tikv-detail 的面板官方解读
----
通过 Performance overview，我们建立 TiDB 性能优化的体系，并撰写了首版 TiDB 性能优化三部曲，随着 v6.1 发版
1. [优化概述](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-overview)：本文介绍性能优化的基本概念，比如用户响应时间、吞吐和数据库时间，以及性能优化的通用流程。
2. [优化方法](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-methods)：本文介绍了基于数据库时间的系统优化方法，以及如何利用 TiDB [Performance Overview 面板](https://docs.pingcap.com/zh/tidb/dev/grafana-performance-overview-dashboard)进行性能分析和优化。包括面板每个指标的含义，正常指标范围，导致指标异常的常见原因有哪些和常见的调优手段有哪些等。
3. [优化实践](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-practices)：TiDB 提供了完善的性能诊断和分析功能，例如 TiDB Dashboard 的 [Top SQL](https://docs.pingcap.com/zh/tidb/dev/top-sql) 和 [Continuous Profiling](https://docs.pingcap.com/zh/tidb/dev/continuous-profiling) 功能，以及 TiDB [Performance Overview 面板](https://docs.pingcap.com/zh/tidb/dev/grafana-performance-overview-dashboard)。本文介绍如何综合利用这些功能，对同一个 OLTP 负载在七种不同运行场景下的性能表现进行分析和对比，并演示了具体的 OLTP 负载的优化过程，帮助你更快地对 TiDB 的性能进行分析和优化。
FAQ
---
1.在哪里可以找到 Performance Overview 面板？
- 从 v6.1.0 起，TiDB Grafana 组件默认内置了 Performance Overview 面板。
- 如果你的 TiDB 版本低于 v6.1.0，需要手动导入 [`performance_overview.json`](https://github.com/pingcap/tidb/blob/master/pkg/metrics/grafana/performance_overview.json)。Performance overview 面板兼容 TiDB v4.x 和 v5.x 版本。导入方法如图所示：
2.请问有相关的使用文档吗？
- Performance Testing Team 年度诚意之作——优化三部曲
1. [优化概述](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-overview)：本文介绍性能优化的基本概念，比如用户响应时间、吞吐和数据库时间，以及性能优化的通用流程。
2. [优化方法](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-methods)：本文介绍了基于数据库时间的系统优化方法，以及如何利用 TiDB [Performance Overview 面板](https://docs.pingcap.com/zh/tidb/dev/grafana-performance-overview-dashboard)进行性能分析和优化。包括面板每个指标的含义，正常指标范围，导致指标异常的常见原因有哪些和常见的调优手段有哪些等。
3. [优化实践](https://docs.pingcap.com/zh/tidb/dev/performance-tuning-practices)：TiDB 提供了完善的性能诊断和分析功能，例如 TiDB Dashboard 的 [Top SQL](https://docs.pingcap.com/zh/tidb/dev/top-sql) 和 [Continuous Profiling](https://docs.pingcap.com/zh/tidb/dev/continuous-profiling) 功能，以及 TiDB [Performance Overview 面板](https://docs.pingcap.com/zh/tidb/dev/grafana-performance-overview-dashboard)。本文介绍如何综合利用这些功能，对同一个 OLTP 负载在七种不同运行场景下的性能表现进行分析和对比，并演示了具体的 OLTP 负载的优化过程，帮助你更快地对 TiDB 的性能进行分析和优化。
- [Performance Overview 面板重要监控指标详解](https://docs.pingcap.com/zh/tidb/dev/grafana-performance-overview-dashboard)