Asunto

Question

Asunto

Recientemente instalé Ubuntu 16.04 LTS (kernel 4.8.0-52) en un Lenovo T460p con un i7-6820HQ, 32 GB de RAM y un SSD Micron 1100 de 512 GB. Marqué la casilla de cifrado completo del disco durante la instalación y utilicé el diseño de partición predeterminado. En general, el rendimiento es excelente.

Sin embargo, con el tiempo, mis compilaciones comenzaron a ejecutarse y tardaron aproximadamente el doble. Además, durante las partes de la compilación que escriben archivos grandes, cualquier tarea (que no sea de compilación) que requiera E/S de disco termina esperando mucho. Esto incluye iniciar nuevos programas, cargar páginas en Firefox, etc. En Firefox, por ejemplo, puedo navegar por la interfaz de usuario, cambiar de pestaña y todo está bien. Pero si sigo un enlace, toda la interfaz de usuario se bloquea hasta que todo se calma.

En resumen, después de un período de tiempo, las compilaciones de repente tardan más y en ciertos puntos durante la compilación la computadora queda básicamente inutilizable.

¿Qué puedo hacer para intentar diagnosticar o resolver este problema?

Información de solución de problemas

• No reinicie con frecuencia, por lo que el sistema suele estar activo durante varios días antes de que me encuentre con este problema. Una vez que lo presiono, me agito un poco tratando de resolver el problema y luego reinicio para poder seguir trabajando.

• Lo único que resuelve el problema es reiniciar la máquina. Intenté salir de todas las aplicaciones, cerrar sesión y volver a iniciarla, y eliminar el caché del búfer (la teoría del mayal es que, a medida que usaba espacio de memoria, las sincronizaciones del disco ocurrían con más frecuencia), pero solo funciona reiniciar.

• Como posibilidad remota, probé la solución paraesta respuestapero no hubo ningún cambio en el comportamiento.

• La ejecución iotopmuestra el dmcrypt_writehilo usando el 99% de E/S cada vez que tengo problemas. Cuando estoynoAl experimentar el problema, también veo dmcrypt_writeaparecer en la parte superior con un porcentaje de IO relativamente alto, pero no permanece allí por mucho tiempo.

• Si corro dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; synccuando todo funciona normalmente, dmcrypt_writesaltaré a la cima durante uno o dos segundos, pero no tiene la misma duración que durante una de mis compilaciones.

• Una compilación completa genera aproximadamente 1,4 GB de datos. Es un proyecto Java con varios módulos. Entonces, se crean muchos archivos pequeños además de algunos archivos JAR más grandes que agregan todos esos archivos pequeños.

• Siempre hay mucha memoria disponible y la partición de intercambio no se utiliza.

• Tengo compañeros de trabajo con computadoras similares (T460p) que también ejecutan Ubuntu y no experimentan este problema. Todos ellos parecen tenerdiferenteSin embargo, marcas/modelos de SSD.

Actualizar

El problema volvió a surgir, así que hice algunas pruebas más basadas en la respuesta a esta pregunta.

• El sistema de archivos todavía no está montado con la discardopción, así que ejecuté fstrimsuponiendo que sería algo similar a tener la discardopción habilitada.
• No cronometré lo suficiente cuando ocurrió el problema por primera vez, pero después de ejecutarlo fstrim, las velocidades de construcción parecieron volver a la normalidad...peroUna vez completada la compilación, el dmcrypt_writehilo se activa y deja el sistema inutilizable durante un período de tiempo. En general, el tiempo total para construir y hacer que el sistema sea utilizable parece ser más o menos el mismo que antes.
• Cambié /proc/sys/vm/dirty_ratioa 2 y /proc/sys/vm/dirty_background_ratio1 y ejecuté algunas compilaciones. Las compilaciones tardaron más de lo normal, aproximadamente lo mismo que la última vez que encontré este problema, pero el sistema no pareció bloquearse tanto. Cambiarlo de nuevo a 20 y 10 volvió al comportamiento mencionado anteriormente.
• En un arranque limpio, intenté configurarlo /proc/sys/vm/dirty_ratioen 2 y /proc/sys/vm/dirty_background_ratio1 y el tiempo fue comparable al de 20 y 10.

Answer 1

Tuve un problema similar en Debian 10+11 donde, si hacía grandes operaciones de escritura en el disco LUKS, todo mi sistema se congelaba por un tiempo, luego respondía nuevamente y luego se congelaba nuevamente...

Sin embargo, no tuve que reiniciar, solo esperé hasta que finalizó la operación de escritura.

Como escribió ScumCoder, hay una solución disponible. A partir del kernel 5.9, la solución está integrada en el kernel.

El siguiente comando me lo solucionó:

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

Extraje el nombre de mi disco "nvme0n1p3_crypt" usando el comandodmsetup table

Me inspiré enhttps://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_rendimiento

Después de la solución, mis operaciones de escritura son mucho más rápidas.

Answer 2

Tengo exactamente el mismo problema que tú y una investigación rápida mostró esta publicación:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

El empleado de CloudFlare investigó bastante el código fuente de Linux y concluyó que la culpable es la dmcryptimplementación actual. Resolvió el problema básicamente reescribiendo la parte correspondiente del núcleo.

Entonces, AFAIK, las únicas dos formas de deshacerse de las desaceleraciones son (1) compilar su versión del kernel o (2) reiniciar de vez en cuando (como dijiste). Elegí este último.

Answer 3

No conozco LUKS específicamente, pero para problemas generales de IO en un SSD, asegúrese de que el descarte esté activado para su montaje fs, es decir, grep descarte /proc/mounts también puede intentar (como root) "echo 1 >> /proc/sys/ vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio", esto hará que el sistema inicie IO antes cuando haya menos registro de datos para escribir.