3.1 Sysbench 基准性能测试

3.1.1 工具集方案

  • sysbench 安装
  • 硬件配置
  • 环境说明
项目
操作系统 Redhat 7.4
TiDB 版本 TiDB-v3.0.5
TiDB & PD 每台 “TiDB 服务器” 部署 2 个 tidb-server + 1 个 pd-server
TiKV 每台 “TiKV 服务器” 部署 4 个 tikv-server
TiDB 关键参数 performance:
max-procs: 24
TiKV 关键参数 readpool:
coprocessor:
high-concurrency: 8
normal-concurrency: 8
low-concurrency: 8
storage:
block-cache:
capacity: “32GB”

3.1.2 测试实操

  • sysbench 配置
    2. mysql-port=4000
    3. mysql-user=sysbench
    4. mysql-password=******
    5. mysql-db=test
    6. time=60
    7. threads=16
    8. report-interval=10
    9. db-driver=mysql
  • sysbench 关键参数说明
    1. --threads=8 表示发起 8 个并发连接
    2. --report-interval=10 表示每 10 秒输出一次测试进度报告
    3. --rand-type=uniform 表示随机类型为固定模式，其他几个可选随机模式：uniform (固定)，gaussian (高斯)，special (特定的)，pareto (帕累托)
    4. --time=120 表示最大执行时长为 120 秒
    5. --events=0 表示总请求数为 0，因为上面已经定义了总执行时长，所以总请求数可以设定为 0；也可以只设定总请求数，不设定最大执行时长
    6. --percentile=99 表示设定采样比例，默认是 95%，即丢弃 1% 的长请求，在剩余的 99% 里取最大值
  1. sysbench 1.0.14 (using bundled LuaJIT 2.1.0-beta2)
  2. Running the test with following options:
  3. Number of threads: 16
  4. Report intermediate results every 10 second(s)
  6. Initializing worker threads...
  7. Threads started!
  8. # 每 10 秒钟报告一次测试结果，tps、每秒读、每秒写、95% 以上的响应时长统计
  9. [ 10s ] thds: 16 tps: 21532.38 qps: 21532.38 (r/w/o: 21532.38/0.00/0.00) lat (ms,95%): 1.04 err/s: 0.00 reconn/s: 0.00
  10. [ 20s ] thds: 16 tps: 21617.20 qps: 21617.20 (r/w/o: 21617.20/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
  11. [ 30s ] thds: 16 tps: 21550.98 qps: 21550.98 (r/w/o: 21550.98/0.00/0.00) lat (ms,95%): 1.03 err/s: 0.00 reconn/s: 0.00
  12. [ 40s ] thds: 16 tps: 21544.16 qps: 21544.16 (r/w/o: 21544.16/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
  13. [ 50s ] thds: 16 tps: 21639.76 qps: 21639.76 (r/w/o: 21639.76/0.00/0.00) lat (ms,95%): 0.99 err/s: 0.00 reconn/s: 0.00
  14. [ 60s ] thds: 16 tps: 21597.56 qps: 21597.56 (r/w/o: 21597.56/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
  15. SQL statistics:
  16.     queries performed:
  17.         read:                            1294886                        # 读总数
  18.         write:                           0                              # 写总数
  19.         other:                           0                              # 其他操作总数 (COMMIT 等)
  20.         total:                           1294886                        # 全部总数
  21.     transactions:                        1294886 (21579.74 per sec.)    # 总事务数 ( 每秒事务数 )
  22.     queries:                             1294886 (21579.74 per sec.)    # 读总数 ( 每秒读次数 )
  23.     ignored errors:                      0      (0.00 per sec.)         # 忽略错误数 ( 每秒忽略错误数 )
  25. General statistics:
  26.     total time:                          60.0029s                       # 总共耗时
  28. Latency (ms):
  29.          min:                                    0.36                   # 最小延时 
  30.          avg:                                    0.74                   # 平均延时
  31.          max:                                    8.90                   # 最大延时
  32.          95th percentile:                        1.01                   # 超过 95% 平均耗时
  33.          sum:                               959137.19 
  34. Threads fairness:
  35.     events (avg/stddev):           80930.3750/440.48                    # 平均每线程完成 80930.3750 次 event，标准差为 440.48
  36.     execution time (avg/stddev):   59.9461/0.00                         # 每个线程平均耗时 59.9 秒，标准差为 0
  • 准备数据
  • 数据预热与统计信息收集

数据预热可将磁盘中的数据载入内存的 block cache 中，预热后的数据对系统整体的性能有较大的改善，建议在每次重启集群后进行一次数据预热。以表 sbtest1 为例，执行如下 SQL 语句 进行数据预热，命令如下：

  1. SELECT COUNT(pad) FROM sbtest1 USE INDEX(k_1);

统计信息收集有助于优化器选择更为准确的执行计划，可以通过 analyze 命令来收集系列表 sbtest* 的统计信息，每个表都需要收集统计信息，以表 sbtest1 为例，命令如下：

  1. ANALYZE TABLE sbtest1;
  • Point select 测试命令
    1. sysbench --config-file=sysbench-thread-16.cfg oltp_point_select --tables=32 --table-size=10000000 run
  • Update index 测试命令
  • Read-only 测试命令
    1. sysbench --config-file=sysbench-thread-16.cfg oltp_read_only --tables=32 --table-size=10000000 run
  • Write-only 测试命令
    1. sysbench --config-file=sysbench-thread-16.cfg oltp_write_only --tables=32 --table-size=10000000 run

  • Read-Write 测试命令

  • oltp_point_select

  • read_only
type thread tps qps min latency avg latency 95th latency max latency
read_only 64 5984.48 95751.60 7.87 10.69 14.21 85.24
read_only 128 9741.39 155862.00 7.64 13.14 18.28 236.37
read_only 256 13080.20 209284.00 9.22 19.56 28.16 99.79
read_only 512 15678.40 250854.00 10.40 32.62 49.34 115.78
read_only 1024 17691.40 283063.00 10.87 57.73 87.56 378.12
read_only 2048 19086.60 305386.00 7.68 107.12 164.45 710.91

oltp_read_only.png

  • oltp_update_index
type thread tps qps min latency avg latency 95th latency max latency
write_only 64 7882.92 47297.50 3.05 8.12 12.52 341.78
write_only 128 9780.01 58680.10 3.07 13.08 21.50 504.41
write_only 256 11450.20 68701.20 3.12 22.34 36.89 6874.97
write_only 512 13330.00 79979.20 3.04 38.39 65.65 6316.33
write_only 1024 14761.20 88567.40 3.30 68.39 118.92 5426.65
write_only 2048 16825.20 100951.00 3.25 121.50 223.34 5551.31

  • read_write

oltp_read_write.png

3.1.3 总结

由于 TiDB 与 MySQL 在体系架构上的差别非常大，很多方面都很难找到一个共同的基准点，所以大家不要消耗过多精力在这类基准测试上，应该更多关注 TiDB 和 MySQL 在应用程序使用场景上的区别。MySQL 读扩容可以通过添加从库进行扩展，但单节点写入不具备扩展能力只能通过分库分表，而分库分表会增加开发维护方面成本。TiDB 不管是读流量还是写流量都可以通过添加节点的方式进行快速方便的扩展。