[Flush-8: 16] ve [jbd2 / sdb2-8] 'nin GUI yanıt vermemesine neden olmasını nasıl önleyebilirim? [kapalı]

Yaklaşık olarak haftada iki kez, grafik arayüzün tamamı, web'e göz atmak veya kağıt yazmak gibi basit görevleri yaparken uyarı olmadan yaklaşık 10-20 saniye boyunca kilitlenecektir. Bu durumda, GUI öğeleri fare veya klavye girişine yanıt vermez ve Sistem Monitörü uygulamasında% 100 IOWait işlemci kullanımı görüntülenir.

Bugün, nihayet sorun başladığında GNOME Terminali'ni açtım. Google Chrome, Firefox, GNOME Do ve GNOME Panel gibi diğer uygulamaların yanıt vermemesine rağmen, terminal kullanılabilirdi. Çalıştım iotopve komutları adlandırdı [flush-8:16]ve [jbd2/sdb2-8]dönüşümlü olarak% 99,99 IO kullandığını gözlemledim .

Bunlar nedir ve GUI'nin yanıt vermemesine neden olmalarını nasıl önleyebilirim?

ayrıntılar

$ 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/sdabir OCZ-VERTEX2 ve /dev/sdbbir WD10EARS'dir . İşte dumpe2fs /dev/sdb2ve smartctl /dev/sdb --all.

dmesgVeya 'da alışılmadık bir şey görmüyorum /var/log/syslog.

cpu-load disk-usage

— ændrük
kaynak

Size ne olduklarını söyleyebilirim: Dosya sisteminin bir parçasıdır - flushRAM tamponunu / önbelleğini diske yazar ve jbd2 ext4 günlüğü ile ilgilenir.

— jg-faustus

Bu arada bir dizüstü bilgisayar mı?

— jg-faustus

Burada yüksek sesle düşünmek:% 100 IOWait, dosya sisteminin diskin düşük güç durumundan uyanmasını beklediği anlamına gelebilir - agresif güç tasarrufu WD Greens'in önemli bir özelliğidir. Ancak sistemi neden kilitleyeceğinden emin değilim. Muhtemelen bir /dev/sdade var - hangi disk neyi tutuyor? "Sda kökü, sdb'de ev" gibi mi?

— jg-faustus

Bozuk bir disk olabilir, SMART verilerini veya çıkışında dmesgdisk hataları olup olmadığını kontrol edin .

— düzenleyin

"çok yerelleştirilmiş" - bu soruyu bulan bir gelecek ziyaretçi olduğum için çok kötü çünkü aynı soruna bakıyorum.

— DXM

Bir teori geliştireceğim:

/dev/sdb1 belki takas alanı nedir?

Grafik arabirimin merkezi olan bir şey diske yüklenirse, GUI bu verileri alana kadar devam edemez. Takas diski uyuyorsa, disk yanıt verene kadar sıkışmış demektir.

Bunun geçici bir kilitlenme olacağını düşünüyorum ve 10-20 saniyelik süre, uyku diskinin yanıt vermesi için geçen süreye uyuyor. Terminal muhtemelen duyarlı, çünkü ihtiyacı olan tek şey zaten RAM.

Teoriyi keşfetmek için bazı terminal araçları:

hdparm -C /dev/sdX size bir diskin uyup uymadığını söyler:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idledemektir. Durumda standbyya sleepingda dönmeyi durdurdu ve yeniden başlaması biraz zaman alacak. Bkz man hdparm.

free -m ne kadar takas alanı kullanıldığını söylüyor:

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

"Takas:" ilgili satırdır, bu örnekte 6.2 GB takas kullanılabilir ve hiçbir şey kullanılmaz.

Sorun buysa, swap'ı sda'ya taşıyabilir veya sdb için pencereleri devre dışı bırakabilirsiniz.

— JG-Faust'um
kaynak

Bu iyi bir teori, ama bence sorun takas ile ilgili değil. Takas bölümü gerçekten de aynı sürücü üzerindeyken, sistem bunu nadiren kullanır. free -mKilitleme sırasında 0 MB takasın kullanıldığını doğruladı.

— ændrük

@ ændrük Tamam, o zaman alanı uzmanlara bırakmak zorunda kalacağım.

— jg-faustus