原文来源：https://tidb.net/blog/fc072338

背景

在信创和国产化的背景下，政企银行国企等会在不久的将来全面实现国产化。就银行业底层使用的数据库而言，会逐步从小 oracle 小机、DB2 大机等国外产品逐步替换为使用国产数据库，从边缘系统开始替换积累使用经验，后逐渐全面覆盖到核心系统。

在核心系统迁移到国产数据库前，需要做很多测试工作，其中很关键的一项的测试就是应用压测，应用压测可以模拟真实业务场景中用户使用，得到系统最真实的性能表现。作者在最近在某银行进行一次核心系统 poc 测试之后，将测试中的一些想法和调优手段进行整理之后编写这篇文章。

文章内容导读

应用压测架构

在通常的应用压测架构中，会在在压测端配置好压测任务项。

主要配置信息有：1、应用请求接口；2、模拟请求数据集；3、压测任务用户数（请求并发数）。

开始压测后，压测机根据配置的用户并发数，向应用集群发送一个或多个请求，通常在一个请求中，应用会向数据库发送多次请求，数据库也会多次向应用返回结果集，即一次压测请求，应用和数据库可能会有多次交互。

应用压测方式与目标

对于应用压测结果的考察有如下通常两种模式：

1. 在同等机器资源下，固定压测用户并发下，测试得到 TPS。

2. 在同等机器资源下，可调整加大压测用户并发，直至测出性能拐点，取最高的 TPS 作为成绩。

在进行应用压测前还需要知道一些概念：

1. 应用压测 TPS 不等于数据库事务 TPS。应用压测 TPS 概括的生命周期是压测机向应用发起请求到请求回复结束，数据库事务 TPS 生命周期是 begin 和 end 之间

2. 对于考察固定压测并发，通常应用和数据库都不会有资源瓶颈，最终压测结果和数据库 sql 执行的快慢强相关。

3. 对于可以加大并发测出拐点性能的考察模式，理论上压测结果与 sql 执行快慢和 sql 执行成本强相关。

4. TPS* 平均响应延时 =1，系统平均响应越快，耗时越短，TPS 越高。

小插曲

作者在某次 poc 测试时，目标是测试出拐点性能，但是压测平台显示增加了压测并发之后，TPS 无明显提升，且数据库各项资源使用率 <50%，后面排查到原因是应用服务器资源使用达到了瓶颈，导致的即使再增加压测并发，应用也不能处理更多的请求，这样 TPS 也不会有提升。

这个也给作者了一个启发，虽然压测的目标是换国产数据库去测试，想去测试国产数据库性能，但是应用压测实际上测试的是整个系统的能力，调优要把视野放大。这点很重要，后面会谈到调优排查到应用的问题。。。

tidb 高性能部署原则

tikv 节点部署推荐

tikv 磁盘部署最佳实践是利用上服务器本地多块高速磁盘进行部署，例如 nvme ssd 等。在 poc 中，不推荐像单机数据库一样使用中心化存储，nas 存储等，有多块盘也不推荐做 raid,tidb 原生多副本就具有高可用性。

通常单台服务器如果有多块磁盘，会考虑每块磁盘上部署一个 tikv 节点，如果只有一块磁盘也可以考虑部署两个 tikv 节点

tidb server 节点部署推荐

通常建议 tidb server 数据量不低于 tikv 节点数据量。在多次实测中表明，在平均每台服务器只部署了一个 tidb 节点的情况下, 将 tidb server 数量进行扩容，集群性能有提升。

pd 节点部署推荐

推荐 pd 部署在 ssd 上；通常无特殊要求，部署三个节点就行；如果涉及到跨中心测试，推荐参考多中心部署多 pd leader 来避免 tso wait 过高，参考：专栏 - 三地五中心，TiDB POC 最佳实践探索 | TiDB 社区

推荐组件绑定 numa 核心

tidb 的组件绑定 numa 核心后，可避免 cpu 跨通道访问内存带来的延迟过高。但是存在的问题就是绑定核心的组件只能使用该核心分配的内存，例如 tikv 混布又绑定了核心，如果涉及到 tikv 可用内存不足够 block cache 使用，这就得实测判断是否绑定核心。

业务环境与部署选择

在上述部署推荐中，我有建议部署多数量节点的趋势，也推荐组件去绑定 numa 核心，这样会涉及到节点混布下，节点相关参数调低，或单组件可用内存上限降低，造成单组件上限瓶颈降低。

但通常而言，核心系统都是都是纯交易系统，功能模块例如：跨行转账，账户信息查询等，几乎都是低成本扁平化 sql, 多个节点资源使用比较均衡，所以不会存在大 expensive sql 造成的瓶颈问题。

连接 TIDB 的方式

使用 mysql 8.0 驱动连接 tidb

#链接需要加上预编译处理的参数url: jdbc:mysql://IP:PORT/DB_NAME?useUnicode=true&characterEncoding=UTF-8&useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSqlLimit=1000000000&prepStmtCacheSize=102400&useConfigs=maxPerformance&rewriteBatchedStatements=true

使用 tidb loadblance 驱动连接 tidb

在 poc 测试中更推荐使用该驱动去直连接 tidb, 多次实测表明，使用该驱动会比 mysql 驱动连接 f5 等负载均衡的方案性能要好一点。

但是该驱动暂未正式 GA, 作者也在使用过程中发现一些其他问题，记录一下：

遇到的问题一：使用该驱动可能会导致负载不均衡

解决方案：添加 random 参数 jdbc:tidb://{ip}:{port}/db?tidb.jdbc.url-mapper=random

遇到的问题二：该驱动所带的负载均衡没有该可用策略，部分 tidb server 节点失活后，请求还是会持续转发到失活节点，导致应用持续报错。

参考 haproxy 探活，检测到下游节点失活后，后续请求不会转发到不可用节点。

listen tidb-cluster                        # 配置 database 负载均衡。   bind 0.0.0.0:3390                       # 浮动 IP 和 监听端口。   mode tcp                                # HAProxy 要使用第 4 层的传输层。   balance leastconn                       # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。   server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3          # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。   server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3   server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3

优化 SQL 解析、编译、优化生成执行计划时间

使用预编译 +prepare plan_cache 进行调优

1、连接串添加预编译的参数

useServerPrepStmts=true&prepStmtCacheSqlLimit=10000000000&prepStmtCacheSize=102400&useConfigs=maxPerformance&rewriteBatchedStatements=true

2、调整数据库 prepare plan cache 参数

3、检查 plan_cache 效果

dashboard 上能看到大部分 sql 解析时间为 0 ，优化时间为微秒级

4、判断是否还需要调整 prepare plan_cache 参数

plan cache 内存使用小于参数值，且 plan_cache 命中率高, 无需调整参数

未使用使用预编译提交 sql

1、开启数据库参数

2、查看效果。

由于 non prepared_plan_cache 这个功能刚出，大量受到限制的 sql 无法走上该功能

tidb 相关参数调整与建议

tidb server {#可以减少日志打印log.level: errorlog.slow-threshold: 3000}

tikv{gc.enable-compaction-filter = truelog.level = error#如下参数不再给具体值建议，根据环境情况来，最佳性能模式下，这些参数的原则是：不会造成瓶颈。raftstore.store-pool-size: readpool.unified.max-thread-count:server.grpc-concurrency:storage.block-cache.capacity:
}

排查全局负载均衡

1、排查应用负载是否均衡

观察应用集群每台应用服务器 cpu 使用率和内存使用率是否均衡

2、查看 tidb server 连接数和请求是否均衡

连接均衡是请求均衡的前提条件，请求均衡才是目的

3、排查 tikv region 和 region leader 是否均衡

4、排查 tikv 请求是否均衡

由于请求类型与请求消耗资源关联有可能非常大，所以我一般直接去看 tikv 相关的线程使用率是否均衡

SQL 调优与常见方向

1、补全索引等

参考：

SQL 性能调优 | PingCAP 文档中心

2、改写 sql

有些 sql 的写法走不了 plan_cache，参考：Prepare 语句执行计划缓存 | PingCAP 文档中心

有些 sql 如标量子查询连接没法下推等。

3、优化表结构

例如：nocluster 表换成聚簇表，即找高频唯一索引查询变成 clustered index

缓存表

缓存表 | PingCAP 文档中心

可以考虑给只有 DQL, 没有 DML 操作的表加缓存表

1、找到所有 DQL 操作的表 (可借助 dashboard)

2、判断这些这些表 sql 没有 DML 操作的表 (可借助 dashboard)

3、ALTER TABLE table_name CACHE

基于颜色优化法排查数据库瓶颈

Performance Overview 面板重要监控指标详解 | PingCAP 文档中心

TiDB 性能分析和优化方法 | PingCAP 文档中心

通过去看整个 sql 执行流程上各阶段耗时去整体评估系统是否存在性能问题，通常颜色深的部分占比大需要注意和排查

优化 coprocessor cache

1、观察监控，miss 的可能是因为 region 有修改，这个没办法，evict 要是多可能是因为 cache 大小不够而产生的缓存淘汰，可以调大 cop cache 参数

2、调整capacity-mb的大小。

小表热点

可能会存在这样一种情况，某张表只有几万行，这个时候大概率这张表只有一个 region（raft group 这里先不讨论），这样对这张表所有的读写都会集中在一个 tikv 上，但是在进行应用压测的时候这个 SQL 是高频 sql, 热力图上也显示该 sql 读写流量高，这个时候会出现热点瓶颈，也导致整体延时上升

取巧方案：

pdctltiup ctl:v<CLUSTER_VERSION> pd -u http://<pd_ip>:<pd_port> [-i]
1、临时关闭合并region的调度config set max-merge-region-keys 50config set max-merge-region-size 1
2、多次切割region切割regionoperator add split-region 1 --policy=scan

尝试开启非可重复读

在不介意幻读的情况下，可设置该参数，可显著降低 tso_wait 耗时

该参数是实例级别，需要依次连接每一个实例去设置set  tidb_rc_read_check_ts =on

如果应用事务里面依赖可重复读，开这个参数可能会报错，例如：在一个事务里面多次查序列

排查数据库外耗时

当整个系统响应耗时大部分不在数据库侧时，这时候即使在数据库侧优化的再好，也没办法去优化好整体性能

1、大致评估系统外耗时

TiDB 性能分析和优化方法 | PingCAP 文档中心

2、如果感觉连接空闲时间很长，即数据库外耗时多，则需要排查应用 - 数据库之间网络延迟，应用资源使用率等

作者在某次排查到应用集群时发现，所有的应用服务器上某个端口的应用实例没有起，所以其实应用出问题也是很正常的。

算计 GC 间隔与压测项时长

默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据。通常而言压测环境美伦 GC 任务耗时 <2min

常见的应用压测项耗时，10 分钟、15 分钟。在这种配置下，几乎每轮压测期间都会执行 GC 任务

为了达到更稳定优异的性能，可以把tidb_gc_run_interval 调大，例如调整到 1 小时做一次，大概率压测期间就不会碰到在做 GC 了

手动进行 compaction

可以手动对 TIKV 进行 compact 操作后再进行压测，谋求更优异的性能

TiKV Control 使用说明 | PingCAP 文档中心

写在最后

1、应用系统压测是对一个系统性能的检验，调优会涉及到方方面面，软件、cpu、内存、网络等等。

2、带你重走 TiDB TPS 提升 1000 倍的性能优化之旅 | PingCAP，写完文章后找到了一篇官方在 V5 时代出的一篇性能压测的文章，分析的更细致和循序渐进，可以看一看，其中思想和我的文章有重复的，但是我最佳 poc 大多是基于 V6 和 V7 版本做的，有一些新特性。官方文章更侧重讲思路和推理分析，而我这更侧重可行性实操分享。

作者介绍：BraveChen，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库 TiDB 整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有 TiDB 高级资格证书，并活跃于 TiDB 开源社区，是官方认证合作伙伴。目前已为 10+ 客户提供了专业的 TiDB 交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。