OMS 性能优化-OceanBase数据库使用指南

本文介绍如何优化 OMS 的性能。本文提供的方案可以解决大部分性能问题。

通用方案

优化方案	描述
并发	源端并发：`source.workerNum` 目标端并发：`sink.workerNum` 全量迁移建议源端与目标端并发相同，增量迁移源端无需设置并发。并发度一般和机器 CPU 核数相关，最大可以设置成 CPU*4。设置并发时，请考虑机器上是否运行其他任务。
JVM 内存	`coordinator.connectorJvmParam` 主要调整以下三个参数： - `-Xms8g`: 初始内存 - `-Xmx8g`: 最大内存 - `-Xmn4g`: 新增代内存规则：初始内存 = 最大内存新增代内存 = 最大内存 - 4G + 通常每个并发对应 1G 内存，例如 32 并发时，最大内存设置为 32G。
每个分片记录数	`source.sliceBatchSize` 默认值为 600 对于大表，通常设置为 10000 就能满足需求，过大可能会占用大量内存。参考 `logs/msg/metrics.log` 中的 `slice_queue` 值决定是否修改分片数。如果为 0 则需要增加每个分片的记录数（`source worker` 线程会从 `slice_queue` 中拉取分片，0 表示没有分片，`source worker` 会等待空转）。
索引后置	在进行全量迁移后，为了提高迁移效率，通常需要在迁移完成后创建索引。对于目标库是OceanBase的情况，可以通过设置系统参数`struct.transfer.config.ob.parallel`来配置创建索引时的并发度。

增量迁移

当源端有批量操作导致增量延迟时可以调整事务分片，参数为 source.splitThreshold，默认值为 128。

对于批量 INSERT 操作，建议将该值调大，最大为 512。
对于批量 UPDATE 和 DELETE 操作，建议将该值调小，最小为 1。

排查迁移任务性能瓶颈

按照 slice 分片 -> source 读取源端 -> dispatcher 数据分发 -> sink 写入目标端的顺序排查迁移任务性能瓶颈。

分片队列检测

slice_queue > 0 瓶颈不在这里，slice_queue=0 分片慢，增加 source.sliceBatchSize 每个分片的记录数，多表场景也可以增加 source.sliceWorkerNum 分片工作线程。
源读取瓶颈检测

source_worker_num 小于 source_worker_num_all 表示瓶颈不在源读取。
写入瓶颈检测

sink_worker_num 小于 sink_worker_num_all 表示瓶颈不在写入。
写入性能检测
- dispatcher.ready_execute_batch_size=0 表示写入没有瓶颈。
- ready_execute_batch_size>0 表示写入慢。
分发性能检测
- dispatcher.wait_dispatch_record_size=0 表示分发没有瓶颈。
- wait_dispatch_record_size>0 表示 OMS 内部计算数据归属分区存在瓶颈（分区表情况下一般都会有积压，分区计算比较耗时），旁路场景下可以关闭分区计算 sink.enablePartitionBucket=false。也可能存在热点数据，详细查看下面的疑似热点这块。todo
JVM 内存检测

在 JVM 内存不足时，可能会触发 Full GC（全垃圾收集）。这也会导致迁移效率降低，并可能引发数据库连接断链等容易被误判的异常。登录 OMS 容器，查看进程 GC 情况。

用户操作建议

如果源端在做批量操作，建议控制流程。

su - ds
ps -ef|grep "组件 ID"

/opt/alibaba/java/bin/jstat -gcutil {pid} 1s
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
0.00  18.27  64.08   0.90  97.11  93.45      7    0.374     0    0.000    0.374
0.00  18.27  64.08   0.90  97.11  93.45      7    0.374     0    0.000    0.374

FGC 不断增加则表示需要增加 JVM 内存。