OB4.0 TPCH 性能测试,低于预期

【 使用环境 】Linux 5.18.19 & centos 8
【 OB or 其他组件 】
【 使用版本 】oceanbase 4.0.0.0
【问题描述】本地创建一个OB实例,TPCH 100G数据,想对比LZ4和ZSTD的性能差距,结果性能都特别差,远不如OB 3.1.14表现出的结果,我怀疑是参数配置引起的,但又不确定具体原因。
【参数配置】
create resource unit tpch_unit max_cpu 112, memory_size ‘70g’;
create resource pool tpch_pool unit = ‘tpch_unit’, unit_num = 1, zone_list=(‘zone1’);
create tenant tpch_mysql resource_pool_list=(‘tpch_pool’), zone_list(‘zone1’), primary_zone=RANDOM, locality=‘F@zone1’ set variables ob_compatibility_mode=‘mysql’, ob_tcp_invited_nodes=’%’;

alter system set enable_sql_audit=False;
alter system set enable_sql_extension=True tenant=tpch_mysql;
alter system set syslog_level=‘PERF’;
alter system set max_syslog_file_count=100;
alter system set trace_log_slow_query_watermark=‘100s’;
alter system set _hash_area_size=‘3g’ tenant=tpch_mysql;
alter system set enable_rebalance=False;
alter system set memory_chunk_cache_size=0;
alter system set cache_wash_threshold=‘30g’;
alter system set ob_enable_batched_multi_statement=True tenant=tpch_mysql;
alter system set _bloom_filter_ratio=10;
alter system set _rowsets_enabled=True tenant=tpch_mysql;
alter system set _parallel_server_sleep_time=10;
alter system set cpu_quota_concurrency=4;
alter system set syslog_io_bandwidth_limit=‘30m’;
alter system set enable_async_syslog=True;
alter system set large_query_worker_percentage=10;
alter system set builtin_db_data_verify_cycle=0;
alter system set micro_block_merge_verify_level=0;
alter system set freeze_trigger_percentage=50;
alter system set enable_perf_event=False;
alter system set large_query_threshold=‘1s’;
alter system flush plan cache global;

set global ob_sql_work_area_percentage = 80;
set global optimizer_use_sql_plan_baselines = True;
set global optimizer_capture_sql_plan_baselines = True;
set global ob_query_timeout = 36000000000;
set global ob_trx_timeout = 36000000000;
set global max_allowed_packet = 67108864;
set global parallel_servers_target = 896;
set global _groupby_nopushdown_cut_ratio = 1;
set global secure_file_priv = ‘’;

【问题现象】
TPCH SQL1 测试结果

[2022-11-22 08:49:36] BEGIN 1
[2022-11-22 08:52:42] END,COST 185.80s
[2022-11-22 08:52:42] BEGIN 1
[2022-11-22 08:55:43] END,COST 180.43s
[2022-11-22 08:55:43] BEGIN 1
[2022-11-22 08:58:40] END,COST 177.83s

【附件】
perf top

iostat

执行sql有加并发查询的hint吗?另外有执行合并和手动收集统计信息吗?建议按照文档排查下操作步骤上的差异 :https://www.oceanbase.com/docs/community-observer-cn-10000000000901377

测试步骤按照文档进行,sql语句有增加并发查询,也手动合并过,但现象还是一样。执行tpch sql1的查询语句过程中,通过iostat命令,我发现磁盘有大量写操作,perf top也显示进程写加锁占比比较高,这是为什么呢?
perf to

iostat

有大量io这个肯定不太对的,单台70G内存有点太小了,可以尝试缩小数据量,或者增加租户内存

好的,谢谢,我再试试