当我将文件复制到 USB 设备（相机、硬盘、存储卡）或从 USB 设备复制文件时，我的系统变得非常慢。例如，如果我想关闭一个窗口，我会移动鼠标，但鼠标光标移动大约需要 2 秒或更长时间。当我最终将光标移到 x 上并单击它时，10 多秒内没有任何反应。我已经在禁用所有桌面效果的情况下尝试过此操作，但问题仍然存在。
软件：Linux Mint 9 KDE 硬件：
- 华硕SLI主板
- 英伟达 6600 GPU
- 2 GB 内存
- 2 GB 交换
- AMD Athlox X2 @ 3800+
对我来说，这个硬件在运行这个软件时应该不会有任何问题，直到我使用 USB 复制文件时才会出现问题。我应该从哪里开始寻找解决这个问题的方法？我认为图形驱动程序可能是问题的一部分，但我不确定。
答案1
似乎有一个linux内存管理中的大页问题。这种情况很少发生，但听起来你已经观察到了。
原因
这是我对这篇文章所发生的事情的极其简化的描述。
如果不幸的话，进程在发出内存访问时就会陷入困境。这是因为当启用透明大页时，内存访问可能会触发同步压缩（主内存碎片整理），同步意味着内存访问不会在压缩之前完成。这本身并不是一件坏事。但是，如果写回（例如，将缓冲数据写入 USB）恰好同时发生，则压缩可能会停止，等待写回完成。
因此，任何进程都可能最终等待慢速设备完成写入缓冲数据。
治愈
正如OP所做的那样，升级主内存可能有助于延迟问题的发生。但对于那些不认为这是一种选择的人来说，有两种明显的解决方法。两者都涉及重新编译内核：
答案2
这听起来与我在这里的问题相似（其中的答案向我指出了这个问题）：
但理论完全不同，我使用的解决方案与你的无关，但效果很好。
我使用的是 rsync，所以我所要做的就是使用 --drop-cache 选项。 （这会导致复制速度变慢，作为副作用）
答案3
我发现唯一真正有效的技巧： Gnome、nautilus 将文件复制到 USB 停止在 100% 或附近
如果您想尝试一些高级用户技巧，您可以通过将 /proc/sys/vm/dirty_bytes 设置为 15728640 (15 MB) 之类的值来减小 Linux 使用的缓冲区大小。这意味着应用程序无法提前获得超过 15MB 的实际进度。
一个副作用是，使用此设置，您的计算机可能具有较低的数据写入吞吐量，但总的来说，我发现看到程序在写入大量数据时运行很长时间，而不是在写入大量数据时感到困惑，这很有帮助。程序似乎已经完成了它的工作，但是当内核执行实际工作时，系统严重滞后。将 dirty_bytes 设置为相当小的值还可以帮助防止系统在可用内存不足并运行突然写入大量数据的程序时变得无响应。
但是，不要设置太小！我使用 15MB 作为粗略估计，内核可以在 1/4 秒或更短的时间内将缓冲区刷新到普通硬盘驱动器。它使我的系统不会感到“滞后”。