利用JuiceFS使MySQL 备份验证性能提升 10 倍

目录
  • 数据准备
  • 使用默认参数
  • 增大XtraBackup的内存缓冲区
  • 增大XtraBackup读线程数
  • JuiceFS启用异步写
  • 增大JuiceFS的磁盘缓存
  • 增大数据库数据量
  • 总结

前言:

JuiceFS 非常适合用来做 MySQL 物理备份,具体使用参考官方文档。在测试时,备份验证的数据准备(xtrabackup --prepare)过程非常慢。我们借助 JuiceFS 提供的性能分析工具做了分析,快速发现性能瓶颈,通过不断调整 XtraBackup 的参数和 JuiceFS 的挂载参数,在一个小时内将时间缩短到原先的 1/10。本文将我们性能分析和优化的过程记录分享下来,给大家分析和优化 IO 性能提供参考。

数据准备

我们通过 SysBench 工具生成一个大小 11GiB 左右的单表数据库,数据库表的 partition 设置成 10。为了模拟一个正常的数据库读写场景,通过 SysBench 以秒 50 个请求的压力访问数据库,在该压力下数据库对数据盘造成的写数据在 8~10MiB/s 范围内。通过下列命令将数据库备份到 JuiceFS 上。

# xtrabackup --backup --target-dir=/jfs/base/

为了保证每次数据准备操作的数据完全一样,使用 JuiceFS 的快照(snapshot)功能基于 /jfs/base 目录生成快照 /jfs/base_snapshot/。每一次操作前都会将前一次数据准备操作过的数据删掉重新生成一个新的快照。

使用默认参数

# ./juicefs mount volume-demoz /jfs

#  time xtrabackup --prepare --apply-log-only --target-dir=/jfs/base_snapshot

执行总耗时62秒。

JuiceFS支持导出操作日志 oplog,并能对 oplog 进行可视化展示。在执行 xtrabackup --prepare操作之前我们新开一个终端连接到该服务器,在命令行输入

# cat /jfs/.oplog > oplog.txt

开始搜集 oplog 日志,然后执行 xtrabackup --prepare 操作,操作结束后将 oplog.txt 下载到本地,上传到 JuiceFS 提供的 oplog 分析页面:https://juicefs.com/oplog/

我们将 oplog 进行可视化展示

这里先大致介绍下这个图中各种元素含义。我们的一条 oplog 中包含了时间戳,线程 ID,文件系统操作函数(read, write, fsync, flush 等),操作持续的时间等。左侧数字表示线程 ID,横轴表示时间,不同类型操作用不同颜色标记。

我们把局部图像放大,不同颜色代表不同类型的操作就一目了然。

排除掉与本次操作无关的几个线程。在数据准备过程中有 4 个线程负责读,5 个线程负责写数据,读写在时间上都是重叠的。

增大 XtraBackup 的内存缓冲区

参考 XtraBackup 官方文档,数据准备是使用内嵌的 InnoDB 在备份数据集上执行故障修复(crash recovery)的过程。

使用 --use-memory 选项增大内嵌 InnoDB 的内存缓冲区大小,默认 100MB,我们增大到 4GB。

# time xtrabackup --prepare --use-memory=4G --apply-log-only --target-dir=/jfs/base_snapshot

执行时间降到了33秒。

可以看到读写不重叠了 ,将数据读到内存处理完成后写入文件系统。

增大 XtraBackup 读线程数

通过增大缓冲区将时间缩短了一半,整个读的过程耗时依然比较明显。我们看到每个读线程基本都是跑满的状态,我们尝试增加更多的读线程。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot

行时间降到了23秒。

读线程已经增加到了 16 个(默认 4 个),读操作降到 7 秒左右。

JuiceFS 启用异步写

上一步我们极大的优化了读操作时间,现在写过程消耗的时间就比较明显了。通过分析 oplog,发现写操作中 fsync 是不能并行的,因此增大写线程数并不能提升写的效率,在实际操作过程中我们也通过增大写线程数验证了这一点,这里就不赘述了。分析 oplog 对同一个文件(相同文件描述符)的写操作的参数(偏移,写数据大小),发现有大量的随机写操作,我们可以在挂载 JuiceFS 时启用 --writeback 选项,写数据时先写本地盘,再异步写到对象存储。

# ./juicefs mount --writeback volume-demoz /jfs
# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=16 --innodb-read-io-threads=16 --apply-log-only --target-dir=/jfs/base_snapshot

时间降到了 11.8 秒。

写过程已经降到 1.5 秒左右。

我们看到读线程读操作依然比较密集,我们尝试持续增加读线程数,InnoDB 读线程数最大为 64,我们直接调成 64。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

执行时间 11.2 秒,相比之前基本没变化。

我们看到,读线程读操作已经比较稀疏了,应该是线程读的数据之间有依赖关系,导致不能完全并行化,已经不能通过提升线程数压缩读过程的时间了。

增大 JuiceFS 的磁盘缓存

在上一步中,我们通过提升读线程数来提升读过程的效率已经到顶了,只能通过降低读数据的延迟来减少读过程时间。

JuiceFS 在读操作处理上提供了预读和缓存加速能力,我们接下来尝试通过增大 JuiceFS 的本地缓存来降低读操作的延迟。

将 JuiceFS 的本地缓存由高效云盘换成 SSD 云盘,并将缓存大小由 1G 改成 10G。

# ./juicefs mount --writeback volume-demoz --cache-size=10000 --cache-dir=/data/jfsCache /jfs

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

执行时间降到了 6.9 秒。

通过提升缓存性能和增大缓存空间进一步减少了读操作耗时。

到此我们总结一下,我们通过分析 oplog,不断寻找可以优化的点,将整个数据准备过程一步步从 62 秒降到 6.9 秒,效果通过下图更直观的展示。

增大数据库数据量

以上的操作都是针对 11G 这样一个比较小的数据集不断调整参数进行优化得到一个很好的结果。作为对比,我们以同样的方式生成一个 115G 左右的 partition 为10的单表数据库。在 SysBench 持续每秒 50 个请求情况下,执行备份操作。

# time xtrabackup --prepare --use-memory=4G --innodb-file-io-threads=64 --innodb-read-io-threads=64 --apply-log-only --target-dir=/jfs/base_snapshot

这个过程耗时 74 秒。

我们看到,读和写还是分开的。

在数据量增大10倍左右,相应的准备时间也增大到10倍。这是因为备份(xtrabackup --backup)过程所需的时间扩大到 10 倍,在 SysBench 对数据库压力不变的情况下,备份过程中产生的 xtrabackup_logfile 也是原先的 10 倍。数据准备是要把 xtrabackup_logfile 中的所有数据更新合并到数据文件中,可见即使数据规模增大了 10 倍,但更新单条日志的时间基本不变。从上图也可以验证这一点,数据规模增大后,准备过程仍然是分成了读数据和写数据这两个明显的过程,说明设定的 4GB 的缓冲区大小仍然是够用的,整个过程仍然可以在内存中完成然后更新到文件系统。

总结

我们使用 SysBench 这个相对简单的工具构造初始数据,持续给数据库一定数据更新的压力模拟数据备份时数据库运行场景。使用 JuiceFS 的 oplog 来观察 XtraBackup 在数据准备过程中访问备份数据的读写特点,调整 XtraBackup 和 JuiceFS 的参数来不断优化数据准备过程的效率。

在实际生产场景中,情况比我们 SysBench 模拟要复杂得多,我们上面的线性关系不一定严格成立,但是我们通过分析 oplog 快速发现可以优化的点,进而不断调整 XtraBackup 和 JuiceFS 的缓存和并发的思路是通用的。

整个调参过程耗时 1 小时左右,oplog 分析工具在这个过程中发挥了很大的作用,帮助我们快速定位系统性能瓶颈,从而针对性地调整参数做优化,也希望这个 oplog 分析功能也能帮助大家快速定位和分析遇到的性能问题。

到此这篇关于利用JuiceFS使MySQL 备份验证性能提升 10 倍的文章就介绍到这了,更多相关 MySQL 性能提升 内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 使用FriendFeed来提升MySQL性能的方法

     背景 我们使用MySQL存储了FriendFeed的所有数据.数据库随着用户基数的增长而增长了很多.现在已经存储了超过2.5亿条记录与一堆涵盖了从评论和"喜欢"到好友列表的其他数据. 随着数据的增长,我们也曾迭代地解决了随着如此迅猛的增长而带来的扩展性问题.我们的尝试很有代表性,例如使用只读mysql从节点和memcache来增加读取吞吐量,对数据库进行分片来提高写入吞吐量.然而,随着业务的增长,添加新功能比扩展既有功能以迎合更多的流量变得更加困难. 特别的,对 schema 做改动

  • Python 使用 PyMysql、DBUtils 创建连接池提升性能

    Python 编程中可以使用 PyMysql 进行数据库的连接及诸如查询/插入/更新等操作,但是每次连接 MySQL 数据库请求时,都是独立的去请求访问,相当浪费资源,而且访问数量达到一定数量时,对 mysql 的性能会产生较大的影响.因此,实际使用中,通常会使用数据库的连接池技术,来访问数据库达到资源复用的目的. 解决方案:DBUtils DBUtils 是一套 Python 数据库连接池包,并允许对非线程安全的数据库接口进行线程安全包装.DBUtils 来自 Webware for Pyth

  • Rails中使用MySQL分区表一个提升性能的方法

    MySQL 的分区表是一种简单有效的处理极大数据表的特性,通过它可以使应用程序几乎很少改动就能达成对极大数据表的高效处理,但由于 Rails ActiveRecord 设计上一些惯例,可能导致一些数据处理不能利用分区表特性,反而变得很慢,在使用分区表过程中一定要多加注意. 下面以一个例子来说明.在 light 系统中,有一张数据表是 diet_items, 主要字段是 id, schedule_id, meal_order food_id, weight, calory 等等,它的每一条记录表示

  • 利用JuiceFS使MySQL 备份验证性能提升 10 倍

    目录 数据准备 使用默认参数 增大XtraBackup的内存缓冲区 增大XtraBackup读线程数 JuiceFS启用异步写 增大JuiceFS的磁盘缓存 增大数据库数据量 总结 前言: JuiceFS 非常适合用来做 MySQL 物理备份,具体使用参考官方文档.在测试时,备份验证的数据准备(xtrabackup --prepare)过程非常慢.我们借助 JuiceFS 提供的性能分析工具做了分析,快速发现性能瓶颈,通过不断调整 XtraBackup 的参数和 JuiceFS 的挂载参数,在一

  • Nginx开启一个参数就能让你的WEB性能提升3倍的方法

    一.遇到的一些问题 记得 2008 年做性能测试的时候,新进7台 lenovo 4核4G 服务器用于性能测试. 当时资源紧张,这7台服务器都装了双系统(Win2003/CentOS5)空闲时用于做测试机(压测的Agent). 当时给Nginx做了一系列测试,印象很深的是:在这批机器上,Nginx状态页面的压测. 短连接的话最佳QPS约4万,长连接的话最高QPS约13万. 大概3年后,那批 lenovo 服务器已经没人瞧得上了,只能做肉鸡. 然而,一次不经意的测试,发现再牛的服务器,短连接最佳QP

  • MongoDB创建一个索引而性能提升1000倍示例代码

    MongoDB 创建索引的语法 1.为普通字段添加索引,并且为索引命名 db.集合名.createIndex( {"字段名": 1 },{"name":'idx_字段名'}) 说明: (1)索引命名规范:idx_<构成索引的字段名>.如果字段名字过长,可采用字段缩写. (2)字段值后面的 1 代表升序:如是 -1 代表 降序. 2.为内嵌字段添加索引 db.集合名.createIndex({"字段名.内嵌字段名":1},{"

  • JAVA下单接口优化实战TPS性能提高10倍

    概述 最近公司的下单接口有些慢,老板担心无法支撑双11,想让我优化一把,但是前提是不允许大改,因为下单接口太复杂了,如果改动太大,怕有风险.另外开发成本和测试成本也非常大.对于这种有挑战性的任务,我向来是非常喜欢的,因为在解决问题的过程中,可以学习到很多东西. 当时我只是知道下单接口慢,但是没人告诉我慢在哪里,也即是说,哪些瓶颈导致下单接口慢了.其实没人知道也没关系的,因为我们可以通过压测来找到具体的瓶颈. 下面会详细介绍一下,在本次压测中遇到的问题以及如何解决,期间用了什么工具. 用到的工具和

  • ASP.NET页面优化 性能提升8倍的方法

    为了让您对优化的效果有个直观的了解,我准备了下面的测试结果截图: 测试环境: 1. Windows Server 2003 SP2 2. Viaual Studio 2008,使用自带的WebDev.WebServer.EXE运行网站程序. 3. (ThinkPad SL510):Core2 T6670 2.2GHz, 4G内存 二个红框中的数字反映了优化前后的执行时间. 数字表明:优化前后,执行时间有了8倍多的差别. 测试背景 看过了优化结果,再来介绍一下:这个测试到底是在测试什么东西? 现在

  • centos7中如何利用crontab进行mysql定时备份

    目录 centos7用crontab进行mysql定时备份 备注 附crontab文件的一些例子 总结 centos7用crontab进行mysql定时备份 1.建立 mysql3306_backup.sh 文件 文件名及路径可以自定义,个人习惯将脚本.脚本日志.备份的数据放在mysql的data路径下,方便查找 mysql3306_backup.sh内容: #!/bin/bash # 以下配置信息请自己修改 mysql_user="USER" #MySQL备份用户 mysql_pas

  • 详解如何利用Xtrabackup进行mysql增量备份

    目录 利用Xtrabackup进行mysql增量备份 安装 设置数据库用于备份账户 全量备份 增量备份 提问总结 原理 为什么最后一次增量备份不用 "--apply-log-only" 为什么备份完后要准备备份 "prepare" 为什么选择这个做备份? 利用Xtrabackup进行mysql增量备份 现在xtrabackup版本升级到了8.0,但是只对mysql8.0才有支持, 我们这还是使用2.4, 但是2.4相比之前的2.1有了比较大的变化:innobacku

  • php7性能提升的原因详解

    为什么PHP7的性能可以提高这么多? 1. JIT 2. Zval的改变 3. 内部类型zend_string 4. PHP数组的变化(HashTable和Zend Array) 5. 函数调用机制(Function Calling Convention) 6. 通过宏定义和内联函数(inline),让编译器提前完成部分工作 为什么PHP7的在实际的业务性能提高才30%左右? 实际的业务不一定有很复杂的计算逻辑 实际的业务会用到Redis 和MYSQL,网络和IO的瓶颈 影响了PHP7的整体性能

  • MySQL数据库查询性能优化策略

    优化查询 使用Explain语句分析查询语句 Explain 用来分析 SELECT 查询语句,开发人员可以通过分析 Explain 结果来优化查询语句. 通过对查询语句的分析,可以了解查询语句的执行情况,找出查询语句执行的瓶颈,从而优化查询语句. 使用索引查询 MySql中提高性能的一个最有效的方式就是对数据表设计合理的索引. 索引提供了高效访问数据的方法,并且加快查询速度. 如果查询时没有使用索引,那么查询语句将扫描表中所有的记录.在数据量大的时候,这样查询速度会很慢. 使用索引进行查询,查

  • MySQL备份脚本的写法

    前言: 数据库备份的重要性不言而喻,特别是在生产环境,任何数据的丢失都可能产生严重的后果.所以,无论什么环境,我们都应该有相应的备份策略来定时备份数据库.在 MySQL 中,比较常用的逻辑备份工具是 mysqldump,本篇文章将介绍 MySQL 定时备份的方法. 1.制定合适的备份策略 对于不同的数据库环境,我们应该考虑不同的备份策略.制定备份策略时,应考虑以下几点因素: 物理备份还是逻辑备份.这个可以由数据库大小决定,比如说小于100G用逻辑备份,大于100G用物理备份. 备份文件保留时间.

随机推荐