课程名称：课程版本（101/201/301）+ 课程名称
学习时长：
课程收获：
课程内容：
基准测试建议
-
实例选择原则
- TiDB 实例，使用高性能 CPU 的服务器
- TiKV 实例，使用高性能 SSD 的服务器，大于 16C，内存不要低于单机数据量的 10%，至少3台服务器
- PD 实例，不需要太高的 CPU 和内存（4C16GB），最好有 SSD
-
单实例 TiDB 的并发数控制在 500个 以内
-
多实例 TiDB 中
- 运行多个 benchmark 同时连接不同的 TiDB 实例，测试结果是所有实例 QPS 的总和
- 使用像 HAProxy 这样的负载均衡工具进行连接（可能会影响测试性能）
-
配置优化
- 参考官网中测试报告的配置
- 参考 TiKV 优化的相关课程
Sysbench 工具介绍
- Sysbench 是一个基于 LuaJIT 的脚本化多实例的基准测试工具，常用于做数据库 OLTP 性能测试
- Sysbench 提供的测试场景
- oltp_insert
- oltp_point_select
- oltp_update_index
- oltp_update_non_index
- oltp_read_write
- …
安装 Sysbench
配置 Sysbench
- 准备配置文件
- time 表示测试的持续实践
- threads 表示测试的并发数
Sysbench 加载数据
- 创建一个测试数据库
create database sbtest;
- 如果使用乐观锁事务，开启自动重试功能，避免提交冲突报错
set global tidb_disable_txn_auto_retry = off;
- 使用指定配置文件启动 sysbench 加载数据
- –tables，sysbench会创建指定数量的表
- –table-size，sysbench在创建的每个表中，导入指定数量的数据
sysbench --config-file=config oltp_point_select --tables=16 --table-size=10000000 prepare
启动 Sysbench 测试
- 收集每个表的统计信息
ANALYZE TABLE sbtest1;
…
ANALYZE TABLE sbtest7;
…
- 数据预热，建议每次重启集群之后都执行该步骤
SELECT COUNT(pad) FROM sbtest7 USE INDEX (k_7);
…
- 使用指定配置文件启动 Sysbench 测试
sysbench --config-file=config oltp_read_wirte --tables=16 --table-size=10000000 run --threads=64
Tips：在前面加载完数据之后，对 data 目录进行备份，每次测试之后用原来备份的目录覆盖再重新启动，这样可以保证每次使用不同并发数测试的时候基础数据是一致的
- 测试结果示例
TPC-C 工具介绍
-
TPC-C 是一个 OLTP 数据库性能测试工具。他使用一个电商平台销售模型进行测试，包括以下几种类型：
- NewOrder
- Payment
- OrderStatus
- Delivery
- StockLevel
-
tpm-C 表示每分钟新订单的事务数
-
Warehouse ，表示货品仓库，会进行商品动态调度。
- 2500 warehouse，大概160GB 的数据量
- 5000 warehouse，大概280GB 的数据量
- warehouse 数量越少，意味着越多客户从同一个仓库购买商品，以此事务冲突会越严重
安装 TPC-C
- 安装 java，ant 包
yum install -y java ant
- 修改 benchmarksql，添加兼容 MySQL 协议
git clone -b 5.0-mysql-suport-opt-2.1 https://github.com/pingcap/benchmarksql.git
cd benchmarksql; ant
配置 TPC-C
- 修改 tpcc 配置文件
- warehouse，商品仓库数量，影响数据量
- terminals，并发数
- loadWorkers，加载数据的并发数，不要设置过高，可能导致数据加载失败
TPC-C 加载数据
- 创建一个测试数据库
create database sbtest;
- 如果使用乐观锁事务，开启自动重试功能，避免提交冲突报错
set global tidb_disable_txn_auto_retry = off;
- 创建 tpcc 表结构
cd run && ./runSQL.sh props.mysql sql.mysql/tableCreates.sql && \
./runSQL.sh props.mysql sql.mysql/indexCreates.sql
- 导入 tpcc 数据
- 整个 tpcc 测试最耗时，最容易报错的步骤
- loadWorkers 参数不要设置过高
./runLoader.sh props.mysql
启动 TPC-C 测试
- 启动 benchmark
./runBenchmark.sh props.mysql
-
测试结果
- tpmC
-
数据一致性验证（可选）
- 如果所有 SQL 返回结果为空 ，则表示测试过程中 数据没问题
./runSQL.sh props.mysql sql.common/test.sql
测试过程的常见问题
-
增加并发数之后，为什么 TiKV 的 CPU 使用率仍然很低？
- 检查负载是否均衡，是否存在写热点
-
检查 TiKV 模块是否存在 CPU 瓶颈（查看监控模版：TiKV THread CPU Panel）
-
增加并发数之后，TiKV 的 CPU 没有达到瓶颈，为什么 CPU 使用率仍然很低？
- 考虑是否 NUMA 的影响，即跨服务器的内存访问
-
TiDB 和 TiKV 增大并发压力之后，为什么整体性能负载还是很低？
- 检查监控面板 TiDB ideal QPS
- 这里是根据并发和延迟反推出 QPS 的
- 该值应该跟实际的 QPS 差不多，如果相差过大，可能是客户端并发度达到瓶颈
- 也可能是 HAProxy 导致，可以尝试对单个 TiDB 进行测试
- 检查监控面板 TiDB ideal QPS