Mi escritorio suele responder muy bien, incluso bajo una carga pesada. Pero cuando copio archivos a una unidad USB, siempre se bloquea después de un tiempo. Por "bloquear", quiero decir:
- Mover el foco de una ventana a otra puede tardar entre 10 y 20 segundos
- Cambiar de escritorio puede tardar entre 10 y 20 segundos
- Los videos ya no se actualizan (en YouTube, el audio continúa reproduciéndose, solo el video se congela)
La carga del sistema no es excepcionalmente alta cuando esto sucede. A veces, veo mucho blanco en xosview, lo que indica que el kernel está ocupado en alguna parte.
A primera vista, parece que copiar archivos a la unidad USB interferiría de alguna manera con compiz, pero no puedo imaginar cuál podría ser la conexión.
Aquí está el resultado de htop:
Aquí está el resultado de iostat -c -z -t -x -d 1una suspensión de 2 minutos:
19.07.2012 20:38:22
avg-cpu: %user %nice %system %iowait %steal %idle
1,27 0,00 0,38 37,52 0,00 60,84
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdg 0,00 2,00 0,00 216,00 0,00 109248,00 1011,56 247,75 677,69 0,00 677,69 4,63 100,00
Como puede ver, sólo el disco duro externo está activo. Aquí está el registro completo:http://pastebin.com/YNWTAkh4
El bloqueo comenzó a las 20:38:01 y finalizó a las 20:40:19.
Información del software:
- openSUSE 12.1
- KDE 4.7.x
- Sistemas de archivos: reiserfs y btrfs en mi disco duro interno, btrfs en la unidad USB
Respuesta1
Mi primera suposición fue btrfsque los procesos de E/S de este sistema de archivos a veces toman el control. Pero eso no explicaría por qué X se bloquea.
Mirando las interrupciones, veo esto:
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 179 0 0 0 0 0 0 0 IR-IO-APIC-edge timer
1: 6 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042
8: 1 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0
9: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi
12: 10 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042
16: 3306384 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1, nvidia, mei, eth1
Bueno, claro. El controlador USB utiliza la misma IRQ que la tarjeta gráfica y es el primero en la cadena. Si se bloquea (porque el sistema de archivos hace algo costoso), la tarjeta gráfica muere de hambre (y la red también).
Respuesta2
Había visto problemas similares conopenSUSE12.1 del kernel Linux-3.1 y descubrí que deshabilitar páginas grandes transparentes ayudó:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
El problema subyacente es que si una aplicación asigna 4 MB o más, el kernel intentará darle una página enorme, para lo cual necesita 4 MB de RAM contiguos. Ahora, si hay muchas páginas sucias que aún deben escribirse en un dispositivo USB lento, espera a que finalice la E/S antes de continuar con la asignación de memoria.
Respuesta3
Como se mencionó, esto probablemente tenga que ver con la configuración de Hugepages del kernel. Conozco a varias personas con este problema. Puedes encontrar mucha documentación al respecto en la web, por ej.
- https://bbs.archlinux.org/viewtopic.php?id=112846&p=1
- http://lwn.net/Articles/467328/
- http://forum.manjaro.org/index.php?topic=2062.0
- Rendimiento lento al copiar archivos hacia y desde dispositivos USB
He solucionado completamente el problema en mi configuración haciendo lo siguiente. Tenga en cuenta YMMV, es posible que no todas las correcciones a continuación sean necesarias y tal vez no sean suficientes. Puede que haya olvidado algo para ser honesto. De todos modos esa es mi configuración y funciona.
- Utilice el kernel Linux-ck
echo madvise > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defrag
Respuesta4
Cambie el cable. Retire el óxido del puerto/cables USB.