Como posso impedir que [flush-8: 16] e [jbd2 / sdb2-8] causem falta de resposta da GUI? [fechadas]

Aproximadamente duas vezes por semana, toda a interface gráfica fica bloqueada por cerca de 10 a 20 segundos sem aviso enquanto eu estiver executando tarefas simples, como navegar na Web ou escrever um artigo. Quando isso acontece, os elementos da GUI não respondem à entrada do mouse ou do teclado e o applet System Monitor exibe 100% de uso do processador IOWait.

Hoje, finalmente eu já tinha o Terminal GNOME aberto quando o problema começou. Apesar de outros aplicativos como Google Chrome, Firefox, GNOME Do e Painel GNOME não responderem, o terminal foi utilizável. Eu executei iotope observei que os comandos nomeados [flush-8:16]e [jbd2/sdb2-8]estavam usando 99,99% IO alternadamente.

O que são esses e como posso impedi-los de causar falta de resposta da GUI?

Detalhes

$ 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é um OCZ-VERTEX2 e /dev/sdbé um WD10EARS . Aqui está dumpe2fs /dev/sdb2e smartctl /dev/sdb --all.

Não vejo nada incomum em dmesgou /var/log/syslog.

cpu-load disk-usage

— ændrük
fonte

Posso lhe dizer o que são: Eles fazem parte do sistema de arquivos - flushgrava o buffer / cache de RAM no disco e o jbd2 lida com o diário ext4.

— jg-faustus

Este é um laptop, a propósito?

— jg-faustus

Apenas pensando em voz alta aqui: 100% IOWait pode significar que o sistema de arquivos está esperando o disco sair de um estado de baixa energia - a economia de energia agressiva é uma das principais características do WD Greens. Mas não sei por que ele bloquearia o sistema. Presumivelmente /dev/sda, também existe - qual disco contém o quê? Como "root on sda, home em sdb"?

— jg-faustus

Pode ser um disco defeituoso, verifique os dados SMART ou a saída de dmesgerros de disco.

— organiza

"localizado demais" - pena que eu seja um futuro visitante que encontrou essa pergunta porque estou olhando exatamente para o mesmo problema.

— DXM

Vou arriscar uma teoria:

/dev/sdb1 é talvez trocar espaço?

Se algo central na interface gráfica tiver sido transferido para o disco, a GUI não poderá continuar até que tenha recebido esses dados. Se o disco de troca estiver inativo, isso significa que ele ficará travado até que o disco responda.

Eu acho que isso daria um bloqueio temporário, e o período de 10 a 20 segundos se encaixa no tempo que leva para um disco adormecido responder. Presumivelmente, o terminal ainda responde, pois tudo o que precisa já está na RAM.

Algumas ferramentas terminais para explorar a teoria:

hdparm -C /dev/sdX informa se um disco está dormindo:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idlesignifica que está em execução. No estado standbyou sleepingparou de girar e levará um tempo para iniciar novamente. Veja man hdparm.

free -m diz quanto espaço de troca é usado:

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

"Swap:" é a linha relevante; neste exemplo, a troca de 6,2 GB está disponível e nada é usado.

Se esse for o problema, você pode mover a troca para sda ou desativar as saídas para sdb.

— jg-faustus
fonte

Essa é uma boa teoria, mas acho que o problema não está relacionado à troca. Enquanto a partição swap está realmente na mesma unidade, o sistema raramente, se é que alguma vez, a usa. free -mdurante o bloqueio confirmou que 0 MB de troca estava sendo usado.

— ændrük

@ ændrük Ok, então terei que deixar o campo para os especialistas.

— jg-faustus