DM 中 relay log 性能优化实践丨TiDB 工具分享-低调大师

DM 中 relay log 性能优化实践丨TiDB 工具分享

2022-03-02 396

前言

Relay log 类似 binary log，是指一组包含数据库变更事件的文件，加上相关的 index 和 mata 文件，具体细节参考官方文档。在 DM 中针对某个上游开启 relay log 后，相比不开启，有如下优势：

不开启 relay log 时，每个 subtask 都会连接上游数据库拉取 binlog 数据，会对上游数据库造成较大压力，而开启后，只需创建一个连接拉取 binlog 数据到本地，各个 subtask 可读取本地的 relay log 数据。
上游数据库对 binlog 一般会有一个失效时间，或者会主动 purge binlog，以清理空间。在不开启 relay log 时，如果 DM 同步进度较为落后，一旦 binlog 被清理，会导致同步失败，只能重新进行全量迁移；开启 relay log 后，binlog 数据会被实时拉取并写入到本地，与当前同步进度无关，可有效避免前面的问题。

但在 DM 版本 <= v2.0.7 中，开启 relay log 后有如下问题：

数据同步延迟相比不开启 relay log 有明显上升，下面的表格是一个单 task 的 benchmark 的测试结果，可看出平均 latency 有明显的增长。下表中以“.”开头的是延迟的百分位数据。

开启 relay 后 CPU 消耗增加。（由于 latency 的增长，在一些简单场景下（比如只有 1 个 task）相比不开启 relay log，资源使用率反而是下降的。但当 task 增多时，开启 relay 的 CPU 消耗就增加了）。

由于以上问题，在新的版本中，我们对 DM 的 relay log 做了一些性能优化。

当前 relay 实现

在开始介绍具体的优化之前，首先简单介绍下当前 DM 中 relay 的实现，详细实现，详情可参阅 DM 源码阅读系列文章（六）relay log 的实现，本文在此不做过多描述。

当前 relay 模块可以分为两个部分，relay writer 和 relay reader 部分，其结构如下所示：

Relay writer

relay writer 依次做了下述 3 个事情：

使用 binlog reader 从上游 MySQL/MariaDB 读取 binlog event；
将读取到的 binlog event 使用 binlog transformer 进行转换；
将转换后的 binlog event 使用 binlog writer 以 relay log file 的形式存储在本地的 relay directory 中。

Relay reader

开启 relay 后，Syncer 会通过 relay reader 获取 binlog event，relay reader 主要是做了如下工作：

读取 realy directory 中的 binlog 文件，发送给 syncer；
当读取到文件尾时，定时（目前是每隔 100ms）检查当前 binlog 文件大小和 meta 文件内容是否存在变化，如果改变则继续读取（binlog 文件变化）或者切换到新的文件（meta 文件变化）。

从上面的介绍可以看出，relay reader 跟 relay writer 是相互独立的，彼此通过 relay directory 中的 binlog、meta 和 index 文件进行交互。

测试环境说明

在开始介绍优化内容前，先介绍下优化时使用的环境情况

上游为 MySQL，版本为 5.7.35-log；
下游为单实例的 TiDB，版本为 5.7.25-TiDB-v5.2.1；
DM 使用了 1 个 master 和 1 个 worker
- Latency 基准测试版本为 2021-10-14 号的 master 分支（commit hash 为 d2dc22d）
- CPU 基准测试版本为 2021-11-01 号的 relay 重构分支（commit hash 为9f7ce1d6）
在小规模测试（<= 4 task）下 MySQL/TiDB/DM 运行在同一主机，方便测试，主机环境为 8 核 16G；
较大规模测试（> 4 task）下 MySQL/TiDB/DM 分别运行在一台主机上，主机都是 8 核 16G
测量迁移延迟采用下游自更新时间列的方式，详细参考多种方式告诉你如何计算DM同步数据到 TiDB 的延时时间中的第三种方式。

Latency 优化

从上面的“当前 relay 实现”部分可以看出，有两个可能影响 latency 的点：

当前 relay reader 的定时 check 的实现方式本身就会对 latency 有一定影响，在最坏情况下一个 binlog event 至少要延迟 100ms 才能同步到下游；
relay writer 会写到磁盘，之后 relay reader 从磁盘读取，这一读一写是否会对 latency 有较大影响？
- 调研发现 linux 系统（Mac OS 系统下也有类似机制）下存在 page cache 的机制，读取最近写入的文件并非通过磁盘，而是读取 OS 内存中的缓存，因此理论上影响有限。

经过调研以及对上述问题的测试，我们总结了两个方案：

在内存中缓存 relay writer 在最近一段时间内预备写入的 binlog，如果 relay reader 请求这段 binlog，relay reader 直接从内存读取；
relay reader 仍然采用读取文件的方式，relay writer 在写入新的 event 时，通知 relay reader。

方案 1 需要根据下游的写入速度在读内存和读文件之间进行切换，实现起来相对复杂，而且由于 OS 层 page cache 的存在，应用本身再增加一层缓存对 latency 的影响有限。

方案 2，我们做了一些初步的测试，在增加 relay reader check 的频率时，开启 relay 基本能达到不开启 relay 时的latency，调研了下 MySQL 的 relay log，发现也是通过读取文件的方式，因此我们选择了方案 2。

实现相对较简单，在 relay writer 增加了 Listener，在有新 binlog event 时通知该 Listener（往 channel 中发送一个消息），然后在 relay reader 中，将定时 check 改为监听 channel 中的消息。

下图是在 4 table 4 task 测试下的 latency 结果，可以看出开启 relay 后的 latency 跟不开启很接近：

CPU 优化

Latency 优化完后，我们也对开启 relay log 后的 CPU 占用情况做了测试，发现开启后 CPU 占用率也较高，下图是在 4 table 4 task 下测试结果（注：后续没有特殊说明的话，都是在该场景下的测试结果），可以看出开启 relay 后 CPU 消耗有明显增长，而且尖刺变得更大：

使用 golang 自带的 pprof 做了一个 CPU profile，从下图可以看出占比较大的主要是 syncer/relay reader/relay writer 等部分，对比代码逻辑后，发现：

Relay reader 使用了 go-mysql 的 ParseFile 接口，该接口每次调用都会重新打开文件，并读取第一个 FORMAT_DESCRIPTION 事件，也就是下图中第一个蓝色标注的位置；
在优化 latency 时，由于 relay reader 和 writer 是相互独立的，为了简化实现，仅通过 channel 通知是否存在新的 binlog 写入，而新写入的 binlog 可能在上次读取的时候已经读取过了，这导致了很多无效的 meta、index 文件的检查。

针对上面的问题，我们做了如下优化：

使用 go-mysql 的 ParseReader 来消除重复打开和读取的消耗；
重构 relay 模块，将 relay writer 和 reader 整合在一起，方便两者间通信。relay reader 在通过 channel 收到通知后，检查当前 relay writer 正在写入的文件是否跟正在读取的文件相同，即该文件是否为 active 写入状态，并获取当前文件写入的位置，通过这些信息，可以避免无效的 meta、index 文件的检查。

从下图可以看出优化后 CPU 有较大幅度的降低，但是尖刺仍然较大：

由于我们测试用的 sysbench 产生 write 事件的速率是比较平稳的，DM 中也没有特别的执行代码，而 Golang 是一个编译型带 GC 的语言，因此我们猜测尖刺主要来自于 GC，但是这一点从 CPU profile 并不明显，见下图：

使用 GODEBUG=gctrace=1开启 GC 日志，见下图，可以发现：

开启 relay 后，驻留内存大了接近一倍（239 MB -> 449 MB），Heap 总空间也大了近一倍。
- 经过调研该问题是由于 DM 内嵌的 tidb 导致的内存泄漏，暂时未处理。
开启 relay 后，GC 占用的 CPU 大幅增加，特别是 background GC time 和 idle GC time。

下图是上面优化后做的 heap profile 中 alloc_space 部分的火焰图：

说明：pprof 的 heap profile 是程序运行至今的一个剖析，并不是某一段时间内，所以从下图中也可以看到一些驻留内存的申请。

通过 heap profile 并对比代码，发现了以下可优化的点：

Go-mysql 在从文件解析 binlog event 时，每个 event 都会重新申请一个 bytes.Buffer，并在读取过程中不断扩容。优化后改为使用一个 buffer pool，减少不断扩容带来的开销；
Local streamer 中 heatbeat event 使用了 time.After ，使用该接口代码会更简洁，但是该接口创建的 channel 只在触发 timer 时才会释放，另外 Local streamer 读取事件是一个高频调用，每次调用都创建一个 timer channel 开销也较大。优化后改为复用 timer；
Relay 从上游读取事件时使用了一个 timeout context，每次读取都会创建一个额外的 channel，而在当前场景下，该 timeout context 并没必要。优化后去掉了该 timeout context；
Relay reader、relay writer 写入 debug 日志未检测 log level，每次都会创建一些 Field 对象，虽然不大，但是由于这些操作调用频率较高，也会带来一些开销。优化后，对高频调用的 debug 日志，增加 log level 判断。
- 说明：DM 写入日志使用的 zap logger ，该 logger 性能较好，在非高频调用下，直接调用 log.Debug 一般是没问题的。

优化后的结果如下，可以看出 CPU 又降低了不少，尖刺也少了很多：

下图为在 20 table 20 task 场景下的测试结果：

遗留问题 & 未来工作

经过上面的优化，开启 relay 相比不开 relay，在 latency 上的差距已经很小， CPU 的增长也在一个相对低的水平，但是仍有一些点是可以继续优化的，预期会在后续版本中逐步添加，如下：

go-mysql读文件使用的 io.CopyN，这个函数内部会申请一个小对象，高频使用情况下还是对 GC 有一些影响的，但不大，这次暂时没改；
有些对 no relay和 relay同时生效的优化这次没做，比如 streamer 读取 event 时创建的 timeout context；
目前看多个 reader 读同一个文件还是有不少开销的，再优化的可能方案：
- 减少读的次数，比如一个 reader 读完、其他的 reader 读内存之类的，或者像之前设想的增加内存缓存的方式；
- 合并相同下游的 task，减少 task 数量。

微信关注我们

原文链接：https://my.oschina.net/zhaiyuan/blog/5470924

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

高性能图计算系统 Plato 在 Nebula Graph 中的实践

本文首发于公众号 Nebula Graph Community 1.图计算介绍 1.1 图数据库 vs 图计算图数据库是面向 OLTP 场景，强调增删改查，并且一个查询往往只涉及到全图中的少量数据，而图计算是面向 OLAP 场景，往往是针对全图数据进行分析计算。 1.2 图计算系统分布架构按照分布架构，图计算系统分为单机和分布式。单机图计算系统优势在于模型简单，无需考虑分布式通讯，也无需进行图切分，但受制于单机系统资源，无法进行更大规模的图数据分析。分布式图计算平台将图数据划分到多个机器上，从而处理更大规模的图数据，但不可避免的引入了分布式通讯的开销问题。 1.3 图的划分图划分主要有两种方式边切割（Edge- Cut）和点切割（Vertex-Cut）。边分割：每个点的数据只会存储在一台机器上，但有的边会被打断分到多台机器上。如图(a)所示，点 A 的数据只存放在机器 1 上，点B 的数据只存放在机器 2 上。对于边 AB 而言，会存储在机器 1 和机器 2 上。由于点 A 和点 B 分布在不同的机器上，在迭代计算过程中，会带来通讯上的开销。点分割：每条边只会存储在一台...

2022-03-02

476

作者：鲸腾 FE 来源：恒生LIGHT云社区 Nginx简介 Nginx 是一款由俄罗斯的程序设计师 Igor Sysoev 所开发的高性能的 http 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，它的主要功能有：反向代理负载均衡 HTTP 服务器目前大部分运行的 Nginx 服务器都在使用其负载均衡的功能作为服务集群的系统架构。功能说明在上文中介绍了三种 Nginx 的主要功能，下面来讲讲具体每个功能的作用。一、反向代理（Reverse Proxy）介绍反向代理前，我们先理解下正向代理的概念。打个比方，你准备去看周杰伦的巡演，但是发现官方渠道的票已经卖完了，所以你只好托你神通广大的朋友A去内部购票，你如愿以偿地得到了这张门票。在这个过程中，朋友A就起到了一个正向代理的作用，即代理了客户端（你）去向服务端（售票方）发请求，但服务端（售票方）并不知道源头是谁发起的请求，只知道是代理服务（朋友A）向自己请求的。由这个例子，我们再去理解下反向代理，比如我们经常接到10086或者10000的电话，但是每次打过来的人都不一样，这是因为10086是中国移动...

2022-03-02

512

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。