TIDB4.0 5.0 压测

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
5.0 版测试
配置:
TIDB+PD+monitor 3台 8C 16G 100g硬盘
TIKV 3台 8C 16G 100g硬盘
DM+monitor+worker 1台 4C 8G 100g硬盘
TIFLASH 2台 8C 16G 100g硬盘
WORKER 1台 4C 8G 100g硬盘
【问题描述】

  1. 使用navicat无法看到INFORMATION_SCHEMA 下表,使用命令或sql可以查询到
    navicat试过 10.* 12.*
    image
    2.压测导致tiflush超时:什么原因?
    说明:2.1 压测指标 jmeter 32线程 32 连接 执行sql (尝试16线程 16连接数也是同样问题)
    2.2 同样SQL 、压测指标4.0 QPS:2
  2. 4.0 5.0 压测结果
    tiflush查询新能提升明显,tikv查询性能下降
  3. 执行计划
    sql中使用的关联均为主键,但是没有走索引?
  4. 数据库连接池问题
    使用jmeter压测时,线程数100,连接数32 报错线程时内无可用线程
    使用Mysql时不存在该问题,可能与SQL执行过慢有关,进一步排查中

附:sql:

select
t1.group_id,
t1.company_id,
t1.business_id,
t2.ware_inside_code,
sum(FLOOR(COALESCE(t4.ware_qty * t4.ware_price,t2.ware_qty * t2.ware_price * t2.group_qty) * IF(t2.separated = 1,t2.separate_rate,1))),
sum(FLOOR(COALESCE(t4.ware_qty * t4.net_price,t2.ware_qty * t2.net_price * t2.group_qty) * IF(t2.separated = 1,t2.separate_rate,1)))
from h3_tmp_test.t_order_info t1
left join h3_tmp_test.t_order_detail t2
on t1.order_id = t2.order_id
left join h3_tmp_test.t_order_outbound t3
on t2.order_id = t3.order_id
left join h3_tmp_test.t_order_outbound_detail t4
on t3.id = t4.outbound_id
and t2.row_number = t4.row_number
group by
t1.group_id,
t1.company_id,
t1.business_id,
t2.ware_inside_code
limit 3000,100;

  1. native 不显示的问题,参考此贴 tidb5.0 INFORMATION_SCHEMA,METRICS_SCHEMA,PERFORMANCE_SCHEMA三个库的表在navicat不显示
    2.jmeter 的问题看到您反馈也在排查下,你可以先试试 1 线程能不能跑起来,排除下是工具问题还是集群问题。 如果 1 个线程可以跑起来,麻烦反馈下 tiflash 日志。
  2. 请问是使用 tiup 安装部署的吗? 麻烦反馈下 tiup cluster display 结果
  3. 这个测试过程有 DM 吗? 数据流程是怎么样的? 4.0 和 5.0 是使用的相同资源,测试完 4.0,删除后再测试 5.0 吗? 4.0 和 5.0 的参数配置都一样吗?
  4. 能否反馈下这些sql的建表语句 和 执行计划, explain analyze 的结果,看下单个sql的执行计划是否也是 5.0 比较慢。

1.好的
2.测试jmeter 1个线程 1个连接可以


3.使用tiup部署的

4. 过程中没有dm了。我们的5.0 是4.0直接升级上来的,数据是一样的没有改动
5.执行时长 4.88 开启async-commit 和 cluster index后与4.0类似

tiflush-error日志:链接:https://pan.baidu.com/s/1P3Uyj2etP8BVZZ10pQeoWg
提取码:1111
tiflush日志:链接:https://pan.baidu.com/s/1pOkDAbES8782yAqbuQN7FA
提取码:1111

4.0和5.0执行计划不一样吗?explain analyze sql在4.0 和5.0都跑一下贴一下输出。

4.0的升级为5.0了,执行计划是一样的

用mysql客户端跑一下explain analyze, 我们可以看看是否可以进一步优化。


强制tikv

默认:


为什么网络、cpu那么高,磁盘没什么压力?使用tikv、tiflush都是这样

explain analyze, 不是explain
参照文档
https://docs.pingcap.com/tidb/stable/sql-statement-explain-analyze

刚才为了压测tidb,把tiflush清了了,现在重新加数据卡住了,好久了

注:原来时复制2 这次是复制1

现在复制完了,但是执行不了

麻烦检查下集群状态是否正常,以及 tikv/tiflash 相关组件的日志是否有报错。