有没有比cp更快的替代方法来复制大文件（〜20 GB）？

我是一名研究生，我所在的小组维护着Linux集群。群集的每个节点都有自己的本地磁盘，但是这些本地磁盘相对较小，没有自动备份。因此，该组拥有一个具有许多TB存储空间的文件服务器。我是Linux的相对新手，所以我不确定文件服务器在速度，网络能力等方面的规格是什么。我确实从经验中知道本地磁盘在I / O方面比文件服务器快得多。大约有十几个人使用文件服务器。

使用cp〜20 GB的文件从文件服务器复制到本地磁盘之一平均需要大约11.5分钟的实时时间（根据time）。我知道此cp操作的效率不是很高，因为（1）time告诉我该副本的系统时间仅为〜45秒；并且因为（2）top在复制期间进行检查时，％CPU相当低（通过检查，平均大约为0-10％）。

使用cp将大约20 GB的文件从本地磁盘上的一个文件夹复制到同一本地磁盘上的另一个文件夹所花费的时间更少-实时约为9分钟（根据，系统时间约为51秒time）。因此，显然文件服务器比预期的要慢于本地磁盘，但可能不会慢很多。我很惊讶从本地复制到同一本地的速度不超过9分钟。

我需要将大约200个大文件（每个〜20 GB）从文件服务器复制到本地磁盘之一。因此，我的问题是：在Linux中复制大文件是否有更快的选择cp？ （或者cp我可以使用任何标记来加快复制速度吗？）即使我能以某种方式节省一分钟的复制时间，也将极大地帮助您。

我确定要购买新的，速度更快的硬件磁盘，但是我无法访问这些资源。我也不是系统管理员，我只是一个（新手）用户，所以我无法访问有关磁盘负载的更多详细信息。我确实知道，虽然每天有大约十二个人使用文件服务器，但我是唯一使用此特定节点/本地磁盘的人。

复制期间，％CPU 应当为低。CPU告诉磁盘控制器“将数据从扇区X–Y抓取到Z的内存缓冲区”。然后它继续执行其他操作（如果没有其他操作，请睡觉）。当数据在内存中时，硬件触发中断。然后，CPU必须复制几次，然后告诉网卡“在内存位置A，B和C传输数据包”。然后又回到做其他事情。

您正在推动〜240mbps。在千兆局域网上，您应该至少能够做到800mbps，但是：

1. 使用文件服务器的每个人（以及交换机之间的连接等）都可以共享。
2. 这受文件服务器处理写入速度的限制，请记住，使用它的每个人都共享其磁盘I / O带宽。
3. 您没有指定访问文件服务器的方式（NFS，CIFS（Samba），AFS等）。您可能需要调整网络安装，但是在最近的任何情况下，默认设置通常都非常合理。

为了追踪瓶颈，iostat -kx 10这将是一个有用的命令。它会告诉您本地硬盘上的利用率。如果可以在文件服务器上运行该文件，它将告诉您文件服务器的繁忙程度。

通用的解决方案是加快瓶颈，这当然是您没有预算的。但是，在几种特殊情况下，您可以找到一种更快的方法：

• 如果文件是可压缩的，并且您具有快速的CPU，则在运行中进行最小限度的压缩可能会更快。类似lzop或可能的东西gzip --fastest。
• 如果仅在此处和此处更改一些位，然后再发送回文件，则仅发送增量会更快。不幸的是，rsync这里并没有真正的帮助，因为它将需要读取文件的两侧以找到增量。相反，您需要在更改文件时跟踪增量的内容。这里的大多数方法都是特定于应用程序的。但是可能您可以使用device-mapper（请参阅全新的dm-era target）或btrfs进行设置。
• 如果要将同一数据复制到多台计算机，则可以使用udpcast之类的内容一次将其发送到所有计算机。

而且，由于您注意到您不是系统管理员，所以我想这意味着您拥有系统管理员。或至少有人负责文件服务器和网络。您可能应该问问他/她/他们，他们应该更加熟悉您的设置细节。您的系统管理员应该至少能够告诉您可以合理预期的传输速率。

这可能是一种更快的替代方法，并且您两天都不会阻塞网络：取一个或两个大USB（如果有USB 3，则为USB 3）或FireWire磁盘，将其连接到服务器并将文件复制到磁盘。将磁盘运送到本地计算机。将文件复制到计算机上。

您对效率的定义是落后的。实施效率更高，浪费的CPU时间更少。在本地副本上，您平均大约有74 MB / s的吞吐量（读+写），这与单个硬盘的吞吐量差不多。

如果您具有直接SSH（或SFTP）访问权限（请咨询系统管理员），则可以将其scp与压缩（-C）结合使用：

scp -C you@server:/path/to/yourfile .

当然，这仅在文件可压缩的情况下才有用，这将占用更多的CPU时间，因为它将使用加密（因为它是通过SSH）并进行压缩的。

该cp实现很可能不是瓶颈。尝试通过iotop服务器和群集节点上的IO使用情况进行观察。这将为您提供一个可以改善性能的想法。

另一个技巧是避免从同一主机复制相同的数据。例如，如果您有相同的20G文件要通过网络从文件服务器分发到所有群集节点，则与以对等方式而不是从一台服务器到所有客户端复制文件相比，它的工作速度要快得多。实现起来有点复杂，但是您甚至可以尝试使用一些命令行p2p，例如直接连接集线器。

如果在该20G文件中，某些部分是公共的，而某些部分是特定于群集节点的，请考虑将其分为公共部分和特定部分，然后以p2p方式分发公共部分。

这些文件的性质/内容可能有所不同。我知道您需要从一台计算机复制200个文件（每个文件约20 GB），是吗？

如果这些文件是可压缩的或具有相似/相同的片段，则有两种方法：

• 在复制之前将其压缩，或在启用zip的计算机之间创建隧道。因此，如果网络是瓶颈，速度会更快

• 如果文件非常相似，或者它们之间共享一些共同的内容，请尝试使用rsync。它将花费一些时间来查找文件之间的共同点，并且不需要按字面意义进行复制，因为它将基于共同点来重建它。

编辑

您是否需要多次复制这些文件？（例如，复制->使用这些文件->在计算机A中更改文件中的某些内容->将文件再次复制到计算机B中）

如果是这样，rsync会有所帮助，因为它将尝试检测版本之间的相等，而不复制未更改的内容。

第三种方法：如果以上正确（文件更改，然后将所有文件再次复制到第二台计算机），则可以尝试binary diff更改第二台计算机中第一台计算机中所做的更改。

我在这里看到以下内容，加密不是一个好主意，因为它可能会增加要传输的数据量。

如果要在两个系统之间进行复制，则瓶颈当然是服务器之间的连接。

如果要在本地复制，请查看进程如何进行，它是单线程的，因此标准Linux实用程序使用：

- for all blocks in a file
      read a block
      write a block

此操作没有并发。

为了加快速度，您可以使用以下方法：

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

有关更多信息，请参见buffer（1）手册页。

buffer命令设置了两个进程来同时运行复制过程：一个进程用于读取，另一个进程用于写入，它使用共享内存缓冲区在两个进程之间传递数据。共享内存缓冲区是经典的循环缓冲区，它可以防止覆盖未写入的数据和写入已写入的数据。我已经使用此程序减少了从磁盘到磁带的传输中大约10-20％的复制时间。

如果您需要同时更新整个集群，为什么不尝试P2P传播算法呢？

https://github.com/lg/murder是Twitter使用的

有BTSync，你可以尝试为好。

如果您要频繁地将同一组文件从本地计算机复制到服务器，而在此处和此处进行较小的更改。您可以使用rsync或DVCS（例如hg或git）加快传输速度。

git或hg可以跟踪并检测增量，并且仅传输这些增量。在使用git的情况下，由于双方都有存储库的完整历史记录，因此找出增量非常便宜。

rsync使用一种形式的滚动校验和算法来检测增量，而无需事先了解另一端的情况。尽管rsync需要更多工作来计算增量，但并不需要存储整个文件历史记录。

您可能想要尝试将所有文​​件打包到一个存档中（不需要压缩）。以我的经验，复制一个存档比复制大量单个文件要快

尝试bbcp。在我们的环境中进行的测试表明，cp具有某种内置的调控器。请小心，因为当您卸下调速器时，您可能会为服务器加红线并造成中断。在我们的案例中，我们使服务器脱机以进行复制，因此速度越快越好。这样可以将传输时间缩短几个小时。

复制之前，请确保目标文件不存在。

有时甚至仅在同一主机上进行复制（不涉及网络）也要花费多少时间却令人惊讶。

在这里查看我对另一个CP问题的回答。长话短说，覆盖现有文件比截断或先取消链接然后复制要慢得多。对于1.2GB的文件，后者快8倍。