集群信息：
OceanBase 版本号：4.3.5.0
Region 数量：1；机器数量：3；CPU 架构：x86_64
通过obd白屏部署，OLAP类型
obd version: 3.1.2
集群详情OCP截图：
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秒以内
硬盘换SSD
尝试过，当时是arm的，内存也大，性能还不如这个
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’;
三台一样
$ 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
你发的参数好像就是参考链接里的
有些可能不一样 你按照上面的参数调整 调整完以后 用ssd硬盘 重新压测一次
emm
1.这些参数并没有太大不同，不太可能有很大的提升
2.关于磁盘类型，跑tpch都有预热的，预热后从内存读取数据吧，跟磁盘类型关系不大
哈哈，遇到问题，先看巡检，标准操作
我看了下巡检报告，发现了一个问题： data_dir and log_dir_disk are on the same disk. 数据盘和日志盘同盘了，这个会影响性能，建议分盘；
嗯嗯，这个建议我看到很多次了，也实践过，并不是瓶颈所在，主要是这套机器就这一个盘，不想弄了
好好学习，天天向上 
可以发一下租户规格看看，另外每条sql具体的耗时也可以发下。可能是某条sql读盘了，可以单独跑一下耗时比较长的sql，看看io情况
租户名 tenant_tpch
OceanBase 版本号 4.3.5.0
租户模式 MySQL
字符集 utf8mb4
Collation utf8mb4_bin
部署分布 FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3
UNIT规格
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
Q13咋回事
用敏捷诊断工具obdiag 拿一下Q13的obdiag plan_monitor报告我们看看咋回事
https://www.oceanbase.com/docs/common-obdiag-cn-1000000002488264
学到了！
emm，看了一眼，不会用啊，怎么单独看Q13的，链接里好像看整个集群
关注一下
obdiag 那个收集plan_monitor的是针对一次执行的，不是针对整个集群。现在你的疑惑点不是Q13这个case不符合预期吗，你可以单独拉出来Q13里面的SQL语句去收集一下plan_monitor。这个报告的好处是里面详细的展示了执行计划、算子信息、执行情况、表结构等等信息，一般分析SQL问题这份报告就足够了，可以减少很多不必要的论坛交互时间。
