主页 / server / 问题 / 1069740
Accepted
jakew009
Asked: 2021-07-16 10:21:11 +0800 CST

了解没有交换的只读文件系统上的 buff/cache 和 tmpfs 关系

  • 772

我们有一个非常奇怪的错误，在 Raspberry Pi 上运行的 Yocto 操作系统会因为磁盘 IO 等待而“锁定”。

设想：

  • 操作系统以只读方式运行，没有交换
  • 有一个 tmpfs 文件系统，用于存储操作系统需要写入的内容（/var、/log 等）
  • tmpfs 默认为可用 2GB RAM 的一半
  • 有一个 USB 硬盘驱动器连接用于存储大型 MP4 文件

在运行与 Google Coral USB 加速器交互的 Python 程序一段时间后，输出top为：

top 命令的输出

因此 CPU 负载很大，但 CPU 使用率很低。我们认为这是因为它正在等待 IO 到 USB 硬盘。

其他时候我们会看到更高的缓存使用率：

Mem: 1622744K used, 289184K free, 93712K shrd, 32848K buff, 1158916K cached
CPU:   0% usr   0% sys   0% nic  24% idle  74% io   0% irq   0% sirq
Load average: 5.00 4.98 4.27 1/251 2645

文件系统看起来相当正常：

root@ifu-14:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.1G    528.1M      2.4G  18% /
devtmpfs                804.6M      4.0K    804.6M   0% /dev
tmpfs                   933.6M     80.0K    933.5M   0% /dev/shm
tmpfs                   933.6M     48.6M    884.9M   5% /run
tmpfs                   933.6M         0    933.6M   0% /sys/fs/cgroup
tmpfs                   933.6M     48.6M    884.9M   5% /etc/machine-id
tmpfs                   933.6M      1.5M    932.0M   0% /tmp
tmpfs                   933.6M     41.3M    892.3M   4% /var/volatile
tmpfs                   933.6M     41.3M    892.3M   4% /var/spool
tmpfs                   933.6M     41.3M    892.3M   4% /var/lib
tmpfs                   933.6M     41.3M    892.3M   4% /var/cache
/dev/mmcblk0p1           39.9M     28.0M     11.9M  70% /uboot
/dev/mmcblk0p4          968.3M      3.3M    899.0M   0% /data
/dev/mmcblk0p4          968.3M      3.3M    899.0M   0% /etc/hostname
/dev/mmcblk0p4          968.3M      3.3M    899.0M   0% /etc/NetworkManager
/dev/sda1               915.9G     30.9G    838.4G   4% /mnt/sda1

当它全部“锁定”时，我们注意到 USB 硬盘驱动器因为完全没有响应（ls什么都不做，只是冻结）。

在 dmesg 日志中，我们注意到以下几行（粘贴为图像以保留颜色）：

dmesg 输出

这是我们开始收到这些错误后 dmesg 的完整输出： https ://pastebin.com/W7k4cp35

我们推测，当系统上运行的软件尝试对一个大文件 (50MB +) 执行某些操作时（在 USB 硬盘上移动它），不知何故，系统内存不足。

我们真的不确定我们到底是如何进行的。我们发现了这个博客：https ://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/哪一种看起来像同样的问题和建议修改vm.dirty_ratio和vm.dirty_background_ratio以更频繁地将缓存刷新到磁盘。

这是正确的方法吗？

当前设置是vm.dirty_ratio = 20和vm.dirty_background_ratio = 10

相对较慢的 USB 硬盘驱动器是否需要更改？有人可以解释发生了什么吗？

filesystems linux-kernel embedded-linux

2 个回答

  1. Best Answer
    [sda] tag#0 timing out command, waited 180s
blkupdate_request: I/O error, dev sda1
INFO:  task jbd2/sda1 blocked for more than 122 seconds.

    块设备 /dev/sda 失败。替换它并恢复数据。

    Linux 的任务被阻止警告是指任务在几分钟内没有进展。对于计算机，甚至是存储系统来说，这都是永恒的。触发不正常的 I/O 问题。要么存储出现故障，要么存在大量的争用，要么资源严重匮乏。由于其他消息包含 I/O 错误的证据，因此前者似乎很可能。

    如果存储已被替换，则该模型可能速度较慢且不适合此应用程序。尝试使用高性能 SSD，例如 USB 3 适配器中的 NVMe 或类似设备。

    还想出一个综合负载测试来像应用程序一样运行存储，并获得一些性能数据。小的随机写入，长的顺序写入，也许是混合的。在 Linux 上，fio是一个非常灵活的 I/O 测试器。

    最后，其他硬件组件可能出现故障。作为一个 Raspberry Pi，尝试更换整个东西。

    • 3

  2. 作为对这个问题的更新，这里以前的答案几乎都是钱。

    事实上，问题在于 Raspberry Pi 4 无法从其 USB 端口提供足够的电力来长时间同时驱动 USB 硬盘驱动器和 Google Coral。一段时间后，USB 硬盘驱动器根据上面的日志开始表现得非常奇怪，这使它看起来像是失败了。

    切换到 SSD 使问题立即消失。

    • 1

相关问题