本文介绍如何优化 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.374FGC 不断增加则表示需要增加 JVM 内存。
