【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1
【问题描述】OB社区版4.2.1 1T数据量10G以下数据增量 每日合并时间20小时左右 如何优化
【复现路径】近3个月没有任何操作，都师20小时左右
ob4.2.1.log (70.8 KB)
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
1 个赞
你的数据盘是SSD么？
另外先查一下GV$OB_COMPACTION_PROGRESS，看下上次和这次合并的一个情况
刚才没看到文件。看起来集群性能有点差，你搜下select * from GV$OB_TABLET_COMPACTION_HISTORY where tenant_id = 1002 and compaction_scn = 1709211602665446060 order by time_to_usec(finish_time)-time_to_usec(start_time) desc limit 10
还有就是租户规格是什么样的，表数量大概有多少，增量数据是随机写居多么。
分区数是百万级别，合并是需要10小时+量级的
obclient [oceanbase]> SELECT count()/3 FROM oceanbase.DBA_OB_TABLE_LOCATIONS where DATABASE_NAME in (‘cst’,‘hds’,‘jcw’,‘ljdmws’,‘org’,‘pub’,‘smy’) ;
±-------------+
| count()/3 |
±-------------+
| 1177847.0000 |
±-------------+
1 row in set (4.210 sec)
这个查询代表分区总数吗？如果要降低合并时间，只能降低分区数吗？
推荐用obdiag 工具的根因分析功能分析一下合并卡的问题。
命令：obdiag rca run --scene=major_hold
根因分析的使用文档：OceanBase分布式数据库-海量数据 笔笔算数
租户资源很足。
是的，是分区数，也可能有其他方法，你先再查下 GV$OB_COMPACTION_SUGGESTIONS以及__all_virtual_dag_scheduler看一下
1 个赞
你目前可以通过加大compaction_low_thread_score的值，来增加合并任务的可用线程数。当前是默认值，为6，即6个可用线程。我建议你可以提高到12或者更高，具体多少，这取决于你的业务资源是否足够，因为提高了合并线程数，合并过程中会占用更多资源，可能会挤占到业务资源。
从之前的历史记录来看，单次分区合并任务增量数据不多，并行度不高，提高合并线程数可以让更多分区合并间并行。
另外方便的话麻烦再通过select * from GV$OB_TABLET_COMPACTION_HISTORY where tenant_id = 1002 and compaction_scn = xx order by time_to_usec(finish_time)-time_to_usec(start_time) desc limit 2，找到最耗时的几条合并记录，然后通过TASK_ID，到对应server上收集一下这几次合并的日志。即 grep TASK_ID observer.log.xxx（根据记录的start_time/finish_time找附近时间点能覆盖该合并记录的日志）。我看下单次合并的执行情况
1 个赞
你的数据盘是单独给OB集群用吗，有其他压力吗。
另外，可以提高compaction_low_thread_score后看看新一轮合并有没有性能提升
改成12后合并速度没有任何提升
由于分区数超百万，如果只调大score没有提升的话，建议尝试将以下两个配置项调大
其中compaction_dag_cnt_limit默认值为15000，compaction_schedule_tablet_batch_cnt默认值为50000.
alter system set compaction_schedule_tablet_batch_cnt = 100000;
alter system set compaction_dag_cnt_limit = 50000;
另外就是观察一下数据盘的io情况，是否压力比较大