У нас действительно странная ошибка, из-за которой операционная система Yocto, работающая на Raspberry Pi, «зависает» из-за ожидания дискового ввода-вывода.
Сценарий:
- операционная система работает только для чтения и не имеет свопа
- существует файловая система tmpfs для вещей, которые должна записывать ОС (/var, /log и т.д.)
- tmpfs по умолчанию имеет половину доступных 2 ГБ ОЗУ.
- подключен жесткий диск USB для хранения больших файлов MP4
Через некоторое время после запуска программы Python, взаимодействующей с USB-ускорителем Google Coral, вывод вершина является:
Таким образом, нагрузка на ЦП огромна, но загрузка ЦП низкая. Мы считаем, что это связано с ожиданием ввода-вывода на жесткий диск USB.
В других случаях мы увидим еще более высокое использование кеша:
Мем: 1622744 КБ использовано, 289184 КБ свободно, 93712 КБ уничтожено, 32848 КБ усилено, 1158916 КБ кэшировано
CPU: 0% usr 0% sys 0% nic 24% простоя 74% io 0% irq 0% sirq
Средняя нагрузка: 5,00 4,98 4,27 1/251 2645
Файловая система выглядит вполне нормально:
root@ifu-14:~# df -h
Используемый размер файловой системы Доступное использование % Установлено на
/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,6 млн 48,6 млн 884,9 млн 5% /запуск
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/кэш
/dev/mmcblk0p1 39,9 млн 28,0 млн 11,9 млн 70% /uboot
/dev/mmcblk0p4 968,3 млн 3,3 млн 899,0 млн 0% /данные
/dev/mmcblk0p4 968,3 млн 3,3 млн 899,0 млн 0% /etc/имя хоста
/dev/mmcblk0p4 968,3 млн 3,3 млн 899,0 млн 0% /etc/NetworkManager
/dev/sda1 915.9G 30.9G 838.4G 4% /mnt/sda1
Когда все это «зависает», мы замечаем, что жесткий диск USB полностью не отвечает (лс ничего не делает и просто зависает).
В журналах dmesg мы заметили следующие строки (вставлены как изображение для сохранения цвета):
Вот полный вывод dmesg после того, как мы начали получать эти ошибки:
https://pastebin.com/W7k4cp35
Мы предполагаем, что когда программное обеспечение, работающее в системе, пытается что-то сделать с большим файлом (более 50 МБ) (перемещая его на жестком диске 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 потребовать изменения этого? Может кто-нибудь объяснить, что происходит?
