【TiDB 4.0 PCTA 学习笔记】- 2.3.4 How to Benchmark（如何对 TiDB 进行基准测试）@2班+欧阳

xuanyuan · 2020 年12 月 20 日 03:06

课程名称：2.3.4 How to Benchmark（如何对 TiDB 进行基准测试）

学习时长：30min

课程收获：Sysbench，TPCC on TiDB

课程内容：

benchmark建议
- 实例选择规则
  - TiDB实例：计算优化
  - TiKV实例：存储优化，16C+，大内存更好，不少于3个
  - PD实例：可使用低速CPU低容量内存（4C16G），最好有SSD，因为分配TSO需要写盘
- 每个TiDB最好控制并发在500以内
- 多个TiDB的话
  - 同时进行benchmark，之后汇总
  - 使用像 HAProxy之类的负载均衡器
- 配置优化
  - 参考官网配置优化报告
  - 参考TiKV优化
使用sysbench
- 基于LuaJIT的多线程工具，适用于数据库OLTP 测试
- https://github.com/akopytov/sysbench
- 提供场景：
  - oltp_insert
  - oltp_point_select
  - oltp_update_index
  - oltp_update_non_index
  - oltp_read_write
  - …
- 准备配置文件
  - ![]
- 创建测试数据库
  - create database sbtest;
- 如果使用乐观锁，打开auto retry
  - set global tidb_disable_txn_auto_retry = off;
  - 4.0之前默认是乐观事务
  - 4.0之后默认是悲观事务
- 使用配置文件运行sysbench进行加载
  - sysbench --config-file=config oltp_point_select --tables=16 --table-size=10000000 prepare
- 分析表
  - analyze table sbtest7;
- 通过select进行预热
  - select count(pad) from sbtest7 use index (k_7);
- 运行
  - 建议先备份数据，以方便多次运行（TiKV+PD的数据）
  - sysbench --config-file=config oltp_point_select --tables=16 --table-size=10000000 run --threads=64
  - 在进行下一轮测试之前，先停止集群，用备份覆盖，启动，再运行下一次测试
- 测试结果
TPC-C
- OLTP测试工具，通过使用商品销售模型来进行以下五种不同的事务
  - 新订单
  - 支付
  - 订单状态
  - 配送
  - 库存
- tpmC：每分钟生成的新订单数量
- 仓库数量越少，事务冲突越严重
- 构建
  - java
    - sudo yum install -y java ant
  - 构建mysql协议支持的benchmarksql
    - git clone -b 5.0-mysql-supoort-op5-2.1 https://github.cin/pincap/benchmarksql.git
    - cd benchmarksql; ant
- 修改tpcc配置
  - warehouse，仓库数量
  - terminals，终端数，即并发数
  - loadWorkers，倒入数据的并发数
- 加载
  - create database tpcc;
  - 如果使用乐观锁，打开auto retry
    - 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
  - 加载
    - ./runLoader.sh props.mysql
- 运行
  - ./runBenchmark.sh props.mysql
- 结果
- 检查一致性（可选）
  - ./runSQL.sh props.mysql sql.common/test.sql
常见问题
- 更高的并发，为什么TiKV的CPU用量还是很低？
  - 检查负载是否均衡
    - 写入是否有热点，写入是否均匀
  - 检查TiKV模块上是否有CPU瓶颈（TiKV Thread CPU Panel）
    - 有的话，可以适当增加模块儿的并发度
- 假设在高并发下TiKV尚未达到CPU用量瓶颈，为什么TiDB的CPU使用率很低？
  - 原因可能是NUMA
    - 跨NUMA访问内存，降低性能
    - TiDB默认会使用所有的CPU，因此建议在开启NUMA的机器上运行N（N=NUMA节点个数）的TiDB
- TiDB和TiKV配置合理，CPU未达到瓶颈，为什么整体性能还是很低？
  - 检查TiDB理论上的QPS（默认不限时，需要在Grafana配置）
  - 如果实际QPS和理论QPS相差太多，很可能是客户端达到了瓶颈
  - proxy调整或压测单台然后汇总