【 使用环境 】 测试环境
【 OB or 其他组件 】
【 使用版本 】4.3
【问题描述】
最近在做OB的压测，4U32G环境下做OB的INSERT 业务，然后设置10次转储触发合并。过程中发现TPS会受合并任务的影响出现下降，但是严格来看TPS的下降时间点要比通过
SELECT * FROM oceanbase.GV$OB_TABLET_COMPACTION_HISTORY WHERE TYPE =‘MAJOR_MERGE’ AND tenant_id = 1004;
这个SQL查出来的时间点要延迟30s。这个是什么原因？
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
针对您描述的情况，建议使用 obdiag 工具来收集相关的诊断信息，以便我们能够更准确地定位问题。
日志采集场景: 卡合并场景
日志采集命令: obdiag gather scene run --scene=observer.major_hold
请使用上述命令收集日志，并将收集到的日志压缩包提供给我们。这将有助于我们进一步分析 TPS 下降的具体原因。
为了更好地帮助您解决问题，请您提供以下信息：
希望以上信息能帮助我们更快地找到问题的原因。谢谢您的配合！
附上敏捷诊断工具 obdiag 使用帮助链接
根据您提供的信息，合并任务对TPS产生影响的原因可能是因为合并操作本身是资源密集型的任务，这会对同一时间段内的其他操作（例如INSERT业务）产生影响。您提到的TPS下降时间点与通过SQL查询获取的合并任务开始时间点之间有30秒的延迟，这可能是由于系统在启动合并任务后，还需要一些时间来准备资源，包括但不限于内存分配、I/O预热等。此外，合并任务的实际执行可能会受到其他后台任务的影响，例如日志同步、数据校验等，这些任务也可能导致合并任务的实际开始时间晚于预期。
为了更准确地分析这个问题，建议您检查这段时间内的系统日志，特别是关于资源使用情况（如CPU、内存、I/O）的日志，以确定是否有其他任务在消耗资源，导致合并任务延迟。同时，您也可以尝试调整合并任务的调度策略，例如设置更宽松的触发条件，或者在业务低峰期执行合并任务，以减少对业务的影响。
检索到的文档如下:
学习学习
你是设置这个参数 冻结多少次以后合并 如果是你看看文档的解释
