rocH
#1
【 使用环境 】生产环境
【 OB or 其他组件 】ob和oms
【 使用版本 】源端4.2.1. oms 4.2.9 目标端4.3.4.1
【问题描述】
OMS机器配置： 64核CPU128G内存4T硬盘。 硬盘为固态PCIE4.0接口，写入性能应该没压力。
网络带宽总量500Mb
从源端4.2.1增量同步到新集群4.3.4.1. 通过外网传输数据
根据源端机器的iftop命令显示，源端从oss服务拉取日志的流量是1Gbps。 (oss和源端为同一内网)
然而发送到目标端的流量才200Mbps。
同步表对象占整个库的99%的数据量。
如图为oms的增量监控图。迁移流量约50MB。 因store拉取日志速度跟不上，导致延迟逐渐拉大
有没有什么办法增加store组件拉取日志的速度
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
2 个赞
咖啡哥
#3
OMS跟源端OB在一起局域网吗？
如果不在，大概率是网络带宽限制了。
OMS要贴源，否则容易出现网络带宽问题。我们实测源端OB日志量200M/s都没问题
排除网络问题，store延迟可以从几个方面优化：
OMS参数：store.topic.mode.config
单条链路会独占store，如果按表拆分链路后，可避免store瓶颈，修改OMS系统参数store.topic.mode.config为模式UN_SHARE
store组件：参数
store新增参数liboblog.working_mode=memory
该模式下，会避免logproxy落盘进而避免磁盘I0瓶颈
liboblog.working_mode:memory
适当增加并发和内存：
ob2store.serialize_pool_size:16
liboblog.memory_limit=32G
3 个赞
rocH
#4
oms和源端ob不在一起。
和目标端ob在一起。
如果将oms迁移到 源端网络。
Incr-Sync组件是否会产生延迟？
1 个赞
咖啡哥
#5
OMS要贴近源端，主要流量在抽日志的环节，要把日志都抽到OMS服务器解析。Incr-Sync增量组件没那么多量了
3 个赞
