--- title: "全量/增量数据迁移性能调优 | OceanBase 文档中心" description: 全量/增量数据迁移性能调优 名词解释 TPS 源端每秒拉取到的消息数量。 延时 当前任务的延时时长，单位为秒。延时计算不考虑安全位点。 ReadQ 在异步传输时，中间框架通过 ReadQ 获取数据并将数据写入目标端。当前进程未被中间框架获取的数据将被缓存在 ReadQ 中。ReadQ 的默认最大值是 4096。如果值… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*L03BS6f-o40AAAAAAAAAAAAADiGDAQ/original) 迁移服务 OMSV 4.2.5 社区版 # 全量/增量数据迁移性能调优 更新时间：2026-04-14 15:40:37 [编辑](https://github.com/oceanbase/oms-doc/edit/V4.2.5/zh-CN/1100.o-m-guide/400.component-tuning/100.tune-connector.md) ## 名词解释 - TPS 源端每秒拉取到的消息数量。 - 延时 当前任务的延时时长，单位为秒。延时计算不考虑安全位点。 - ReadQ 在异步传输时，中间框架通过 ReadQ 获取数据并将数据写入目标端。当前进程未被中间框架获取的数据将被缓存在 ReadQ 中。ReadQ 的默认最大值是 4096。如果值比较小，说明源端可能没有数据或者源端拉取存在瓶颈。 - WriteConsume 写入一次 `{batch.size}` 的时间，单位毫秒。`WriteConsume` 的数值越低，说明目标端性能越好。 ## 查询 Metrics 信息 执行 `./connector_utils.sh metrics` 命令，即可查询 Metrics 信息。 ```bash ./connector_utils.sh metrics 2022-09-22 12:49:48.876 SOURCE: [RPS:0.0, IOPS:0.0M, delay:1489ms] SINK: [RPS:0.0, TPS:0.0, IOPS:0.0M, delay:2986440ms] SINK_TIME: [execute_time:0.0ms/record, commit_time:0.0ms/batch] SINK_SLOW_ROUTES: SINK_THREAD: 4/4 DISPATCHER: wait record:0, ready batch:0, shardTime:nullms/record forward_slot0 batchAccumulate: 0, recordAccumulate: 0 queue_slot1 batchAccumulate: 0, recordAccumulate: 0 heap:620M/1945M, noHeap:52M/488M, threadCount:18, cpu:0.054, sysCpu:51.555 ParNew(count:0, cost:0) ConcurrentMarkSweep(count:0, cost:0) ``` 说明如下： 1. SOURCE RPS/IOPS/DELAY 2. SINK RPS/TPS(RecordBatch/s)/IOPS/DELAY 3. SINK_TIME: execute_time 表示每个 record 的执行时间，commit_time 表示 recordBatch 的执行时间。 4. SINK_SLOW_ROUTES：内部统计下，部分执行较慢的 SINK_ROUTES 信息，SINK_ROUTE 表示可并行写入单元。例如，kafka 的 partition、datahub 的 shard、rocketmq 的队列。 5. SINK_THREAD：当前活跃 sinkThread / 最大 sinkThread。如果 sinkThread 较少证明 sink 端较为空闲，未达到瓶颈。 6. DISPATCHER 中间队列情况，wait record: 表示等待被分配的消息数，ready batch 表示等待 sink thread 执行的 record batch 数量。 如果 wait record 数量较多，证明消息数量较大，可能受到 GC 影响。 如果 ready batch 较多，则证明 sink 端存在瓶颈，可以尝试提高 sink 写入速率（例如，增加线程）。 7. {框架队列名称} batchAccumulate: {积攒 recordBatch 数量}, recordAccumulate: {积攒 record 数量}。 1. 如果第一个队列 batchAccumulate 为空则证明当前瓶颈在 source 端无消息进入。 2. 如果最后一个队列 batchAccumulate 满则证明瓶颈在 RecordDispatcher(冲突矩阵/散列) 中，此时需要看 DISPATCHER 的 metrics。 8. 堆内存使用/堆内存最大，非堆内存使用/非堆内存最大，线程数，进程 cpu && sys cpu。 9. {时间} {youngGcName}(count:{累计次数}, cost:{累计耗时}) {fullGcName}(count:{累计次数}, cost:{累计耗时})。 ## 诊断 Incr-Sync/Full-Import 1. 查询 Incr-Sync/Full-Import 组件的组件 ID。 1. 登录 OMS 社区版控制台。 2. 在左侧导航栏，单击 **数据迁移**。 3. 在 **迁移任务列表** 页面，单击目标数据迁移任务的名称，进入详情页面。 4. 单击页面右上角的 **查看组件监控**。 5. 在 **查看组件监控** 对话框，查看 **Incr-Sync 增量同步组件** 或 **Full-Import 全量导入组件** 的 **组件 ID**。 2. 进入 Incr-Sync/Full-Import 组件目录。 1. 登录 OMS 社区版部署服务器。 2. 进入 Docker 容器。 ```shell docker exec -it ${CONTAINER_NAME} bash ``` 3. 执行进入组件目录的命令。 ```shell cd /home/ds/run/${组件 ID} ``` 3. 在 Incr-Sync/Full-Import 组件目录下执行 `./connector_utils.sh diagnose`，即可进行诊断。 ```bash ./connector_utils.sh diagnose -s 'YYYY-MM-DDTHH:mm:ss' -e 'YYYY-MM-DDTHH:mm:ss' ``` 上述命令中，`-s` 和 `-e` 均为可选参数，`-s` 表示开始分析日志的时间，`-e` 表示结束分析日志的时间。时间格式为 'YYYY-MM-DDTHH:mm:ss'，例如 '2023-06-01T12:00:00'。 `./connector_utils.sh diagnose` 的默认值为 10 分钟（`-e` 默认值为当前时间）。 返回结果示例如下： ```bash [Metrics] TPS: [last:345,avg:277.28,p99:911.00] RPS: [last:106,avg:257.08,p99:968.00] IOPS: [last:2KB,avg:21.33KB] EXECUTE_TIME: [last:34ms,avg:220.44ms,p99:783.00ms] SINK_DELAY: [last:19ms,avg:260.31ms,p99:819.00ms] SOURCE_DELAY: [ source_subtopic2_source_delay: [last:702ms,avg:525.00ms,p99:986.00ms] source_subtopic1_source_delay: [last:14ms,avg:490.69ms,p99:973.00ms] ] QUEUE_BATCH_ACCUMULATE: [ frame_queue_slot_1.batchAccumulate: [last:420,avg:496.00,p99:975.00] frame_queue_slot_2.batchAccumulate: [last:310,avg:470.05,p99:975.00] ] JVM-MEM: heap:34.28M/3641M, noHeap:19.38M/0M] THREAD: [count:4, sink:14/16] CPU: [last:17,avg:27.95,p99:62.00] [Pref] sink block: true youngGc: true [Suggest] config[coordinator.shuffleMinBatchSize]:20 to 40 config[coordinator.shuffleMaxBatchSize]:40 to 80 jvm to: -Xmx4096m ``` 说明如下： - Metrics 信息为判断依据。 - Pref 信息为根据 Metrics 判断分析的瓶颈点。 - Suggest 信息是推进优化的点。例如上述示例中可以更新 Incr-Sync/Full-Import 组件 `coordinator` 中的 `shuffleMinBatchSize`、`shuffleMaxBatchSize` 和 `connectorJvmParam` 参数。 ## workerNum - `workerNum` 已达到上限，`metrics` 日志中 `sink` 的 `executeTime` 和 `commitTime` 的时间可以接受。 1. 从任务详情页面进入 **查看组件监控** 对话框。 2. 单击目标组件后的 **更新**。 3. 在 **更新配置** 对话框，鼠标悬停至 `sink` > `workerNum` 参数，单击编辑图标。 如果没有该参数，请将鼠标悬停至 `sink` 参数旁边的空白处，单击添加图标。 #### 说明 如果您使用旁路导入方式写入数据库，可以通过修改 `serverParallel` 参数来调整旁路导入 Server 端的并发数，默认值为 8。 4. 根据机器资源，调大 `workerNum` 的值。 5. 在文本框中输入修改后的参数后，单击确认图标。 6. 在 **更新配置** 对话框，单击 **确定**。 - `workerNum` 未达到上限，`metrics` 日志中每两次之间的 GC 时间很长。 1. 从任务详情页面进入 **查看组件监控** 对话框。 2. 单击目标组件后的 **更新**。 3. 在 **更新配置** 对话框，鼠标悬停至 `source` > `splitThreshold` 参数，单击编辑图标。 如果没有该参数，请将鼠标悬停至 `source` 参数旁边的空白处，单击添加图标。 4. `splitThreshold` 参数的默认值为 128，调小该参数的值。 5. 在文本框中输入修改后的参数后，单击确认图标。 6. 在 **更新配置** 对话框，单击 **确定**。 - `workerNum` 只有 `1` 或 `2`，`connector.log` 打印 `conflictKey` 或者 `deepSize` 关键字。 1. 从任务详情页面进入 **查看组件监控** 对话框。 2. 单击目标组件后的 **更新**。 3. 在 **更新配置** 对话框，鼠标悬停至 `coordinator` 参数旁边的空白处，单击添加图标。 4. 输入需要添加的 Key Name 为 `hotKeyMerge`，单击对号。 5. 在 **更新配置** 对话框中，找到新增的 Key Name，其默认值为 NULL。 6. 鼠标悬停至新增参数，单击显示的编辑图标，修改参数值为 `true`，单击确认图标。 7. 在 **更新配置** 对话框，单击 **确定**。 ## GC 时间过长 #### 说明 此处 GC 时间过长，指每秒 Young GC 超过 300ms，每秒都存在 Full GC。 ### 查看 GC 在 `task` 目录下执行以下命令，查看每秒的 GC 的详情： ```bash /opt/alibaba/java/bin/jstat -gcutil `cat task.pid` 1s ``` - 增大 JVM 内存：调整 `coordinator` > `connectorJvmParam` 为 `-Xms12g -Xmx16g`。 此处仅为示例，您需要参考当前机器的内存调整。如果之前参数存在，您可以去掉 `-Xmn`。 - 同步 && 全量：减小 `coordinator` > `bridgeQueueSize` 的值。默认值为 `256`，可以减小到 `32`。 - 同步 Kafka：设置 `sink` > `lingerMs` 参数的值为 1。 - 设置 `coordinator` > `throttleMemoryBound` 参数的值为 bytes 字节数来限制内存。建议将该参数设置为最大内存的 1/4。 例如，最大堆内存是 16G，则该值为 `16 * 1024 * 1024 * 1/4 = 4294967296`。 - 如果 `conf/coordinator.json` 或者 `conf_new/coordinator.json` 中 `dispatcherClassName` 配置项是 `ShuffleRecordDispatcher`，则可以更改 `coordinator` 的如下配置项： - `maxRecordCapacity = 1000` 控制 `dispatcher` 队列总数。默认是根据 `shuffleMinBatchSize *(shuffleBucketSize* 1.5) = 3840`。 - 设置 `shuffleBucketSize` 参数的值为 32。减少攒批桶数量，默认为 `128`。 - 设置 `shuffleFlushIntervalMs` 参数的值为 10，加速推送到 Sink 端。 - 增加 `sink` > `workerNum` 参数，默认值为 `16`，最大可以调整到 `64`。 ## 攒批相关参数 #### 注意 攒批相关参数仅适用于非数据库目标端的增量同步链路。 参考 GC 情况： 1. 在 GC 不严重时，在目的端能承受的范围能增加攒批能力。 2. 在 GC 严重时，减少攒批。 - `maxRecordCapacity`：攒批队列最大数量，默认 `16000`。 - `shuffleMinBatchSize`：攒批最小批次，默认 `20`。 - `shuffleMaxBatchSize`：攒批最大批次，默认 `64`。 - `shuffleFlushIntervalMs`：刷新时间，默认 `100ms`。 - `shuffleBucketMaxInFlightBatchSize`：每个并发允许最多正在投递数量，增量默认 `1`，全量不限制。 - `shuffleBucketSize`：允许最大攒批并发。 在 shuffleMaxBatchSize || shuffleFlushIntervalMs 达成的条件下即会投递（写入线程还具备写入能力）。 ## 延迟所需的信息说明 - 当前任务延迟的截图，包括任务延迟、Store 延迟和 Incr-Sync 延迟。 ![latency-zh](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/oms/oms-enterprise/latency-zh.png) 如上图所示，在一个数据迁移或数据同步任务中，存在多种延迟概念。 | 序号 | 延迟类型 | 描述 | | --- | --- | --- | | 1 | 任务延迟 | - 数据迁移或数据同步任务的延迟时间以 Incr-Sync 延迟时间为准。如果存在多个 Incr-Sync，以最长的 Incr-Sync 延迟时间为准。 - 数据迁移或数据同步任务的延迟时间计算和组件的延迟时间计算本身属于不同的调度存储，可能存在差异。例如，任务数量过多、调度时间过长等可能导致任务延迟时间大于组件延迟时间，但仅是展示延迟时间的差别。 | | 2 | Store 延迟 | “当前时间 - Store 抓取变更记录的时间”得到的时间差即 Store 组件的延迟时间。该时间计算存在轮询，通常为 10~30 秒。 | | 3 | Incr-Sync 延迟 | “当前时间 - 当前写入至目标端记录的最小变更时间”得到的时间差即 Incr-Sync 组件的延迟时间。该时间计算存在轮询，轮询时间请参考括号内多少秒前更新的时间。 | - Incr-Sync 组件的 Metrics 日志记录，详情请参见本文《查询 Metrics 信息》模块的内容。 - 建议您将 Incr-Sync 组件的 `logs` 和 `conf` 目录打包提供。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线