rocH
#1
【 使用环境 】生产环境
【 OB or 其他组件 】OB、OMS、obProxy
【 使用版本 】OB: 4.3.4.1. OMS: 4.2.10 obProxy: 4.3.4.0-1
【问题描述】
业务背景：
生产环境需要在其他机房同步一个备库。并且这个备库需要开放给数据分析部门使用，需要在备库中写入数据分析表。由于备租户只能读无法写。
因此我们需要通过oms迁移一个全能租户。
机器配置介绍：
原集群： 1-1-1。 机器都是76核，1T内存的高性能机器
新集群： 单机集群。 56核，256G内存
obproxy：8核16G内存。 单独为了同步备库分别给原集群和新集群在各自内网中都各建了一个代理。
OMS： 64核128G内存；部署在原集群的内网中
原集群和新集群属于不同机房，但是有光纤直连。最大网速10Gbps。并且新旧集群机器和oms机器之间网速都使用iperf3 工具测试过。10Gbps可能不太稳定，但是8Gbps是稳的
全量迁移任务配置：
同步性能：
如图所示，同步性能及其不稳定。
根据调优文档 执行 ./connector_utils.sh diagnose命令。
显示
[Scene] JdbcWriteSlowScene
commit/batch=75517.00ms, execute/record=3.00ms, 建议查看该时间是否合理
日志中经常出现的异常：
com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 12000, active 814, maxActive 1089, creating 1, createElapseMillis 64
求助该如何调整oms服务
开那么多并发干啥？内存还挺小，有没有宽表？多分区表？大字段表？
淇铭
#5
./connector_utils.sh metrics 查看一下 看看瓶颈在哪里
1 个赞
rocH
#6
2025-09-26 18:00:25 INFO
2025-09-26 17:57:20.597
SOURCE: [RPS:3876.18, IOPS:nullM]
DATAFLOW: [slice:145.7ms, query:0.93ms, sliceQueue:143]
SINK: [RPS:39014.88, TPS:129.88, IOPS:40.324M]
SINK_TIME: [execute_time:6.54ms/record, commit_time:2852.77ms/batch]
SINK_THREAD: 1024/1024
DISPATCHER: wait record:null, ready batch:191, shardTime:nullms/record
queue_slot1 batchAccumulate: 512, recordAccumulate: null
heap:52632M/58982M, noHeap:61M/0M, threadCount:3041, cpu:37.414, sysCpu:44.565
ParNew(count:32, cost:18997) ConcurrentMarkSweep(count:947, cost:5586858)
连接并发开的太多了吧，正常同步很少开64以上，一般32个并发已经很高，连接数越多协调成本越高。建议是基于16、32个并发先观测瓶颈点是网络，还是源端、目标端负载（尤其CPU)，不一定是OMS的问题
rocH
#8
ConcurrentMarkSweep(count:947, cost:5586858)
看这个指标感觉是fullgc过于频繁
查找到对应 全量任务的java进程。
ps -ef| grep ds/run
查看gc状况
./jstat -gcutil 52565 3s
如上图，一直在fullgc
