我以前从未见过或听说过这样的事情，而且我在网上找不到任何其他类似的东西。
我已经将网络升级到千兆位，并且最近一直在传输大文件（这个问题是一堆总计超过 200GB 的 DVD 映像）。每当我尝试复制一组几 GB 或更大的文件时，我都会注意到这种奇怪的行为，Mint 会将一大块数据加载到 RAM 中——通常约为 1.2 GB 或更小——有时只有几百兆—— - 然后开始传输。当它完成传输时，它实际上会停止传输，吐出旧的数据块，并等待继续传输，直到下一个数据块加载到 RAM 中。然后它将恢复通过网络传输。然后又重复。并重复。并重复。直到数据全部完成。
这是这些奇怪时刻之一的系统监视器的屏幕截图。
。您可以在 RAM 转储数据的精确时刻看到传输终止，然后在传输再次恢复的同一时刻看到 RAM 变平。同样有趣的是，我实际上有 6 GB RAM，而不是 Sys 的 3.2 GB。 Monitor会让你相信——这是Mint第二次突然没有报告此事。但这是另一天的问题。
这并不是世界上最糟糕的事情，但是当我使用过的所有其他操作系统在通过网络传输数据时同时将数据加载到 RAM 中或从 RAM 中加载出来时，这有点烦人。它不必停下来思考它。如果我能解决这个问题，那么在移动这些大量数据时会节省我的时间。
有什么建议、补救措施、诊断或理论吗？
答案1
Marco 的评论激励我尝试一些我没有想到的事情，然后我发现了答案。好吧，我想我发现了一个替代方案。如果有人对此有更多了解，请添加答案。
我应该事先指定如何传输文件。这是通过网络（当然）通过 WebDAV 连接到我的 Synology NAS 完成的。
在 Marco 发表评论后，我测试了使用几种不同的方法将大约 11.7 GB 复制到 NAS：
Samba：不仅平均速度快得多，而且没有等待数据加载的问题。
FTP：平均速度更快，传输不会停止等待数据加载到内存中，但有时 CPU 会变得有点有趣......我的意思是它最大化了其中一个核心，我不得不终止 FTP 进程，因为即使在我取消传输后，它仍然继续占用 CPU。
WebDAV：和以前一样——RAM 会抓取一堆数据，数据会传输，然后 RAM 会转储它并抓取更多数据，传输这些数据，等等。
所以我发现 Samba 在这种情况下是更好的方法。我做了一点谷歌搜索，发现有些人认为 WebDAV 是一种笨重的协议，尤其是对于 LAN。
不过，我不知道这是否就是 WebDAV 的方式——是否其他人也有同样的问题——或者 Mint 是否有问题，或者这只是我对 Mint 的特殊设置。所以我想我会在选择这个作为最佳答案之前几天给出这个，只是为了看看其他人是否有更好的解决方案/更多可以添加但我无法添加的内容。