Avem o eroare cu adevărat ciudată în care un sistem de operare Yocto care rulează pe un Raspberry Pi se va „bloca” din cauza așteptării I/-urilor pe disc.
Scenariu:
- sistemul de operare rulează numai în citire și nu are swap
- există un sistem de fișiere tmpfs pentru lucrurile în care sistemul de operare trebuie să scrie (/var, /log etc)
- tmpfs are implicit jumătate din cei 2 GB de RAM disponibile
- există un hard disk USB conectat pentru stocarea fișierelor MP4 mari
După un timp de rulare a unui program Python care interacționează cu un accelerator USB Google Coral, ieșirea de top este:
Deci, sarcina procesorului este masivă, dar utilizarea procesorului este scăzută. Credem că acest lucru se datorează faptului că așteaptă IO pe hard disk-ul USB.
Alteori vom vedea o utilizare și mai mare a memoriei cache:
Mem: 1622744K folosit, 289184K gratuit, 93712K shrd, 32848K buff, 1158916K în cache
CPU: 0% usr 0% sys 0% nic 24% inactiv 74% io 0% irq 0% sirq
Medie de încărcare: 5,00 4,98 4,27 1/251 2645
Sistemul de fișiere arată destul de normal:
root@ifu-14:~# df -h
Dimensiunea sistemului de fișiere Utilizat Disponibil Utilizare% Montat pe
/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/volatil
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
Când totul „se blochează”, observăm că hard disk-ul USB nu răspunde complet (ls nu face nimic și doar îngheață).
În jurnalele dmesg am observat următoarele rânduri (lipite ca imagine pentru a păstra culorile):
Iată o ieșire completă a dmesg după ce începem să primim aceste erori:
https://pastebin.com/W7k4cp35
Presupunem că, atunci când software-ul care rulează pe sistem încearcă să facă ceva cu un fișier mare (50 MB +) (mutându-l pe hard disk-ul USB), cumva sistemul rămâne fără memorie.
Nu suntem cu adevărat siguri cum procedăm. Am gasit acest blog: https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/ care pare a fi aceeași problemă și sugerează modificarea vm.dirty_ratio și vm.dirty_background_ratio pentru a goli mai des cache-urile pe disc.
Este aceasta abordarea corectă?
Setările curente sunt vm.dirty_ratio = 20 și vm.dirty_background_ratio = 10
Ar putea un hard disk USB relativ lent să necesite schimbarea asta? Poate cineva să explice ce se întâmplă?
