☰

复制大量数据时传输速率降低

tag-icon • tag-icon hard-drive performance transfer iowait
复制大量数据时传输速率降低

我使用的是 Ubuntu 16.04.3 LTS 系统（4.10.0-40-generic），有两个硬盘，每个磁盘上有几个分区。当我在两个磁盘之间复制数据（<5GB）时，传输速率约为 70 MB/s。但是，当我尝试将大量数据（>30GB）从一个磁盘复制到另一个磁盘时，我注意到几个性能问题。

我的问题是，这种行为是否正常，在 Linux 系统中是否可预料到？
有人能向我解释一下，并建议我如何避免这种性能下降吗？

下面我将描述我的观察结果。在示例中，我将 54GB 的磁盘映像文件从 sda8（325 GB 分区）复制到 sdb8（1.6TB 分区）

1）传输速率降低，iowait增加
当我尝试复制超过 50 GB 的数据时，我注意到传输速率逐渐降低。我使用 Glances、atop、iotop 和 iostat 监控性能。在 30GB 的进度中，传输速率已降至 58 MB/s，在 46GB 时降至 36MB/s，在 52GB 时降至 12 MB/s。此后，传输速率开始真正波动并降至 1MB/s 以下。同时，我看到 iowait 从最初的 0% 增加到最后的 62%。在复制期间，磁盘 sd8 的“繁忙”百分比在 40% 到 60% 之间。磁盘 sdb 一直处于 100% 繁忙状态。不仅传输速率下降，而且我的系统响应也变得迟钝。我预计 iowait 是导致这种情况的原因。
这是正常现象吗？如何避免性能下降？

2）复制后 IOwait 保持高位
复制结束后，我注意到 iowait 仍然很高，并逐渐开始降至正常值。这需要几分钟。我认为在此期间，数据仍以大约 1 或 2 MB/s 的速率写入 sdb。使用 iotop 看起来是进程“jdb2/sdb4-8”导致了此磁盘写入。在 IOwait 减少期间，我的系统仍然响应不良。还看到磁盘 sda 不再繁忙，但磁盘 sdb 仍然以 100% 繁忙运行。是
什么导致我的系统在复制操作后的几分钟内响应不良？
可以避免这种情况吗？

3）从网络驱动器复制可增强效果
当我尝试将数据从 Synology NAS 复制到本地磁盘 (sdb8) 时，效果更差。首先将网络驱动器安装到我的系统，然后开始复制。最初传输速率也达到 70MB/s，但传输速率下降得更快。几 GB 之后，传输速率已远低于 1 MB/s。尝试使用 Nautilus 的拖放、命令“cp”、命令 rsync、FreeFileSync 应用程序进行复制，但所有复制都显示性能不佳。
使用网络驱动器时性能下降效果更差的原因可能是什么？

附加信息
复制过程中使用“iostat -dx 5”监控磁盘性能，大约5GB的复制进度监控显示：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00  530,40    0,00 68064,80     0,00   256,65     1,62    3,06    3,06    0,00   1,63  86,72
sdb               0,00 18767,20    0,20  112,40    23,20 73169,60  1300,05   144,32 1345,39  308,00 1347,23   8,88 100,00

当复制进度到 52 GB 左右时，会显示：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   64,60    0,00  8268,80     0,00   256,00     0,22    3,41    3,41    0,00   1,76  11,36
sdb               0,00  1054,40    0,20   10,60     6,40  6681,60  1238,52   148,56 9458,00    0,00 9636,45  92,59 100,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   50,20    0,00  6425,60     0,00   256,00     0,16    3,09    3,09    0,00   1,64   8,24
sdb               0,00  2905,80    0,40   17,00     8,80 10289,60  1183,72   141,86 10199,77  652,00 10424,42  57,47 100,00

我意识到这些是多个问题，但我怀疑这些都与同一原因有关，并希望有人可以向我澄清这一点。

答案1

不幸的是，对于您的大文件用例来说，这是正常的，也是意料之中的。您的两个硬盘和一个 50GB 以上的文件的情况消除了许多关于“慢速设备”、“慢速总线”和“慢速文件系统”的误导性说法，而您只剩下无法解释的复制速度慢的问题。您必须拥有相当多的内存才能获得 30GB 文件的性能。系统缓冲区被使用、填满，并且在复制命令完成后，最终将被刷新到目标，这使得实际计时/速率有些困难（即使“时间”命令也会在缓冲区最终刷新之前很久完成。

我发现的唯一“解决方法”是使用“copy”命令，它允许您自己设置显式缓冲区，就像 tar 或 cpio 可以做到的那样。在 tar 上设置 2MB 缓冲区允许我将 50G 文件的 10MB/秒复制速度提高到大约 35MB/秒——仍然比我在较小文件（或在 Windows 中）上获得的标称 100MB/秒慢得多。

另一个可能更好的解决方法是安装 nocache 包并使用 nocache cp 文件目标来限制填充系统缓冲区和拖慢系统速度。将 43G 文件复制到 /dev/null 的速度为 53MB/秒，比 tar 复制的大缓冲区更好。

某些使用叠瓦式磁记录 (SMR) 的磁盘在进行大量写入时会变得非常慢。如果您的复制速度非常慢，但仍有大量可用内存缓冲区，则这可能是原因。

特定情况可能会通过设置 swappiness、vm_dirty 字节/比率、renice、ionice、nocache、预分配文件空间、调度等来帮助解决，但基本问题仍然是，如果没有足够的可用内存，系统就无法正常工作。

看启动板错误 1208993并将自己添加到“这会影响我吗？”列表中。

相关内容