最大化rsync性能和吞吐量-直接连接的千兆服务器

我有两台运行CentOS 6.5的Dell R515服务器，每台中的一个Broadcom NIC直接连接到另一个。我每晚使用rsync over ssh使用直接链接将备份从一对中的主服务器推送到辅助服务器。监控流量，我发现吞吐量约为2MBps，这比我从千兆端口获得的预期要低得多。我已经将双方的MTU设置为9000，但这似乎并没有改变。

是否有建议的设置和优化设置，这些设置和优化可以使我达到最大可用吞吐量？此外，由于我在ssh上使用rsync（或可能只是NFS）来复制数百万个文件（〜6Tb的小文件-巨大的Zimbra邮件存储区），因此我正在寻找的优化可能需要针对我的特定用例进行更具体的说明。

我在两侧都使用ext4，如果这很重要

谢谢

编辑：我使用了以下rsync选项，结果非常相似：

rsync -rtvu --delete source_folder/ destination_folder/

rsync -avHK --delete --backup --backup-dir=$BACKUPDIR source_folder/ destination_folder/

当前，在同cp一个直接电缆链接上使用NFS导出时，我看到的是同样水平的性能下降。

EDIT2：完成同步后，我可以运行iperf并发现性能约为990Mbits / sec，其缓慢是由于使用了实际的数据集。

— dyasny
source

您应该将rsync添加到标签中。您是否检查了rsync上市部分的时间？吞吐量低的原因可能是文件太小。您可以发布rsync命令来检查选项吗？

— kranteg

@kranteg，请参阅编辑

— dyasny 2014年

请通过验证连接iperf。

— ewwhite

是的，iperf显示为991mbits / s，我想这是太慢的数据集

— dyasny 2014年

使用rsync和包含小文件的数据集无法获得良好的throuphput。您绝对应该尝试tar。

— kranteg

Answers:

文件数量和SSH加密开销可能是最大的障碍。您不会在这样的传输中看到线速。

改进的选项包括：

将rsync + SSH与更便宜的加密算法结合使用（例如-e "ssh -c arcfour"）
使用诸如HPN-SSH之类的东西，完全通过SSH传输消除加密。
基于块的传输。快照，dd，ZFS快照发送/接收，等等。
如果是一次或不频繁的传输，请使用tar，netcat（nc），mbuffer或某种组合。
检查您的CentOS tuned-adm设置。
从文件系统挂载中删除atime。检查其他文件系统安装选项。
NIC发送/接收缓冲区。
调整rsync命令。会-W中，整体文件选项在这里做有意义吗？是否启用压缩？
针对传输类型（SSD，主轴数，RAID控制器缓存）优化存储子系统。

— 怀特
source

我已经将SSH用于NFS了，看到了几乎相同的结果。我正在计划基于块的传输，切换到基于LVM快照的备份并将dd备份到第二台服务器，在第二台服务器上我将运行ZFS进行重复数据删除。双方均禁用atime。不使用压缩。如何优化这种传输的存储子系统？该源具有两个12x 10k SAS驱动器的RAID10，一个在本地驱动器上，另一个在MD1220上。备份服务器具有相同的磁盘数量，但具有大型SATA驱动器，并使用RAID5。两侧均具有完整缓存H800和H700控制器。2Mbps的（从iftop的）〜

— dyasny

〜让我觉得网络仍然是这里的瓶颈。

— dyasny 2014年

@dyasny确定要测试您的网络iperf。

— ewwhite 2014年

@dyasny是的。您需要了解的有关ZFS的大多数信息都在这里

— ewwhite

确保目标目录结构是由创建的rsync，不是由创建的cp。我看过更新原本由以下人员创建的远程目录树rsync需要花费更长的时间cp：88GB已用1h26m而不是3h的校验和更新了！如何创建初始磁盘布局对于获得良好的更新性能至关重要。CPU时间是相同的；实时可以翻倍。（从SSD到200GB的Seagate，仅需13分钟即可运行相同的更新而无需校验）。

— 伊恩·艾伦

您可能知道复制很多小文件（例如，使用MailDir格式或类似格式的邮箱）绝对不是利用高带宽接口的最佳选择。SSH可能也不是最佳的传输协议。我会尝试使用tar在源主机上创建tarball，然后再将其发送到辅助主机。

tar c /var/mail | ssh root@secondary-host 'tar x -C /var/backups'

如果需要增量备份，则可能要尝试使用-gtar选项。如果仍然需要最大化吞吐量，请尝试使用netcat而不是ssh。

— Alxgomz
source

我已切换到NFS而不是SSH，以消除加密开销，这并不

— 令人高兴

您是否尝试过使用tar？第一步，请尝试在主服务器上创建本地Tarbal，然后通过网络进行传输。（或使用iperf测试您的网络，如@ewwhite推荐）

— alxgomz 2014年

如果我有地方可用，我会的。即使使用完全填充的DAS盒，这也非常庞大

— dyasny 2014年

然后尝试通过netcat或ssh管道传输（尽管效率不高）

— alxgomz 2014年

稍后我将切换到基于块的备份，然后打算通过管道dd进行备份nc。但是现在，我陷入了两个巨大的备份，然后需要从主主机上移开，所以我可以在那里创建LVM系统

— dyasny 2014年

尝试弄清影响因素：

CPU（例如/ dev / zero的dd通过回送管道）
磁盘I / O（例如，将大文件的dd通过管道传输到cat> / dev / null [通过管道传输以防止短路]）
物理网络I / O（例如，通过dd管道传输到另一台计算机）
等等

并独立测试它们。

我对Broadcom驱动程序有一些不好的经验，所以我的第一个建议是使用以下方法测试可用的网络带宽： dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null

— 斯科特·利德利
source

还是iperf ...

— ewwhite