☰

奇怪的 I/O 停顿影响整个桌面

tag-icon • tag-icon io delay
奇怪的 I/O 停顿影响整个桌面

最近的硬件迁移后，我开始遇到奇怪的 I/O 停顿，影响我的桌面 Debian Stretch 系统。典型症状，都发生在每个摊位期间：

  • 我无法与我的网络浏览器 Chromium 交互。没有任何效果：网页滚动（通常这是我注意到停顿的方式）、切换选项卡等。无论是在网页上还是在 Chromium UI 上，也没有鼠标悬停操作。

  • 在虚拟终端中，我无法再运行新进程。例如，我打开一个新选项卡mate-terminal，但我的 shell 没有显示，只是光标闪烁。在停止之前打开 shell 的终端中，我可以键入命令，但通常它不会启动；sudo something甚至不要求输入密码。

  • 其他程序（例如 RStudio）无法将任何内容保存到磁盘，并且在尝试保存时经常挂起。

  • 我在日志中看到，journald -f如果停顿足够长，journald它会自行重新启动，例如：

      sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart.
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage.
  sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage...
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service.
  sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service...
  sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started
  sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.

  • 当使用 dm_crypt 时，一个dmcrypt_write进程开始占用 100% 的单个 CPU 核心（我后来从这个系统中删除了 dm_crypt，但停顿仍然发生）。

  • 我观察/proc/meminfo发现这个Dirty数字永远不会超过几兆字节。值得注意的是，在失速期间，这个数字不会改变。

  • 在极少数情况下，我什至会收到“信息：任务“某个进程”阻塞超过 120 秒”形式的内核消息，其中“某个进程”通常是 mdX_raid5、chromium 或其线程之一等。日志示例。

最初，我的设置只是单个 1TB 驱动器（当前）的分区上的单个 600GB ext4 文件系统/dev/sdd。然后我迁移到 3×6TB 驱动器 ( /dev/sd{b,c,e})，使用基于 LVM 的 raid5、bcache（其缓存位于 SSD 驱动器上），然后是 dm_crypt — 这就是停滞开始的时候。在调试过程中，我简化为只有LVM-raid5，没有bcache或dm_crypt；摊位仍然会发生，尽管我觉得现在不那么频繁了。

这种失速每天会发生几次，通常会持续几分钟。我注意到我可以通过显式请求某些磁盘操作来破坏它：有时我可以通过从远程计算机通过 ssh 登录到该系统来破坏它，或者（几乎总是）通过cat /dev/sdb >/dev/null或cat /dev/sdc >/dev/null（有时一个，有时另一个有效） ; 特别是从来cat /dev/sde >/dev/null没有帮助）。然后，一切停滞的事情突然又开始运转。

所以我怀疑问题是由以下之一或相互作用引起的：

  • 硬盘：这三个硬盘均为 Seagate Skyhawk ST6000VX0023。其中两个在此设置之前未使用过，第三个使用了半年（/dev/sdc）。
  • 磁盘控制器： 主板：Gigabyte Z68X-UD3H-B3有两个控制器：Marvell 88SE9172其中一个驱动器连接到芯片组内置控制器 ( Intel® Z68) 以及另外两个控制器（我可以在软件中检查哪一个在哪里吗？）。
  • 控制器内核驱动程序中的一些错误。
  • LVM 或 raid5 中的一些错误。

这是一个 Debian Stretch 系统，安装了一些向后移植的软件包，最引人注目的是 kernel 4.19.0-0.bpo.1-amd64。英特尔酷睿 i7-2600k，16GB 内存。

此时我已经没有主意了。如何进一步调试这个问题？

编辑：我启动了一个脚本，每 4 秒从这些驱动器之一读取一个随机扇区，并且现在已经 2 天没有停顿了。因此，确实看起来某些系统组件（LVM？raid？）在必要时无法正确地将设备从某种低功耗模式中唤醒。

编辑：我不再有权访问此系统，因此我无法再测试任何假设。我只能说，运行该脚本后，我不再遇到停顿。不过，我希望知道如何调试它。

答案1

在 6TB 型号上，Seagate Skyhawk 型号的“待机到就绪”时间为 23-30 秒。 1TB 型号的该数字为 6 毫秒；在过渡到 2TB 的过程中，停顿显着增加。我怀疑你的驱动器正在切换到空闲状态，仅缓冲 I/O，然后当你尝试写入它时，它会在旋转时停止。

该驱动器支持 4 种电源管理模式：活动、空闲、待机和睡眠。手册中的相关部分说:

“每次驱动器执行活动功能（读、写或寻道）时，待机计时器都会重新初始化，并开始从指定的延迟时间倒计时至零。如果在需要任何驱动器活动之前待机计时器达到零，则驱动器将使转换到待机模式 在空闲和待机模式下，驱动器接受所有命令，并在需要磁盘访问时返回活动模式。”

从 Linux 内部更改电源管理模式以消除待机模式是一件痛苦的事情。驱动器供应商为此类事情提供了实用程序，但通常他们需要启动其 ISO 或使用仅限 Windows 的实用程序。我在使用 hdparm 调整待机超时方面取得了一些成功；这是一个入门教程。

相关内容