通过监控指标分析性能瓶颈

初步分析与调试

图1 性能调优初步分析与调试

由于全量阶段的数据量较大，需要更高的并发资源。当全量阶段同步速率较低时，请优先通过增加任务并发来解决。全量阶段完成后，可以暂停作业回调资源。如果上述措施对提升同步效率效果不明显，可进一步分析性能瓶颈，详情请参见分析性能瓶颈部分。

当增量阶段同步速率慢或时延增加时，首先观察监控指标或作业告警中是否有作业重试。作业重试可能阻塞数据同步进程，导致时延上升，需通过查看作业日志找到并解决作业重试问题。

图2 作业监控指标显示作业近期存在重试

增量阶段如果没有作业重试但同步效率仍低，则需进一步分析性能瓶颈，详情请参见分析性能瓶颈部分。

分析性能瓶颈

通过查看内存、反压等监控性能指标，确定性能下降的原因，以及瓶颈位于源端还是目的端。

图3 通过监控指标分析性能瓶颈

• 内存占用100%

  当作业的内存占用达到100%时，意味着内存资源不足，需要扩大作业的内存配置或降低对内存的需求。

  内存使用率达到100%时的实时作业监控指标：

  图4 作业内存耗尽时的监控指标状态
  
  图5 作业内存排查与调优策略
  

  针对内存问题，优先通过增加任务配置中的并发数来解决，增加并发可减轻每个taskmanager上的内存压力。

  增大并发后如果内存占用率仍比较大，可以根据不同的链路做组件级的参数调优，详情请参考各个链路的参数调优介绍，包括：

  • 减少数据缓存的大小和时间。
  • 加快缓存数据的flush速度。
  • 对目的端的表结构进行优化，以提高写入性能。
  • 增加单个taskmanager的处理内存，注意不要造成Migration资源组的资源使用率统计不准确。
  • 对读写速率限流，适合数据量不大对作业稳定性需求较高的场景。

  特殊场景：

  • 监控指标显示内存使用率正常，但是日志中搜索到关键字OutOfMemery或OOMKilled，同样可以判断为内存不足场景。
  • 分库分表场景下，如果源端数据库实例或分表数据过大，可能会导致jobmanager内存占用满，通过设置参数jobmanager.memory.process.size = 6G来即时扩展jobmanager节点内存。
• 作业持续反压100

  长时间作业反压100%，表明可能是目的端写入性能瓶颈，原因可能为：

  • 作业目的端配置或者建表不合理，性能仍有优化空间。
  • 目的端集群压力过大。
  图6 作业反压调优策略
  
  图7 正常反压监控图
  
  图8 作业反压持续100监控图
  
  • 针对作业配置或建表不合理的场景，可以参考各个链路参数调优指导中关于目的端的介绍。
  • 针对目的端集群压力较大的场景需要及时联系目的端数据库运维或开发者调整集群状态。
• 作业反压正常（binlog激增）

  作业反压正常可能为源端抽取性能瓶颈，大部分场景为业务量上涨导致源端binlog激增。部分作业会存在网络问题导致数据抽取速率不足，时延上升。

  源端binlog激增时的MySQL实例监控：

  图9 binlog激增MySQL监控图-1
  
  图10 binlog激增MySQL监控图-2
  

  单小时内binlog文件个数增长破百。

  源端binlog文件激增时，需要及时进行以下操作：

  • 调大实时作业并发，避免目的端写入成为瓶颈，导致源端抽取压力。
  • 调大taskmanager堆内存，避免数据量过大作业异常。

    在任务配置中添加参数：

    taskmanager.memory.managed.fraction = 0（默认0.2）

    taskmanager.memory.process.size = 4G（默认不足4G）

  • 适时将时延较大的表从实时作业中拆分出去，通过离线迁移完成大表的数据迁移。