我的主台式机有 64GB RAM。这似乎会导致在文件复制或网络传输等磁盘密集型操作期间脏写缓存经常超过 10GB。 （我通过观察传输之前Dirty的值/proc/meminfo（0 或非常接近它）以及传输期间的值（超过 10GB）来收集此值）我从 SSD 启动，但在外部硬盘驱动器上处理大量数据传输。一个示例外部驱动器的平均写入速度可能约为 100MB/秒，但我通过 10Gbit 网络连接到基于 ZFS 阵列的 NAS，因此通过 LAN >400MB/秒的带宽很常见。
这样做的问题是，如果我正在处理多任务，并且另一个任务执行一个sync操作（一个例子是我认为apt或dpkg类似的sync在完成之前执行一个操作），它可能会使整个过程挂起几分钟。此外，写入过程仍在写入，因此同步可能需要比清空脏缓存的时间更长的时间。这在系统的其他方面也很明显——传输过程中应用程序会出现随机滞后和挂起。
即使对于硬盘来说，10GB 的写入缓存也是相当大的。对于我的 NVMe 启动 SSD 来说，情况可能还不错，可以实现 >1GB/秒写入，但在相对较慢的硬盘上，假设没有发生新写入，可能会导致同步时间超过 2 分钟。如果正在发生非常大的传输，我会看到同步命令停滞超过 10 分钟！
有什么方法可以告诉 Linux 内核限制给定设备可以发送的数据量吗？ （例如，如果我可以告诉内核在强制数据开始刷新到磁盘之前只允许 512MB 的数据进入缓存，这将极大地帮助这种情况。） 如果做不到这一点，我也许可以忍受降低系统范围写缓存，但也不知道该怎么做。
答案1
每设备写入缓存尚未实现，您所说的问题是众所周知的，我在五年前就说过：为什么 2013 年会出现“U 盘失速”问题？为什么现有的“无 I/O 脏节流”代码没有解决这个问题？
我还有 64GiB 的 RAM，这就是我自己解决这个问题的方法：
cat /etc/sysctl.d/dirty.conf
# Per Torvalds advice
vm.dirty_background_bytes = 33554432
vm.dirty_bytes = 134217728
它可能会使某些操作运行得慢一点，但它会解决您的问题。