【TiDB】10-对 TiDB 进行 TPC-C 测试

目录

1、安装bench工具

2、插入数据

3、运行测试

4、测试结果分析

4.1、总体性能概览

4.2、事务类型详细性能

4.3、错误事务分析

4.4、结论与建议

5、清理测试数据


TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试,其中包含五类事务:

  • NewOrder -- 新订单的生成
  • Payment -- 订单付款
  • OrderStatus -- 最近订单查询
  • Delivery -- 配送
  • StockLevel -- 库存缺货状态分析

在测试开始前,TPC-C Benchmark 规定了数据库的初始状态,也就是数据库中数据生成的规则,其中 ITEM 表中固定包含 10 万种商品,仓库的数量可进行调整,假设 WAREHOUSE 表中有 W 条记录,那么:

  • STOCK 表中应有 W * 10 万条记录(每个仓库对应 10 万种商品的库存数据)
  • DISTRICT 表中应有 W * 10 条记录(每个仓库为 10 个地区提供服务)
  • CUSTOMER 表中应有 W * 10 * 3000 条记录(每个地区有 3000 个客户)
  • HISTORY 表中应有 W * 10 * 3000 条记录(每个客户一条交易历史)
  • ORDER 表中应有 W * 10 * 3000 条记录(每个地区 3000 个订单),并且最后生成的 900 个订单被添加到 NEW-ORDER 表中,每个订单随机生成 5 ~ 15 条 ORDER-LINE 记录。

TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput),其中 Transactions 以 NewOrder Transaction 为准,即最终衡量单位为每分钟处理的新订单数。

1、安装bench工具

复制代码
tiup install bench

错误如下:

The component `bench` not found (may be deleted from repository); skipped

由于在前面章节,采用离线方式部署tiup及tidb,不知道是否是这个原因导致无法安装

将tidb-community-toolkit-v8.1.0-linux-amd64 工具包中的 bench-v1.12.0-linux-amd64.tar.gz

复制到另一个位置后解压,然后配置环境变量。

在前面章节中,我的环境配置文件在 /home/tidb/.bashrc 中,

复制代码
cd /home/tidb
mkdir bench
cd bench
tar -zxf bench-v1.12.0-linux-amd64.tar.gz
复制代码
# 依据个人实际的环境变量位置 ,在线的方式 可能是 /root/.bashrc
vim /home/tidb/.bashrc

结尾处添加配置

复制代码
export PATH=/home/tidb/bench:$PATH

然后执行

复制代码
source /homt/tidb/.bashrc

2、插入数据

如果部署多个tidb-server服务,且端口都为4000,则命令中的IP可以用逗号隔开。

如 192.168.20.113, 192.168.20.114

复制代码
cd /home/tidb/bench

tiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456  -D tpcc --warehouses 100 --threads 20 prepare

其中参数:

--warehouses 100 表示执行100个批次,一个批次数据以文章最开始的表格数据

--threads 20 开启20 线程同时操作。

-D tpcc 数据库实例名

最终数据结果

数据导入完成后,可以通过命令 验证数据正确性。

tiup bench tpcc -H 192.168.20.113 -P 4000 -D tpcc --warehouses 4 check

3、运行测试

复制代码
tiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456 -D tpcc --warehouses 100 --threads 100 --time 10m run

运行过程中控制台上会持续打印测试结果:

复制代码
[Current] DELIVERY - Takes(s): 10.0, Count: 116, TPM: 698.9, Sum(ms): 37024.4, Avg(ms): 319.1, 50th(ms): 302.0, 90th(ms): 436.2, 95th(ms): 570.4, 99th(ms): 939.5, 99.9th(ms): 939.5, Max(ms): 939.5
[Current] NEW_ORDER - Takes(s): 10.0, Count: 1386, TPM: 8318.0, Sum(ms): 410842.4, Avg(ms): 296.3, 50th(ms): 251.7, 90th(ms): 486.5, 95th(ms): 637.5, 99th(ms): 906.0, 99.9th(ms): 1342.2, Max(ms): 1342.2
[Current] ORDER_STATUS - Takes(s): 10.0, Count: 126, TPM: 757.6, Sum(ms): 869.9, Avg(ms): 6.9, 50th(ms): 6.8, 90th(ms): 8.9, 95th(ms): 10.5, 99th(ms): 14.7, 99.9th(ms): 16.3, Max(ms): 16.3
[Current] PAYMENT - Takes(s): 10.0, Count: 1327, TPM: 7963.8, Sum(ms): 546047.8, Avg(ms): 411.6, 50th(ms): 352.3, 90th(ms): 704.6, 95th(ms): 872.4, 99th(ms): 1275.1, 99.9th(ms): 1543.5, Max(ms): 1610.6
[Current] STOCK_LEVEL - Takes(s): 10.0, Count: 137, TPM: 823.2, Sum(ms): 3402.9, Avg(ms): 24.9, 50th(ms): 10.0, 90th(ms): 15.2, 95th(ms): 130.0, 99th(ms): 243.3, 99.9th(ms): 302.0, Max(ms): 302.0

[Current] DELIVERY - Takes(s): 10.0, Count: 123, TPM: 740.3, Sum(ms): 35960.9, Avg(ms): 292.4, 50th(ms): 251.7, 90th(ms): 453.0, 95th(ms): 604.0, 99th(ms): 973.1, 99.9th(ms): 1040.2, Max(ms): 1040.2
[Current] NEW_ORDER - Takes(s): 10.0, Count: 1242, TPM: 7474.8, Sum(ms): 388801.1, Avg(ms): 313.2, 50th(ms): 260.0, 90th(ms): 536.9, 95th(ms): 704.6, 99th(ms): 1208.0, 99.9th(ms): 1610.6, Max(ms): 1610.6
[Current] ORDER_STATUS - Takes(s): 10.0, Count: 106, TPM: 638.4, Sum(ms): 766.2, Avg(ms): 7.2, 50th(ms): 6.8, 90th(ms): 9.4, 95th(ms): 14.7, 99th(ms): 18.9, 99.9th(ms): 21.0, Max(ms): 21.0
[Current] PAYMENT - Takes(s): 10.0, Count: 1243, TPM: 7472.7, Sum(ms): 571087.3, Avg(ms): 459.4, 50th(ms): 385.9, 90th(ms): 805.3, 95th(ms): 1040.2, 99th(ms): 1677.7, 99.9th(ms): 2415.9, Max(ms): 2818.6
[Current] STOCK_LEVEL - Takes(s): 9.9, Count: 111, TPM: 673.1, Sum(ms): 3125.7, Avg(ms): 28.1, 50th(ms): 11.0, 90th(ms): 65.0, 95th(ms): 113.2, 99th(ms): 285.2, 99.9th(ms): 570.4, Max(ms): 570.4

最终测试报告

复制代码
Finished
[Summary] DELIVERY - Takes(s): 599.7, Count: 6732, TPM: 673.5, Sum(ms): 2229639.0, Avg(ms): 331.4, 50th(ms): 302.0, 90th(ms): 503.3, 95th(ms): 637.5, 99th(ms): 939.5, 99.9th(ms): 1677.7, Max(ms): 2013.3
[Summary] NEW_ORDER - Takes(s): 599.9, Count: 74459, TPM: 7447.3, Sum(ms): 24556150.5, Avg(ms): 329.9, 50th(ms): 285.2, 90th(ms): 570.4, 95th(ms): 771.8, 99th(ms): 1275.1, 99.9th(ms): 2415.9, Max(ms): 4160.7
[Summary] NEW_ORDER_ERR - Takes(s): 599.9, Count: 23, TPM: 2.3, Sum(ms): 3316.2, Avg(ms): 144.5, 50th(ms): 151.0, 90th(ms): 251.7, 95th(ms): 704.6, 99th(ms): 872.4, 99.9th(ms): 872.4, Max(ms): 872.4
[Summary] ORDER_STATUS - Takes(s): 600.0, Count: 6703, TPM: 670.3, Sum(ms): 53463.5, Avg(ms): 8.0, 50th(ms): 7.3, 90th(ms): 10.0, 95th(ms): 13.1, 99th(ms): 18.9, 99.9th(ms): 159.4, Max(ms): 520.1
[Summary] PAYMENT - Takes(s): 599.9, Count: 71659, TPM: 7167.0, Sum(ms): 32908219.3, Avg(ms): 459.5, 50th(ms): 369.1, 90th(ms): 872.4, 95th(ms): 1140.9, 99th(ms): 1879.0, 99.9th(ms): 3221.2, Max(ms): 6174.0
[Summary] PAYMENT_ERR - Takes(s): 599.9, Count: 42, TPM: 4.2, Sum(ms): 10898.3, Avg(ms): 259.2, 50th(ms): 251.7, 90th(ms): 570.4, 95th(ms): 570.4, 99th(ms): 771.8, 99.9th(ms): 771.8, Max(ms): 771.8
[Summary] STOCK_LEVEL - Takes(s): 600.0, Count: 6630, TPM: 663.0, Sum(ms): 203118.1, Avg(ms): 30.7, 50th(ms): 11.5, 90th(ms): 79.7, 95th(ms): 167.8, 99th(ms): 335.5, 99.9th(ms): 604.0, Max(ms): 1409.3
[Summary] STOCK_LEVEL_ERR - Takes(s): 600.0, Count: 2, TPM: 0.2, Sum(ms): 22.2, Avg(ms): 11.3, 50th(ms): 10.0, 90th(ms): 13.1, 95th(ms): 13.1, 99th(ms): 13.1, 99.9th(ms): 13.1, Max(ms): 13.1
tpmC: 7447.3, tpmTotal: 16621.0, efficiency: 579.1%

4、测试结果分析

将测试结果交由AI分析,提示词:

以下是使用TPC-C 对TiDB服务进行压力测试结果,请分析测试结果

以下是基于提供的TPC-C压力测试结果的分析:

4.1、总体性能概览

  • tpmC (New Order 事务每分钟处理次数) : 7447.3
    • 这是TPC-C测试中最重要的指标,代表每分钟成功处理的New Order事务数。7447.3 表示系统每分钟处理约7447个New Order事务。
  • tpmTotal : 16621.0
    • 这是系统总体每分钟处理的所有事务(包括其他类型的事务)的总和。
  • 效率 (efficiency) : 579.1%
    • 这个值通常表示系统的利用率。超过100%的效率可能表示系统在超负荷运行,或者在一定程度上对事务进行了并发优化。

4.2、事务类型详细性能

  • DELIVERY

    • TPM: 673.5
    • 平均响应时间: 331.4ms
    • 最大响应时间: 2013.3ms
    • P99 响应时间: 939.5ms
    • 分析: DELIVERY事务的平均响应时间和P99响应时间相对较高,表明在高负载下,可能会出现瓶颈或延迟。
  • NEW_ORDER

    • TPM: 7447.3
    • 平均响应时间: 329.9ms
    • 最大响应时间: 4160.7ms
    • P99 响应时间: 1275.1ms
    • 分析: New Order事务是TPC-C测试中的关键负载类型。该事务的平均响应时间相对较好,但P99响应时间较高,可能意味着系统在高负载时有较大延迟。
  • ORDER_STATUS

    • TPM: 670.3
    • 平均响应时间: 8.0ms
    • 最大响应时间: 520.1ms
    • 分析: 这是一个相对较轻的查询操作,响应时间较低。性能表现良好。
  • PAYMENT

    • TPM: 7167.0
    • 平均响应时间: 459.5ms
    • 最大响应时间: 6174.0ms
    • P99 响应时间: 1879.0ms
    • 分析: PAYMENT事务的平均响应时间和P99响应时间较高,最大响应时间超过6秒,显示了在负载下可能存在性能瓶颈。
  • STOCK_LEVEL

    • TPM: 663.0
    • 平均响应时间: 30.7ms
    • 最大响应时间: 1409.3ms
    • 分析: 作为库存查询操作,响应时间总体良好,但在极端情况下(最大响应时间)可能会有明显的延迟。

4.3、错误事务分析

  • NEW_ORDER_ERR: 出现了23次错误,平均响应时间144.5ms,最大872.4ms。
  • PAYMENT_ERR: 出现了42次错误,平均响应时间259.2ms,最大771.8ms。
  • STOCK_LEVEL_ERR: 出现了2次错误,响应时间较低,可能是轻微的错误。
  • 分析: 错误事务数量较少,说明系统在高负载下的稳定性还算不错,但仍需关注事务错误的原因。

4.4、结论与建议

  1. 瓶颈分析: 主要的瓶颈似乎出现在NEW_ORDER和PAYMENT事务中,尤其是在P99和最大响应时间上。可以考虑优化数据库索引、优化SQL查询、或增加硬件资源以改善高负载下的性能。

  2. 事务延迟: 在DELIVERY、NEW_ORDER和PAYMENT事务中的P99和最大响应时间较高,这可能会影响用户体验。建议检查这些事务的执行路径,找出潜在的延迟点。

  3. 系统效率: 效率为579.1%可能表示系统正在过度利用资源,或者在并发负载下有较大的优化空间。建议进一步调查系统资源的利用情况(CPU、内存、磁盘IO等),并根据需求进行调整。

  4. 错误事务: 错误事务数量不多,但需要详细调查这些事务失败的原因,以避免在实际生产环境中出现类似问题。

5、清理测试数据

复制代码
tiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456 -D tpcc --warehouses 4 cleanup

DROP TABLE IF EXISTS item

DROP TABLE IF EXISTS customer

DROP TABLE IF EXISTS district

DROP TABLE IF EXISTS history

DROP TABLE IF EXISTS new_order

DROP TABLE IF EXISTS order_line

DROP TABLE IF EXISTS orders

DROP TABLE IF EXISTS stock

DROP TABLE IF EXISTS warehouse

Finished

参照文章:

如何对 TiDB 进行 TPC-C 测试 | PingCAP 文档中心

相关推荐
微风轻吟挽歌3 天前
TIDB创建索引失败 mkdir /tmp/tidb/tmp_ddl-4000/1370: no such file or directory.
数据库·oracle·tidb
Lucifer三思而后行14 天前
深入解析分布式数据库TiDB:原理、优化与架构实践
数据库·分布式·tidb
TiDB 社区干货传送门20 天前
从开发者角度看数据库架构进化史:JDBC - 中间件 - TiDB
数据库·oracle·中间件·tidb·数据库架构
TiDB 社区干货传送门20 天前
从40秒到11毫秒:TiDB环境下一次SQL深潜优化实战
数据库·sql·tidb
赵渝强老师1 个月前
【赵渝强老师】TiDB SQL层的工作机制
数据库·sql·tidb
观测云1 个月前
TiDB 可观测性最佳实践
tidb
赵渝强老师1 个月前
【赵渝强老师】使用TiDB的审计日志
数据库·tidb
可观测性用观测云1 个月前
TiDB 可观测性最佳实践
tidb
Sirius Wu1 个月前
TiDB 深度解析与 K8S 实战指南
容器·kubernetes·tidb
PingCAP1 个月前
PingCAP“一号员工”唐刘:回顾我与 TiDB 的十年成长之旅
数据库·tidb