Jak mogę zapobiec [flush-8: 16] i [jbd2 / sdb2-8] powodowaniu braku reakcji GUI? [Zamknięte]

11

Około dwa razy w tygodniu cały interfejs graficzny blokuje się na około 10-20 sekund bez ostrzeżenia, gdy wykonuję proste zadania, takie jak przeglądanie Internetu lub pisanie artykułu. Kiedy tak się dzieje, elementy GUI nie reagują na wprowadzanie myszy lub klawiatury, a aplet Monitora systemu wyświetla użycie procesora IOWait w 100%.

Dzisiaj wreszcie zdarzyło mi się mieć terminal GNOME już otwarty, gdy problem się zaczął. Pomimo braku reakcji innych aplikacji, takich jak Google Chrome, Firefox, GNOME Do i GNOME Panel, terminal był użyteczny. Przebiegłem iotopi zauważyłem, że polecenia te nazywają się [flush-8:16]i [jbd2/sdb2-8]używają na przemian 99,99% IO.

Co to jest i jak mogę zapobiec powodowaniu braku reakcji na GUI?

Detale

$ mount | grep ^/dev
/dev/sda1 on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=0)
/dev/sdb2 on /home type ext4 (rw,commit=0)
$ cat /proc/swaps 
Filename        Type        Size     Used    Priority
/dev/sdb3       partition   1052252  0       -1

/dev/sdajest OCZ-VERTEX2 i /dev/sdbjest WD10EARS . Oto dumpe2fs /dev/sdb2i smartctl /dev/sdb --all.

Nie widzę nic niezwykłego w dmesglub /var/log/syslog.

cpu-load disk-usage ændrük
źródło
1
Mogę powiedzieć, czym one są: Są częścią systemu plików - flushzapisują bufor RAM / pamięć podręczną na dysk, a jbd2 zajmuje się dziennikiem ext4.
jg-faustus
Nawiasem mówiąc, czy to laptop?
jg-faustus
Po prostu myślę tutaj głośno: 100% IOWait może oznaczać, że system plików czeka na przebudzenie dysku ze stanu niskiego zużycia energii - agresywne oszczędzanie energii jest główną cechą WD Greens. Ale nie jestem pewien, dlaczego miałby zablokować system. Prawdopodobnie jest /dev/sdateż - który dysk zawiera co? Jak „root na sda, home na sdb”?
jg-faustus
Może to być zły dysk, sprawdź dane SMART lub dane wyjściowe pod dmesgkątem błędów dysku.
umówić
4
„zbyt zlokalizowany” - szkoda, że ​​jestem przyszłym gościem, który znalazł to pytanie, ponieważ patrzę na dokładnie ten sam problem.
DXM

Odpowiedzi:

4

Zaryzykuję teorię:

/dev/sdb1 jest może zamiana przestrzeni?

Jeśli coś centralnego dla interfejsu graficznego zostało przeniesione na dysk, GUI nie może kontynuować, dopóki nie otrzyma tych danych. Jeśli dysk wymiany jest uśpiony, oznacza to, że utknął, dopóki dysk nie zareaguje.

Myślę, że dałoby to tymczasową blokadę, a okres 10-20 sekund pasuje do czasu potrzebnego na odpowiedź dysku uśpionego. Terminal prawdopodobnie nadal reaguje, ponieważ wszystko, czego potrzebuje, znajduje się już w pamięci RAM.

Niektóre narzędzia terminalowe do eksploracji teorii:

  • hdparm -C /dev/sdX informuje, czy dysk śpi:

    $ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby

    active/idleoznacza, że ​​działa. W stanie standbylub sleepingprzestał się obracać i ponowne uruchomienie zajmie trochę czasu. Zobaczyć man hdparm.

  • free -m mówi, ile miejsca zajmuje zamiana:

    $ free -m     
             total       used       free     [...]
Mem:          5973       4928       1045     [...]
-/+ buffers/cache:       1091       4882
Swap:         6234          0       6234

    „Zamień:” jest odpowiednią linią, w tym przykładzie dostępna jest wymiana 6,2 GB i nic nie jest używane.

Jeśli to jest problem, możesz przenieść swap do sda lub wyłączyć spindowns dla sdb.

jg-faustus
źródło
To dobra teoria, ale myślę, że problem nie jest związany z zamianą. Chociaż partycja wymiany jest rzeczywiście na tym samym dysku, system rzadko, jeśli w ogóle, korzysta z niej. free -mpodczas blokady potwierdził, że użyto 0 MB wymiany.
ændrük
@ ændrük Ok, wtedy będę musiał pozostawić pole ekspertom.
jg-faustus