x86三节点100G-TPCH性能不符合预期

集群信息:
OceanBase 版本号:4.3.5.0
Region 数量:1;机器数量:3;CPU 架构:x86_64
通过obd白屏部署,OLAP类型
obd version: 3.1.2

集群详情OCP截图:


image
TPCH数据规模:100G
机器磁盘类型:机械硬盘

TPCH压测参考:
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002012906
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001428761
TPCH压测方式:obclient直连主节点

TPCH执行过程中,三个节点的 top -H 截图

100G-TPCH成绩:17秒,官方公布成绩:6.7秒
预期时间:10秒以内

4 个赞

硬盘换SSD

3 个赞

尝试过,当时是arm的,内存也大,性能还不如这个

3 个赞

lscpu信息 查看一下
参数调优
SET GLOBAL ob_sql_work_area_percentage = 80;

SET GLOBAL ob_query_timeout = 36000000000000;

SET GLOBAL ob_trx_timeout = 36000000000000;

SET GLOBAL max_allowed_packet = 67108864;

– parallel_servers_target = max_cpu * server_num * 8

SET GLOBAL parallel_servers_target = 624;

alter system set default_table_store_format = ‘column’ ;
schema下调整
SET global NLS_DATE_FORMAT=‘YYYY-MM-DD HH24:MI:SS’;
SET global NLS_TIMESTAMP_FORMAT=‘YYYY-MM-DD HH24:MI:SS.FF’;
SET global NLS_TIMESTAMP_TZ_FORMAT=‘YYYY-MM-DD HH24:MI:SS.FF TZR TZD’;

set global ob_query_timeout=10800000000;
set global ob_trx_timeout=10000000000;

set global ob_sql_work_area_percentage=80;

alter system set ob_enable_batched_multi_statement=‘true’;
alter system set default_table_store_format = ‘column’ ;
alter system set _io_read_batch_size = ‘128k’;
alter system set _io_read_redundant_limit_percentage = 50;

– parallel_servers_target = max_cpu * server_num * 8
set global parallel_servers_target=10000;

set global collation_connection = utf8mb4_bin;
set global collation_database = utf8mb4_bin;
set global collation_server = utf8mb4_bin;

set global autocommit=1;
set global optimizer_use_sql_plan_baselines = true;
set global optimizer_capture_sql_plan_baselines = true;

alter system set ob_enable_batched_multi_statement=‘true’;

3 个赞

三台一样
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
Stepping: 2
CPU MHz: 2300.000
CPU max MHz: 2300.0000
CPU min MHz: 1200.0000
BogoMIPS: 4588.92
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 40960K
NUMA node0 CPU(s): 0-15,32-47
NUMA node1 CPU(s): 16-31,48-63

你发的参数好像就是参考链接里的

3 个赞

有些可能不一样 你按照上面的参数调整 调整完以后 用ssd硬盘 重新压测一次

3 个赞

emm
1.这些参数并没有太大不同,不太可能有很大的提升
2.关于磁盘类型,跑tpch都有预热的,预热后从内存读取数据吧,跟磁盘类型关系不大

3 个赞

拿诊断工具obdiag巡检一下看看配置设置的是否合理,文档:https://www.oceanbase.com/docs/common-obdiag-cn-1000000002200479

3 个赞

不得不说,老哥你可太爱巡检了,上回也是让巡检
巡检.rar (2.6 KB)

3 个赞

哈哈,遇到问题,先看巡检,标准操作

我看了下巡检报告,发现了一个问题: data_dir and log_dir_disk are on the same disk. 数据盘和日志盘同盘了,这个会影响性能,建议分盘;

2 个赞

嗯嗯,这个建议我看到很多次了,也实践过,并不是瓶颈所在,主要是这套机器就这一个盘,不想弄了

3 个赞

好好学习,天天向上 :+1: :+1: :+1:

3 个赞

可以发一下租户规格看看,另外每条sql具体的耗时也可以发下。可能是某条sql读盘了,可以单独跑一下耗时比较长的sql,看看io情况

2 个赞

租户名 tenant_tpch
OceanBase 版本号 4.3.5.0
租户模式 MySQL
字符集 utf8mb4
Collation utf8mb4_bin
部署分布 FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3

UNIT规格

  • CPU(核):56
  • 内存(GiB):150
  • 日志盘(GiB):300
  • IOPS:12800000

Zone 优先级 RANDOM

官方 – 自测
Q1 0.58 – 0.83
Q2 0.18 – 0.26
Q3 0.36 – 0.58
Q4 0.17 – 0.33
Q5 0.31 – 1.03
Q6 0.02 – 0.04
Q7 0.35 – 0.94
Q8 0.27 – 0.75
Q9 1.00 – 1.63
Q10 0.26 – 0.56
Q11 0.07 – 0.34
Q12 0.09 – 0.16
Q13 0.45 – 2.19
Q14 0.08 – 0.35
Q15 0.19 – 0.89
Q16 0.23 – 1.16
Q17 0.12 – 0.35
Q18 0.61 – 1.06
Q19 0.14 – 0.30
Q20 0.12 – 1.26
Q21 0.65 – 1.25
Q22 0.14 – 0.79
sum 6.39 – 17.05

2 个赞

Q13咋回事

1 个赞

用敏捷诊断工具obdiag 拿一下Q13的obdiag plan_monitor报告我们看看咋回事
https://www.oceanbase.com/docs/common-obdiag-cn-1000000002488264

1 个赞

学到了!

emm,看了一眼,不会用啊,怎么单独看Q13的,链接里好像看整个集群

关注一下

obdiag 那个收集plan_monitor的是针对一次执行的,不是针对整个集群。现在你的疑惑点不是Q13这个case不符合预期吗,你可以单独拉出来Q13里面的SQL语句去收集一下plan_monitor。这个报告的好处是里面详细的展示了执行计划、算子信息、执行情况、表结构等等信息,一般分析SQL问题这份报告就足够了,可以减少很多不必要的论坛交互时间。