使用oms同步数据时发现同步速度很一般，想咨询下这个速率主要由什么决定，带宽均为满，目前8核16g同步机器 是哦继续提升配置吗
带宽看来已经被充分利用， 硬件配置、OMS配置、源端和目标端数据库性能以及CDC都有可能影响同步速率
跟环境有很大关系
6666
根据文档库中的信息，OMS 数据同步的速度受多种因素影响，包括但不限于硬件配置、网络带宽、日志生成速度、源端和目标端的性能等。对于您提到的情况，8 核 16 GB 的同步机器在带宽均为满的情况下同步速度不理想，是否继续提升配置需要综合考虑以下几点：
-
硬件资源评估：
- 您当前使用的 8 核 16 GB 配置可能在某些高负载场景下成为瓶颈。可以检查 CPU 和内存使用情况，如果接近饱和，则提升配置可能会带来性能改善。
- 参考文档中关于优化日志同步性能的注意事项（《OceanBase 迁移服务》文档 优化日志同步性能 → 注意事项），调整
log_archive_concurrency和log_restore_concurrency参数虽然能增加并发度，但也可能导致更多的 CPU 和内存消耗，因此需谨慎操作。
-
网络带宽优化：
- 文档中提到可以通过设置
standby_fetch_log_bandwidth_limit和_server_standby_fetch_log_bandwidth_limit来控制备库与主库之间的带宽使用（《OceanBase 迁移服务》文档 设置日志同步限速）。确保这两个参数配置合理，避免不必要的带宽浪费或过度限制。
- 文档中提到可以通过设置
-
源端和目标端性能调优：
- 源端数据库的日志生成速率以及目标端处理这些日志的能力也会影响整体同步速度。确保两端都进行了适当的性能调优，例如通过合理的索引设计、表分区策略等手段提高查询效率。
-
其他潜在因素：
- 同步任务本身的复杂度，比如是否存在大量的 DDL 操作或者复杂的 DML 过滤规则，都会对同步速度产生影响。尽量简化同步逻辑，减少不必要的处理步骤。
综上所述，在决定是否提升硬件配置之前，建议先从以上几个方面入手进行排查和优化。如果经过一系列调优后仍然无法满足业务需求，再考虑适当升级硬件配置。同时，也可以参考官方提供的最佳实践指南，进一步挖掘性能潜力。
如果您有具体的性能指标或者遇到特定问题，请提供更多详细信息，以便给出更有针对性的建议。
更多信息请查看:
1 个赞
配置拉伸到32核心64g目前感觉速度也不是很快，资源用的也不满一半都没，工作线程和切片线程我都调到200切分粒度2000，不知道这正常吗，我部署的是麒麟的x86我看oms部署文档没有支持麒麟，不知道是不是与这有关系。我照着你们的建议我再看看
1 个赞
2 个赞
大佬帮忙分析这个同步速度，目前来看查询没有瓶颈，oms配置提升到32核心64g的centos7，公网带宽没有跑满。但是写入速度却很慢，4.3.5三节点ob，看ob的sql分析也没有写入的慢sql。
{“heapMemoryMax”:60620,“heapMemoryInit”:65536,“heapMemoryUsed”:18169,“heapMemoryCommitted”:60620,“noHeapMemoryMax”:0,“noHeapMemoryInit”:2,“noHeapMemoryUsed”:57,“noHeapMemoryCommitted”:61,“gcInfoList”:[{“name”:“ParNew”,“count”:4,“costMs”:270},{“name”:“ConcurrentMarkSweep”,“count”:1,“costMs”:56}],“threadCount”:141}"},“dataflow”:{“slice_queue”:128},“os”:{“OS”:"{“cpu”:0.7731958762886598,“sysCpu”:2.0618556701030926}"},“sink”:{“sink_worker_num”:32,“ob_watermark_detect_times”:271,“sink_request_time”:4.61,“source_iops”:2804786.0,“sink_total_transaction”:5663.0,“ob_exceed_mem_high_watermark_times”:0,“sink_total_record”:2808040.0,“paused_time_ms”:0.0,“sink_commit_time”:1863.45,“sink_worker_num_all”:32,“shardTime”:0.0,“sink_total_bytes”:1.114530782E9,“sink_delay”:1741877920795,“paused_total_time_ms”:0.0,“ob_free_memory”:86,“rps”:8713.89,“tps”:15.9,“ob_exceed_cpu_high_watermark_times”:0,“iops”:3867534.0,“sinkSlowRoutes”:"",“sink_execute_time”:0.43,“ob_free_cpu”:-1},“source”:{“source_read_time”:0.0,“source_rps”:8798.72,“source_slice_time”:3.94,“source_worker_num_all”:32,“source_worker_num”:32},“dispatcher”:{“wait_dispatch_record_size”:32377,“ready_execute_batch_size”:34},“frame”:{“SourceTaskManager.createdSourceSize”:0,“queue_slot1.batchAccumulate”:512,“frame.throttle.throttle_memory_remain”:“none”,“queue_slot1.batchCount”:6242.0,“queue_slot1.tps”:15.800000190734863}}
1 个赞
metrics.log提供一下 全部发出来看看 最好是一个文件的形式发出来 比较容易看
1 个赞
为啥会慢嘞，有点不明白，ob的配置也不低16核心64g的 我看性能监控io也不高
是因为表太多了吗，2000张表
看着是目的端写入慢了，sink_commit_time": 2252.92 这个看着时间很长