sysbench 压测ob时, write only 场景 qps 波动大

好的 我测试下

测试结果跟之前类似,


我抓了一段性能下降时间断的日志 能帮忙看看么
有一些errcode 和 大量的REACH SYSLOG RATE LIMIT , 不确定影响程度

可以,你发出来看下

MEDIUM_MERGE是什么意思?官方网站没有解释

日志通过什么方式上传啊, 我看这里附件只能200k
image

钉钉群里这么回复我的: medium merge是分区级合成major sstable的过程, medium merge更类似major merge (相当于分区级的大合并)

2 个赞

已对接处理

1 个赞

有结果了么

建议看一下是否有调整major_compact_trigger的默认值(这个值默认不大,所以会频繁导致合并发生而非转储,可以调整一下确保不触发合并,仅触发转储,合并任务仅留在夜间低峰时间段执行),我们之前压测过程中遇到过,将major_compact_trigger设置为65535然后将major_freeze_duty_time设置为每日低峰时间点即可。我当时的调整是:

(1)root@sys执行:
ALTER SYSTEM SET major_freeze_duty_time=‘02:00’ TENANT=tenant1;
(2)root@tenant1(业务租户)执行:
ALTER SYSTEM SET major_compact_trigger=65535;

可以试试效果

major_compact_trigger 设置为0 是不是就表示关闭小合并,MINI_MERGE这个是小合并?我发现我这边major_compact_trigger 为0 依然有MINI_MERGE


这个我们当时理解的是默认值0导致频繁触发大合并,所以性能抖动较剧烈,后来调整了这个值以后再压测,那种剧烈的抖动不再明显了(sysbench oltp read write测试时响应耗时直接飙升到上千ms级别的),您可以试试,另外看看其他人是否有类似的情况和更有效的处理方式

另外在我们压测过程中,mini merge这种类型的compaction出现的时候,并没有性能问题,出现性能问题时对应的compaction类型是mini_minor_merge这种类型(这个是我们调整了major_compact_trigger值为65535以及将合并时间点调整后,压测再遇到偶尔的性能抖动(比正常的响应耗时高一些但是没有达到上千ms)时看到的)

这个参数文档描述不是很好理解 , 我看源码这其实是控制两次合并, 中间有多少次冻结(minor freeze) .
在每次触发冻结的时候, 会根据 freeze cnt 和 这个参数对比, 来判断是否需要做大合并
等于0相当于关闭这种触发大合并的通道.

image

我测试过程有调整过这个参数, 不过还是会有问题, 整个过程并没有触发大合并, 就算小合并对性能有一定影响 也不应该qps降为0 .
这段时间没追这个问题 忙其他事去了 :joy:

这个问题我们内部还在定位,有结果了会公布出来