☰

问题

tag-icon • tag-icon encryption luks
问题

问题

我最近在联想 T460p 上安装了 Ubuntu 16.04 LTS（内核 4.8.0-52），该电脑配备 i7-6820HQ、32GB RAM 和 512GB Micron 1100 SSD。安装过程中我选中了全盘加密框并使用了默认分区布局。总体而言，性能很棒。

然而随着时间的推移，我的构建开始花费大约两倍的时间。此外，在构建过程中写入大文件的任何需要磁盘 I/O 的（非构建）任务最终都会等待很长时间。这包括启动新程序、在 Firefox 中加载页面等。例如，在 Firefox 中，我可以浏览 UI、切换选项卡，一切都很顺利。但如果我点击链接，整个 UI 就会锁定，直到一切平静下来。

总而言之，经过一段时间后，构建过程突然变得更长，并且在构建过程中的某些时间点，计算机基本上无法使用。

我可以做些什么来尝试诊断或解决这个问题？

故障排除信息

  • 不要经常重启，这样系统通常可以运行几天才会遇到这个问题。一旦遇到这个问题，我就会花点时间试图找出问题所在，然后重启，这样我就可以继续工作了。

  • 唯一能解决问题的办法是重启机器。我试过退出所有应用程序，注销并重新登录，并删除缓冲区缓存（理论认为，由于使用了内存空间，磁盘同步发生得更频繁），但只有重启才有效。

  • 作为一个长远的目标，我尝试了以下解决方案：这个答案但行为上没有任何改变。

  • 每当我遇到问题时，运行iotop都会显示线程使用了 99% I/O。当我dmcrypt_write不是遇到此问题时，我还看到dmcrypt_write弹出到顶部且 IO 百分比相对较高，但它不会在那里停留很长时间。

  • 如果我dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync在一切正常时运行，dmcrypt_write将会跳到顶部一两秒钟，但它的持续时间与我的一次构建期间的持续时间相差甚远。

  • 完整构建会生成大约 1.4 GB 的数据。这是一个包含多个模块的 Java 项目。因此，会创建大量小文件以及一些较大的 JAR 文件，这些文件会汇总所有这些小文件。

  • 总是有足够的内存可用，并且交换分区未被使用。

  • 我的同事也有类似的电脑（T460p），也运行 Ubuntu，但没有遇到此问题。他们似乎都遇到了不同的但是 SSD 品牌/型号。

更新

这个问题刚刚再次出现，所以我根据对这个问题的回答做了更多的测试。

  • 文件系统仍然没有使用该discard选项挂载，所以我改为运行，fstrim假设这有点类似于启用该discard选项
  • 当问题首次发生时，我没有进行足够的计时，但运行后fstrim，构建速度似乎恢复正常......但构建完成后，dmcrypt_write线程启动，使系统在一段时间内不可用。总的说来，构建和系统可用所需的时间似乎与以前大致相同。
  • 我将其改为/proc/sys/vm/dirty_ratio2 和/proc/sys/vm/dirty_background_ratio1，然后运行了一些构建。构建花费的时间比平时更长——与我上次遇到此问题时花费的时间差不多，但系统似乎没有那么频繁地锁定。将其改回 20 和 10 后，又恢复了上述行为。
  • 在干净启动时，我尝试设置/proc/sys/vm/dirty_ratio为 2 和/proc/sys/vm/dirty_background_ratio1，其时间与 20 和 10 相当。

答案1

我在 Debian 10+11 上遇到了类似的问题，如果我在 LUKS 磁盘上执行大量写入操作，我的整个系统会冻结一段时间，然后再次响应，然后再次冻结......

我不需要重新启动 - 只需等到写入操作完成即可。

正如 ScumCoder 所写，有一个可用的修复程序。从内核 5.9 开始，该修复程序已集成到内核中。

以下命令帮我修复了此问题：

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

我使用命令提取了我的磁盘名称“nvme0n1p3_crypt”dmsetup table

我从中得到灵感https://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

修复之后，我的写作操作快了很多。

答案2

我和你有完全相同的问题，快速研究表明了这篇文章：

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

CloudFlare 的员工对 Linux 源代码进行了深入研究，并得出结论，罪魁祸首是当前的dmcrypt实现。他通过重写内核的相应部分解决了这个问题。

因此，据我所知，消除速度减慢的唯一两种方法是 (1) 编译他的内核版本，或 (2) 偶尔重启（如您所说）。我选择了后者。

答案3

不知道 LUKS 的具体情况，但对于 SSD 上的一般 IO 问题，请确保为您的 fs 挂载启用了丢弃，即 grep discard /proc/mounts 也可以尝试（作为 root）“echo 1 >> /proc/sys/vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio”，当要写出的积压数据较少时，这将使系统更快地启动 IO。

相关内容