¿Cómo puedo evitar que [flush-8: 16] y [jbd2 / sdb2-8] causen que la GUI no responda? [cerrado]

Aproximadamente dos veces por semana, toda la interfaz gráfica se bloqueará durante aproximadamente 10-20 segundos sin previo aviso mientras realizo tareas simples como navegar por la web o escribir un documento. Cuando esto sucede, los elementos de la GUI no responden a la entrada del mouse o del teclado, y el applet System Monitor muestra el uso del procesador 100% IOWait.

Hoy, finalmente tuve el Terminal de GNOME ya abierto cuando comenzó el problema. A pesar de que otras aplicaciones como Google Chrome, Firefox, GNOME Do y GNOME Panel no respondían, el terminal era utilizable. Corrí iotopy observé que los comandos nombraban [flush-8:16]y [jbd2/sdb2-8]usaban alternativamente 99.99% IO.

¿Qué son estos y cómo puedo evitar que causen falta de respuesta de la GUI?

Detalles

$ 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/sdaes un OCZ-VERTEX2 y /dev/sdbes un WD10EARS . Aquí está dumpe2fs /dev/sdb2y smartctl /dev/sdb --all.

No veo nada inusual en dmesgo /var/log/syslog.

cpu-load disk-usage

— ændrük
fuente

Puedo decirle cuáles son: son parte del sistema de archivos: flushescribe el búfer / caché de RAM en el disco, y jbd2 se ocupa del diario ext4.

— jg-faustus

¿Es esta una computadora portátil, por cierto?

— jg-faustus

Solo pensando en voz alta aquí: 100% IOWait podría significar que el sistema de archivos está esperando que el disco se active desde un estado de baja energía: el ahorro de energía agresivo es una característica importante de WD Greens. Pero no estoy seguro de por qué bloquearía el sistema. Presumiblemente también hay una /dev/sda, ¿qué disco contiene qué? ¿Como "root en sda, home on sdb"?

— jg-faustus

Podría ser un disco defectuoso, verifique los datos SMART o la salida de dmesgerrores de disco.

— organizar el

"demasiado localizado": lástima que sea un visitante futuro que haya encontrado esta pregunta porque estoy viendo exactamente el mismo problema.

— DXM

Voy a aventurar una teoría:

/dev/sdb1 ¿es acaso espacio de intercambio?

Si algo central de la interfaz gráfica se ha descargado al disco, la GUI no puede continuar hasta que haya recibido esos datos. Si el disco de intercambio está inactivo, esto significa que está atascado hasta que el disco responda.

Creo que esto daría un bloqueo temporal, y el período de 10-20 segundos se ajusta al tiempo que tarda un disco inactivo en responder. Presumiblemente, el terminal todavía responde porque todo lo que necesita ya está en la RAM.

Algunas herramientas terminales para explorar la teoría:

hdparm -C /dev/sdX le dice si un disco está durmiendo:
```
$ sudo hdparm -C /dev/sdb
/dev/sdb:
drive state is:  standby
```
active/idlesignifica que se está ejecutando. En estado standbyo sleepingha dejado de girar y tardará un tiempo en iniciarse nuevamente. Ver man hdparm.

free -m dice cuánto espacio de intercambio se usa:

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

"Swap:" es la línea relevante, en este ejemplo, el intercambio de 6.2 GB está disponible y no se utiliza nada.

Si este es el problema, puede mover swap a sda o deshabilitar spindowns para sdb.

— jg-faustus
fuente

Esta es una buena teoría, pero creo que el problema no está relacionado con el intercambio. Si bien la partición de intercambio está en la misma unidad, el sistema rara vez, si alguna vez, la usa. free -mdurante el bloqueo confirmó que se estaban utilizando 0 MB de intercambio.

— ændrük

@ ændrük Ok, entonces tendré que dejar el campo a los expertos.

— jg-faustus