☰

大数据初始rsync备份慢到RAID 5

tag-icon • tag-icon rsync
大数据初始rsync备份慢到RAID 5

我使用 rsync 将大约 28TB 的映像复制到 36TB RAID 5。源具有 SSD，目标具有 RAID 5 配置中的 6 个 8TB 7200 SATA3 512e 驱动器。

服务器通过 10G 光纤连接进行连接。它们是交换机上仅有的两台机器。

源是 CentOS 6.8 目标是 Ubuntu 18.04。

我知道 HDD 不会获得完整的 600MB/s 写入速度，但当我预期至少在 200MB/s 范围内时，我目前只能获得 65MB/s。

速度一开始约为 72MB/s，然后逐渐增加到 83MB/s，然后在大约一个小时的时间内降至并保持在 65MB/s。目前转移正在进行 5 天。

这看起来非常慢。我希望得到任何关于加快速度的建议或解释为什么它这么慢。命令运行：

 rsync -a --info=progress2 user@sourceserver:/images/library/ /images/library

更新：
我使用 ssh + tar 测试了一个目录。 （而不是rsync）
我能够在55秒内传输24G，这是可以接受的。然后我应用到整个数据集。很快又恢复到之前提到的缓慢传输速度。
然后我停止传输并尝试单目录测试，并在55秒内达到了24G。
所以我编写了一个脚本来一次使用 tar + ssh 一个目录。前两个目录速度很快，但很快就变慢了。
我现在在最后检查的目录中花费了 20 分钟 17G。

这可能是 RAID 5 问题吗？

更新：我刚刚注意到的快速速度似乎是从页面缓存传输数据。 （从同一目录重新测试并删除），一旦我使用新目录，24G 的速度减慢到大约 3 分钟。但它似乎显示出写入潜力。

我认为问题可能出在源头。我尝试使用 ssh + tar 运行多个进程 (6)，但速度慢得像爬行一样。我尝试了 netcat，但它并不比 ssh + tar 快。目前最稳定、最快的方法是在脚本中使用 ssh(arcfour) + tar 迭代每个目录，中间有 3 秒的暂停。该方法在大约 6-7 分钟内产生了 35G 拷贝。
我注意到，到目前为止，两个晚上的午夜过后，传输时间几乎增加了一倍，并保持在这个速度，直到我停止脚本并重新启动。

顺便说一句：源文件系统是 xfs，目标文件系统是 ext4。抱歉帖子太长，但这似乎是一个很好的练习，可以找到传输 28TB 小文件的最快方法。

答案1

两点：

  • 首先，默认情况下，rsync 通过 SSH 工作。它是慢的。检查输出顶部或者顶部你可能会看到类似的东西：
    顶部 - 18:04:39 向上 113 天, 3:47, 3 位用户, 平均负载: 0,50, 0,59, 0,62
    Tâches：总共 489 个，4 个 en curs，485 个 en veille，0 个arrêté，0 个僵尸
    %Cpu(s)：40,7 ut、14,5 sy、0,0 ni、36,3 id、3,4 wa、0,0 hi、5,1 si、0,0 st
    MiB Mem：总计 7976,3，212,8 libr，2717,9 util，5045,7 tamp/cache
    MiB Éch：总计 8583,0，8381,2 libr，201,8 util。 4598,0 内存分配

      PID 实用程序。 PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM。                                                                                                             
    27262 伊曼纽尔 20 0 33956 7924 4204 R 58,3 0,1 0:21.51 ssh                                                                                                              
    31185 伊曼纽尔 20 0 52164 3208 2140 S 35,1 0,0 0:05.03 rsync                                                                                                            
    27249 伊曼纽尔 20 0 1340140 158896 45432 S 8,9 1,9 4:40.63 python2                                                                                                          
       52 根 20 0 0 0 0 R 6,3 0,0 9:51.41 kswapd0                                                                                                          
    25149 根 20 0 324716 126192 63120 S 2,0 1,5 25:26.24 Xorg                                                                                                             
    25679 伊曼纽尔 20 0 2555068 774108 100220 S 1,3 9,5 9:28.86 WebExtensions

注意到 rsync+ssh 是如何几乎完全耗尽一个 CPU 的吗？

  • 其次，我们不知道您的目标阵列的类型和速度；它的正常写入速度可能很糟糕，例如，如果它是禁用写入缓存的硬件 RAID 控制器。

如何获得更好的性能：

  • 对于初始副本不要使用rsync。严重地。同步很高兴，你知道，同步数据。但对于一个指向空目标的副本来说，这很糟糕。它比以前的好得多慢得多CP。所以我的建议是：通过 NFS 使用 cp并且您将最大限度地利用您的硬件（无论是最慢的部分、目标 RAID 或网络）。

  • 在目标服务器上，编辑/etc/出口:

    /mnt/raid *(rw、异步、no_root_squash、no_subtree_check)

启动 NFS：systemctl restart nfs-kernel-server

  • 在源计算机上，安装导出：

mount <server IP>:/mnt/raid /mnt/target

然后复制所有内容：

cp -av /mnt/source /mnt/target

最好使用屏幕或者多路复用器运行您的副本并避免意外（丢失 ssh 连接等）。

  • 替代解决方案：如果 NFS 不可用，或某些其他文件共享协议（CIFS/SMB、Fuse-FTP、WebDav...），那么最好的选择是使用网猫和这个结合柏油。重要的部分是不加密流量:

在目标机器上，运行网猫服务器：

cd /mnt/target ; nc -l -p 45724 | tar x

在源端，运行以下命令：

cd /mnt/source; tar cf - * | nc <target IP> 45724

答案2

您有很多核心和充足的网络带宽，所以我建议您并行化需求。多个rsync进程，每个进程处理文件集的不同部分。

答案3

结论是许多小文件是 rsync 传输速度慢的原因。

在这种情况下，流式传输方法会更有效，例如使用 ssh + tar

更新：实际上，就我而言，这是不正确的（并没有解决问题）。我在用作测试的目录上运行这些测试。有人指出这些可能在页面缓存中，所以我确保在新目录上再次测试，速度急剧下降。

答案4

我相信我们会得出结论，这是一个硬件问题。事实证明，该特定服务器在出厂时没有配备中间风扇组件。服务器配置中需要风扇，因为它包含一个护罩，可防止气流从 RAID 卡和其他部件中流出。需要风扇来解决这个问题。这可以解释为什么传输速度逐渐减慢。即使在闲置时，该卡也明显发热。此后，我们安装了中风扇组件，传输速度非常稳定在 30-40MB/s，在千兆网络上峰值为 120MB/s。希望我可以在 10G 上进行验证，但无法再访问。

相关内容