共计 3790 个字符，预计需要花费 10 分钟才能阅读完成。
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 剖析性能也能帮忙大家疾速定位和剖析遇到的性能问题。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)