最近用 rsync 来备份一个大约300G的数据.都一天了还在运行,感觉这个跟内存的使用有关:

cat /proc/memoinfo

MemTotal: 98992132 kB
MemFree: 319196 kB
Buffers: 26052 kB
Cached: 96985728 kB
SwapCached: 0 kB
Active: 25044636 kB
Inactive: 72410604 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 98992132 kB
LowFree: 319196 kB
SwapTotal: 51511288 kB
SwapFree: 51511024 kB
Dirty: 12 kB
Writeback: 304 kB
AnonPages: 443732 kB
Mapped: 61240 kB
Slab: 985844 kB
PageTables: 25240 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 101007352 kB
Committed_AS: 1131388 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 305392 kB
VmallocChunk: 34359430583 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB


有什么办法可以看看瓶颈吗?
用scp

记得rsync有参数可以不比对直接复制的

@arkilis
你怎么用Rsync命令的？我一般用rsync -avuz xxx x.x.x.x::xx/xx ，300G很快的。
是不是源磁盘有问题？
网卡是什么样的？
感觉跟内存无关

Thanks,我只用了两个参数
-a: archive
--partial: keep partially transferred files
网络连接两个设备,但是都是千兆的网卡,速度应该不慢. 磁盘没有问题.

根据客户需求还是需要对比的.

btsync 快

大文件小文件?小文件当然很慢很慢了

刚好相反，这张情况下小文件反而快，因为很多很多小文件，有更大可能性大部分在前后两次备份的时候没有发生变化而跳过。
楼主可以讲讲文件的类型和结构，如果是一个大文件，而且内容经常发生变化，rsync这时候并不能发挥优势。rsync在处理大文件的时候会将文件分块然后hash，相同的块会跳过。因此一些基于行或者有固定元素大小的文件在这个时候会有优势。

纯文本的文件是可以这样...要是binary的数据，块比对没戏了，都直接完全复制覆盖了。

不要用 ssh 协议，用 rsync daemon，可以大幅提升速度

把rsync 作为一个一直running的deamon? interesting

不是，是 rsyncd....用的是 rsync:// 协议，而不是 ssh

rsync://协议就是把rsync作为daemon运行

Thanks!

binary实际上也可以，binary文件可以理解为外星文文本或者乱码文本文件，只要发生修改的时候部分位移/覆盖/删除/追加，都有可能导致分块恰好不变而节约传输。

就是用来备份的,有时候保证数据的完整性,我特意运行RSYNC两次,所以这个时候时间问题就来了. 总的来说以50m左右的binary文件为主,还有一些文本文件.总共的大小为300~500GB.

试试-W

这样…两头机器磁盘IO都得很强才行…
前两年搞过一台备份服务器是32G内存跑Freebsd，直接拿SATA 2T硬盘x2作ZFS的mirror，跑rsyncd服务，zpool持续写入速度120MBytes/sec　吧

ZFS？Linux or FreeBSD or Solaris？如果是 Linux，是基于 kernel 的还是基于 fuse 的？

我18楼的写清楚是 freebsd 啊。solaris 现在收费才能用了，没钱。
授权冲突问题，所以当前 zfs 进不了 linux 内核，fuse 的性能功能稳定性作为生产机风险大。
所以，想提高 当前 linux 的磁盘I/O，只有 SSD/阵列产品