Как сделать так, чтобы [flush-8: 16] и [jbd2 / sdb2-8] не вызывали зависания графического интерфейса пользователя? [закрыто]

Question 1

Примерно два раза в неделю весь графический интерфейс блокируется на 10-20 секунд без предупреждения, пока я выполняю простые задачи, такие как просмотр веб-страниц или написание статьи. Когда это происходит, элементы графического интерфейса пользователя не реагируют на ввод с помощью мыши или клавиатуры, а апплет системного монитора отображает 100% использование процессора IOWait.

Сегодня у меня наконец-то оказался открыт терминал GNOME, когда возникла проблема. Несмотря на то, что другие приложения, такие как Google Chrome, Firefox, GNOME Do и панель GNOME, не отвечали, терминал можно было использовать. Я запустил iotop и заметил, что команды с именами [flush-8: 16] и [jbd2 / sdb2-8] попеременно используют 99,99% ввода-вывода.

Что это такое и как я могу предотвратить их отключение графического интерфейса?

Подробности

$ 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 / sda - это OCZ-VERTEX2 и / dev / sdb - это WD10EARS . Вот dumpe2fs / dev / sdb2 и smartctl / dev / sdb --all .

Я не вижу ничего необычного в dmesg или / var / log / syslog .

Question 2

Я буду рисковать теорией:

/dev/sdb1 возможно, область подкачки?

Если что-то центральное к графическому интерфейсу было разгружено к диску, GUI не может продолжиться, пока это не получило те данные. Если диск подкачки спит, это означает, что он застревает, пока диск не отвечает.

Я думаю, что это дало бы временный тупик, и 10-20 вторых периодов соответствуют времени, которое требуется, чтобы диск сна ответил. Терминал является, по-видимому, все еще быстро реагирующим, потому что все, в чем требуется, уже находится в RAM.

Некоторые терминальные инструменты для исследования теории:

hdparm -C /dev/sdX говорит Вам, спит ли диск:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idle средства, которые это выполняет. В состоянии standby или sleeping это прекратило вращаться и будет требовать времени к запуску снова. Посмотрите man hdparm.
free -m говорит, сколько области подкачки используется:
```
$ free -m     
             total       used       free     [...]
Mem:          5973       4928       1045     [...]
-/+ buffers/cache:       1091       4882
Swap:         6234          0       6234
```
"Подкачка": соответствующая строка, в этой подкачке 6,2 ГБ в качестве примера доступно, и ничто не используется.

Если это - проблема, Вы могли бы или переместить подкачку в sda или отключить spindowns для sdb.

j-g-faustus · Answer 1 · 15 March 2011 в 04:11