¿Cómo averiguo qué está congelando mi máquina?

10

Estoy ejecutando Arch en esta máquina:

3.40GHz i7 hexacore (4930K)

16GB DDR3 1600MHz RAM

2 unidades SSD EVO Samsung 840 en Raid0 (usando la incursión BTRFS)

Cuando ejecuto VMware en mi Arch con algunas máquinas virtuales (2 o 3), dándoles alrededor de 2-4 núcleos cada una, y 2GB de RAM cada una, mi sistema comienza a congelarse al azar. Cada dos minutos, el sistema se congelará entre 10 y 30 segundos, y luego comenzará a moverse nuevamente, solo para congelarse 30 segundos más tarde hasta que apague las máquinas virtuales. Cuando el sistema se congela, el mouse todavía se mueve bien, pero las aplicaciones dejan de responder en el host: vmware no responde, firefox (que también está abierto en el host) no responde, etc.

Cuando ocurre el congelamiento, si tengo un monitor de proceso ejecutándose, muestra varios núcleos maximizados por vmware, pero al mismo tiempo, hay otros núcleos no utilizados. También tengo más que suficiente RAM: las máquinas virtuales usan un total de 6 GB y el host tiene 10 GB sobrantes. Tengo 0 espacios de intercambio, por lo que no hay forma de que el intercambio ralentice algo.

Hay informes de que debido a que btrfs causa la fragmentación de los archivos en un nivel de sistema de archivos, las máquinas virtuales pueden funcionar lentamente. Sin embargo, hasta donde puedo decir, la fragmentación es solo un problema en los discos duros tradicionales: los SSD no tienen cabezales de lectura que buscan, por lo que no les importa si un archivo está muy fragmentado.

Esto nunca solía ocurrir cuando estaba ejecutando Debian 7, así que estoy bastante seguro de que no es un problema de hardware.

¿Qué herramientas puedo ejecutar para descubrir por qué mi sistema se congela? Intenté top / htop e iotop (nada está escribiendo o leyendo en exceso cuando el sistema se congela). Parece que no hay ningún tipo de monitor de actividad para que btrfs sepa si tiene problemas para seguir escribiendo / leyendo algo. ¿Hay algo más que pueda probar?

arch-linux vmware btrfs freeze Tal
fuente
Puede estar relacionado con el uso asociado con LUKS: unix.stackexchange.com/questions/203677/…
brauliobo

Respuestas:

15

Desde la página de btrfs gotchas :

Los archivos con muchas escrituras aleatorias pueden fragmentarse en gran medida (más de 10000 extensiones) causando desperdicio en HDD y picos excesivos de carga de CPU de varios segundos en sistemas con un SSD o una gran cantidad de RAM.

  • En servidores y estaciones de trabajo, esto afecta a las bases de datos y las imágenes de máquinas virtuales.

    • La opción de montaje nodatacow puede ser útil aquí, con problemas asociados.

    ...

  • Los síntomas incluyen btrfs-transacti y btrfs-endio-wri que requieren mucho tiempo de CPU (en picos, posiblemente activados por sincronizaciones). Puede usar filefrag para localizar archivos muy fragmentados (puede que no funcione correctamente con la compresión).

Tuve problemas similares a los que describe con Virtualbox. La nodatacowopción para btrfs no ayudó de manera notable en mi sistema. También probé la opción de desfragmentación automática (mencionada como una posible solución para bases de datos de aplicaciones en entornos de escritorio), también sin resultados que hicieran aceptable el comportamiento.

Al final reduje mi partición btrfs y el Volumen lógico en el que vive, creé un nuevo LV y lo formateé como ext4, y luego puse las imágenes de disco VM que tengo (VirtualBox) en esa "partición".

Anthon
fuente
Definitivamente suena como mi problema. En realidad, estaba buscando una forma de verificar qué tan fragmentado estaba un archivo, pero me di por vencido cuando leí la fragmentación no afecta a los SSD como lo hace con los HDD. Aparentemente, el lugar que leí que no era totalmente exacto, todavía afecta a los SSD, es muy interesante. Probaré filefrag, y tal vez cambie el tamaño de mi partición btrfs y mueva mis máquinas virtuales a una partición ext4 como lo hizo, e informe. Gracias
Tal
0

Podría ser un problema transparente de las grandes páginas, en el que un hilo del núcleo está muy mal , literalmente está extrayendo la RAM para desfragmentarlo o creando grandes páginas de 4k.

Kernel podría haber decidido habilitar páginas enormes dada su cantidad bastante grande de RAM del sistema.

Verifique el contenido de estos dos núcleos ajustables:

/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag

Si su contenido es always, podría cambiar nevery ver si desaparecen los picos / heladas de la CPU.

Marco De Lellis
fuente
el problema está en los retrasos de escritura y no está relacionado con el uso de la CPU
brauliobo
0

El problema se resolvió por completo al no usar LUKS en la partición. Así que formateé la partición directamente con BTRFS y no con LUKS primero.

También montado con los siguientes parámetros:

/dev/sda2 /           btrfs       rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0

Relacionado con el rendimiento de escritura abysmal general dm-crypt (LUKS)

brauliobo
fuente