MEDIUM_MERGE类型合并影响TPS

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.1
【问题描述】
ob部署为单zone,两个observer,租户资源是,2C/4G , 2 unit,
用sysbench压测, 16线程 ,10张1000000的表,只做INSERT, 压测10分钟,出现MEDIUM_MERGE合并类型的时间附近,TPS下降较大,MEDIUM_MERGE类型的合并有减少影响的方案吗


1 个赞

4.x的medium merge就类似于3.x的queuing表,是由自适应合并处罚的。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000488719
你可以设置_enable_adaptive_compaction关闭自适应合并,或者对某些表设置 table_mode(4.2.1.5之后)

1 个赞

sysbench 压测的时候用obdiag巡检一下看看集群有没有啥问题。
https://open.oceanbase.com/blog/8457406112

1 个赞

没出现MEDIUM_MERGE类型合并,TPS比较平稳

1 个赞

测试下来就是MEDIUM_MERGE类型出现的时间,TPS下降比较大

1 个赞

MEDIUM_MERGE导致性能降低,但一般情况下只有10%的影响,你的环境会降到0吗?另外,可以看下在压测过程中,磁盘io_wait和cpu负载情况,io_wait比较高或者cpu负载较高的情况下,转储时对压测性能会影响更大,你的磁盘是SSD盘吗,日志和数据盘有没有分开

1 个赞

降到0,那没有,降了有3分之一左右,磁盘类型是SSD,但不是本地盘,相当于云盘

1 个赞

image
你可以根据这个或者官网上 优化一下参数 在进行压测
到时候压测的过程中 你也可以看 是不是有转储的问题
SELECT SVR_IP,SVR_PORT,TYPE,COMPACTION_SCN,START_TIME,FINISH_TIME FROM oceanbase.GV$OB_TABLET_COMPACTION_HISTORY where start_time > ‘时间点’ order by START_TIME desc;
先可以根据这个sql判断下,当qps陡降的时候,是不是触发了MINI_MINOR_MERGE等操作。
然后看下show parameters like “%memstore_limit_percentage%”; 这个参数大小

1 个赞

还有就是clog盘和数据盘 要分开

1 个赞

好的,感谢,触发MINOR_MERGE和MINI_MERGE操作的时候,TPS影响波动不是很大,还算平稳,触发MEDIUM_MERGE操作的时候,波动较大

1 个赞

你先做一下参数优化 后面在压测一下 看看是不是还有qps和tps波动很大情况 后面你在贴出来 我们在沟通看看

1 个赞

那我先看看

1 个赞

你优化参数了么 有没有重新压测

1 个赞

暂时忙其它事去了,上面发的优化参数是3.X的吧,4.X的文档sysbench没看到要改这些参数, 还有看了ob_sql_audit视图,发现有些语句比正常的语句耗时要高几倍。

1 个赞

调优有的 你看看 文档
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050385
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050851
可以尝试修改一下 压测看看 如果语句感觉消耗高 你可以看看show trace 看看消耗在哪里 再看看执行计划 执行计划是不是最优的

只是压测的写入场景,只是INSERT语句,oltp_insert.lua

好的 你先看看文档 看看可以优化不 到时候再压测一下 测测