☰

如何对 Linux 磁盘 IO 系统范围内的“挂起”进行分类

tag-icon • tag-icon linux ubuntu linux-kernel btrfs ubuntu-20.04
如何对 Linux 磁盘 IO 系统范围内的“挂起”进行分类

我有一个盒子，它会定期“出去吃午饭”。症状是任何需要实际磁盘 IO 的东西都会挂起 30 多秒，而且似乎任何已经分页的东西都不会受到影响。问题间歇性地发生（每小时最多几次），到目前为止还没有追溯到任何正在运行的程序或用户行为。现在重新映像盒子会造成很大的干扰，所以我希望隔离问题并希望证明这是不必要的。带有 btrfs-on-luks nvme 根文件系统的 Ubuntu 20.04 系统。

用户描述 + 日志分析（dmesg和journalctl）未显示与该问题相关的任何行为，除了 10 秒后出现的与 io 超时相关的消息，这些消息似乎明显是症状/后果。该盒子在几个月前重新镜像之前，已经在 ubuntu 20.04 上使用（未发现此问题的实例）约 6 个月，所以我有一个小数据点，即问题不是硬件故障。 btrfs scrub并且 biossmart没有报告任何错误。

在复制过程中使用iotop -o实时功能，我可以看到，除了几个内核线程外，磁盘的实际吞吐量下降到~0 [kworker/.*events-power-efficient]。

请推荐下一步措施来分类/隔离 IO 挂起的原因。

按要求智能输出：

#> smartctl -a /dev/nvme0n1` as requested:
[...]
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        33 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    4,339,623 [2.22 TB]
Data Units Written:                 7,525,333 [3.85 TB]
Host Read Commands:                 23,147,319
Host Write Commands:                69,696,108
Controller Busy Time:               1,028
Power Cycles:                       98
Power On Hours:                     3,996
Unsafe Shutdowns:                   25
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

按照@anx 的建议使用netdata，我越来越接近了：内核内存中的以下症状似乎与我所看到的所有情况下的重现 100% 相关。在约 1 分钟内，内核分配了不可回收的内存 ~双打。在分配所有这些期间，~所有 IO 都挂起。IO 有时会在下坡时解除阻塞，因为内存正在被释放。中央峰值/倍增非常一致，前后较小的峰值略有不同。

内核内存使用量突然增加一倍，然后以相同的速率恢复正常

此外，这种行为每小时都会（间歇性地）发生一次： 在此处输入图片描述

正在对每小时运行的 cron 和 systemd 任务进行盘点。查看是否有可以启用的调试日志记录，因为今天日志中这些时间没有任何可疑内容。

答案1

模式（什么时候是否会发生降解？）以及相关指标（在性能下降过程中，是否有任何其他指标急剧下降/飙升？）通常是识别问题的最快途径扳机。

即使触发器不是造成问题的原因（例如，如果系统因内存压力而停滞，但机制为什么虽然这样做会更加复杂，但拥有可靠的复制方法是很有帮助的，这样你就可以获得更多的数据。

分类步骤：

  1. 使用类似工具netdata来直观地确定模式和/或相关指标。当问题发生时，性能指标是否发生了什么变化？最有帮助的指标可能出现较早而不是性能下降 - 你看到的问题很可能是恢复某些驱动程序或程序行为异常的阶段。
  2. 如果您无法发现触发因素，从而无法故意重现，您仍然可以找到一种确定问题何时再次发生的方法（例如，在下一次大磁盘写入时，每天 12:00，...）
  3. top计划任务可确保您在事件期间（例如甚至）获取相关系统状态的快照（或每 X 个时间单位一次）echo t >/proc/sysrq-trigger ; dmesg。手动运行计划任务至少一次，以便缓存其依赖项

常见解释的想法：

  1. 交换配置错误或交换文件位于某些不合适的块设备堆栈上
  2. 硬盘损坏，不一定是包含根文件系统的硬盘
  3. 一些遗留的调试任务，例如在 cronjob 中删除缓存
  4. 数据库在执行日常任务时会消耗大量内存或访问大量目录
  5. SSD 修剪（discard），或缺少修剪，再加上大量写入，导致系统等待磁盘完成

相关内容