主页 / unix / 问题 / 498364
Accepted
liori
Asked: 2019-02-03 16:24:24 +0800 CST

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

  • 772

在最近一次硬件迁移之后，我开始遇到奇怪的 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进程开始占用单个 CPU 内核的 100%（我后来从这个系统中删除了 dm_crypt，但仍然会发生停顿）。

  • 我观察/proc/meminfo并看到这个Dirty数字永远不会超过几兆字节。值得注意的是，在停顿期间，这个数字不会改变。

  • 在极少数情况下，我什至会收到一条内核消息，格式为“INFO：task «some process»blocked for more than 120 seconds.”，«some_process»通常是 mdX_raid5、chromium 或其线程之一等。示例日志.

/dev/sdd最初，我的设置只是单个 1TB 驱动器（当前）分区上的单个 600GB ext4 文件系统。然后我迁移到 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从来没有帮助过）。然后，一切停滞不前的东西突然又开始工作了。

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

  • 驱动器：三个都是希捷 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？）在必要时无法正确地将设备从某种低功耗模式中唤醒。

编辑：我不再可以访问这个系统，所以我不能再测试任何假设。我只能说，在运行该脚本后，我不再获得摊位。不过，我希望我知道如何调试它。

io delay

1 个回答

  1. Best Answer

    希捷 Skyhawk 型号在 6TB 型号上的“待机就绪”时间为 23-30 秒。1TB 型号的这个数字是 6 毫秒；在过渡到 2TB 的过程中，这个档位大大增加了。我怀疑您的驱动器正在切换到仅缓冲 I/O 的空闲状态，然后在您尝试写入它时停止，因为它正在旋转。

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

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

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

    • 1

相关问题