Rsync 传输大文件性能问题

2024-07-09 23:05:10 +08:00
 jolly336

使用 Rsync 在 Mac 电脑上拉服务器上的单个大文件,文件大小 600MB~2G 左右,文件格式 ZIP ,服务端用的 rsync daemon tcp 运行,拉取是增量拉取的,是在服务器修改 ZIP 里的一些 entry 然后拉的,发现 rsync diff 实际拉取了 6M ,但拉取耗时 7s ,Mac 电脑的下载速度是 40Mb/s ,算下来 rsync 的速度才有 6M/7s = 0.85MB/s ,这个如何优化?

目前的想法有这几个:

  1. 调整 rsync 的 --block-size 大小,调整的小一点,测下来能快一点,但这个还是有限;
  2. 拆分服务端的 ZIP 文件,Mac 并行拉取,但这个有一些问题,比如拆分开拉 rsync 要传输的数据量变多了,并行会存在电脑 CPU 、IO 竞争切换,效果会不如直接拉 ZIP ;

还有啥好办法,求指点

2046 次点击
所在节点    问与答
17 条回复
ferock
2024-07-09 23:48:57 +08:00
加上 -W 参数,减少校验试试
jolly336
2024-07-09 23:57:39 +08:00
@ferock -W, --whole-file copy files whole (without rsync algorithm) 就真成了 scp 了,会 disable 增量传输,文件太大了,是不行的
dann73580
2024-07-10 00:31:33 +08:00
换 rclone 才是真解,可以多线程,大文件还能配置分块上传。
yingxiangyu
2024-07-10 01:05:12 +08:00
换 http ,起了端口直接 wget
adrianzhang
2024-07-10 06:20:26 +08:00
瓶颈是啥? IO 还是 CPU ?确定后针对性解决呗。
T0m008
2024-07-10 07:05:39 +08:00
单个文件还要增量传输?不是多此一举吗?要么-W 要么直接 scp, 别折腾了
june4
2024-07-10 08:43:06 +08:00
起个 http 文件服务不就是可以断点继传了,wget 和 aria 之类的都可以断线自动重连继传。
jolly336
2024-07-10 12:02:26 +08:00
@T0m008 scp 没有增量传输了,全部传,Mac 网速一般,这个没法改变,还得要增量拉
jolly336
2024-07-10 12:03:44 +08:00
@dann73580 server 是部署的 K8S 这套,也能用吗?这个支持增量传吗?还有在本地 Mac 网速有限的情况下,能最快拉回文件
jolly336
2024-07-10 12:04:52 +08:00
@adrianzhang 测试了下,Mac 网速不好时 40Mb/s ,瓶颈在网速 IO 这,网速比较高 1000Mb/s 时,瓶颈在服务器磁盘 IO 上
jolly336
2024-07-10 12:05:16 +08:00
@yingxiangyu 这个很原始,没法做到增量 diff 拉取呐
adrianzhang
2024-07-10 12:20:39 +08:00
@jolly336 网速瓶颈的解决,可以依靠 tcp over udp 或 quic 。磁盘 io 解决是把文件直接就放 ram 盘里。
T0m008
2024-07-10 12:38:18 +08:00
@jolly336 你没搞明白吧,单个文件就能把带宽跑满了,你再增量有什么用?你瓶颈在 io 上,增量反而会更慢的
Aurorataro
2024-07-10 13:02:50 +08:00
@jolly336 #9 你的需求适合 rclone copy
happyxhw101
2024-07-10 13:47:41 +08:00
据我调研所知,之前专门调研过,rsync ,rclone 都不支持单文件增量,只有 syncting 支持 apeend 形式的增量,也就是虽然 diff 只有 6M ,但是需要把整个文件重新同步一次
happyxhw101
2024-07-10 13:49:10 +08:00
jolly336
2024-07-12 11:07:47 +08:00
感谢各位大佬的解答,目前看来各种工具还是只有 Rsync 能满足增量拉取,只是性能有点问题,在增量拉取单个大文件时 sender 端要挨个数据块计算 checksum ,这期间网络是空闲的,到传输变动字节数据时网速还是可以的,所以耗时就在 rsync 只会单核 CPU 工作,checksum 拉长了耗时。
目前准备切片并行传的试下,但这种会出现资源竞争,整体耗时有时候会劣化。不知道还有啥好思路优化?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1056082

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX