Bagaimana saya bisa mencegah [flush-8: 16] dan [jbd2 / sdb2-8] dari menyebabkan GUI tidak responsif? [Tutup]

Sekitar dua kali seminggu, seluruh antarmuka grafis akan terkunci selama 10-20 detik tanpa peringatan sementara saya melakukan tugas-tugas sederhana seperti menjelajahi web atau menulis makalah. Ketika ini terjadi, elemen GUI tidak merespons input mouse atau keyboard, dan applet Monitor Sistem menampilkan 100% penggunaan IOW dari prosesor.

Hari ini, saya akhirnya memiliki Terminal GNOME yang sudah terbuka ketika masalah dimulai. Meskipun aplikasi lain seperti Google Chrome, Firefox, GNOME Do, dan Panel GNOME tidak responsif, terminal tetap dapat digunakan. Saya berlari iotopdan mengamati bahwa perintah bernama [flush-8:16]dan [jbd2/sdb2-8]secara bergantian menggunakan 99,99% IO.

Apa ini, dan bagaimana saya bisa mencegah mereka menyebabkan GUI tidak responsif?

Detail

$ 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/sdaadalah OCZ-VERTEX2 dan /dev/sdbmerupakan WD10EARS . Ini dumpe2fs /dev/sdb2dan smartctl /dev/sdb --all.

Saya tidak melihat sesuatu yang tidak biasa di dmesgatau /var/log/syslog.

cpu-load disk-usage

— ændrük
sumber

Saya dapat memberi tahu Anda apa itu: Mereka adalah bagian dari sistem file - flushmenulis buffer RAM / cache ke disk, dan jbd2 berkaitan dengan jurnal ext4.

— jg-faustus

Ngomong-ngomong, ini laptop?

— jg-faustus

Hanya dengan berpikir keras di sini: 100% IOWTapat berarti bahwa sistem file sedang menunggu disk untuk bangun dari kondisi daya rendah - penghematan daya yang agresif adalah fitur utama dari WD Greens. Tetapi tidak yakin mengapa itu akan mengunci sistem. Mungkin ada /dev/sdajuga - disk mana yang menyimpan apa? Seperti "root pada sda, home on sdb"?

— jg-faustus

Bisa jadi disk yang buruk, periksa data SMART atau output dmesguntuk kesalahan disk.

— atur

"terlalu terlokalisasi" - terlalu buruk bahwa saya adalah pengunjung masa depan yang menemukan pertanyaan ini karena saya melihat masalah yang sama persis.

— DXM

Saya akan menjelajah teori:

/dev/sdb1 mungkin ruang swap?

Jika sesuatu yang terpusat pada antarmuka grafis telah diturunkan ke disk, GUI tidak dapat melanjutkan sampai ia menerima data tersebut. Jika disk swap tertidur, ini berarti macet sampai disk merespons.

Saya pikir ini akan memberikan penguncian sementara, dan periode 10-20 detik cocok dengan waktu yang dibutuhkan untuk disk tidur untuk merespons. Terminal mungkin masih responsif karena semua yang dibutuhkan sudah dalam RAM.

Beberapa alat terminal untuk mengeksplorasi teori:

hdparm -C /dev/sdX memberi tahu Anda apakah disk sedang tidur:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idleberarti sedang berjalan. Dalam keadaan standbyatau sleepingsudah berhenti berputar dan akan butuh waktu untuk memulai kembali. Lihat man hdparm.

free -m mengatakan berapa banyak ruang swap yang digunakan:

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

"Swap:" adalah baris yang relevan, dalam contoh ini swap 6,2 GB tersedia dan tidak ada yang digunakan.

Jika ini masalahnya, Anda bisa memindahkan swap ke sda atau menonaktifkan spindown untuk sdb.

— jg-faustus
sumber

Ini adalah teori yang bagus, tapi saya pikir masalahnya tidak terkait dengan swap. Sementara partisi swap memang di drive yang sama, sistem jarang, jika pernah, menggunakannya. free -mselama penguncian mengkonfirmasi bahwa 0 MB swap sedang digunakan.

— ændrük

@ ændrük Ok, maka saya harus menyerahkan bidang kepada para ahli.

— jg-faustus