Gran actividad de escritura en el rendimiento del sistema de armas nucleares SSD

Me di cuenta de que cuando hago aplicaciones de escritura pesada, todo el sistema se ralentiza. Para probar esto aún más, ejecuté esto para hacer una actividad de disco (relativamente) baja en CPU y alta:

john -incremental > file_on_SSD

Esto bombea decenas de miles de cadenas por segundo a un archivo en el disco de mi sistema.

Cuando hace esto, el mouse se retrasa, los TTY dejan de responder, las aplicaciones se "desvanecen" y, en general, toda la computadora queda inutilizable. Cuando eventualmente puedo controlar + C john, el sistema vuelve a su máxima potencia después de unos segundos.

Este es un ejemplo extremo, pero tengo problemas similares con actividades ligeramente menos intensivas en escritura, como copiar archivos grandes de fuentes rápidas o transcodificar.

Mi disco principal del sistema operativo es un SSD bastante rápido ( OCZ Agility 60GB ) con EXT4. Si escribo johnla salida en un disco mecánico con EXT4, no experimento las mismas ralentizaciones, aunque la velocidad es mucho más lenta (SSD hace ~ 42,000 palabras por segundo, mecánico hace 8,000 w / s). El rendimiento puede ser relevante. El disco mecánico tampoco tiene nada que ver con el sistema. Son solo datos.

Y estoy usando el kernel 2.6.35-2, pero he notado este problema desde que obtuve este SSD cuando probablemente estaba usando .31 o algo de esa época.

Entonces, ¿qué está causando la desaceleración? Problema EXT4? Problema del kernel? Problema de SSD? Todas las anteriores? ¿Algo más?

Si cree que necesito realizar una prueba adicional, simplemente deje un comentario diciéndome qué hacer y adjuntaré el resultado a la pregunta.

Este ha sido un problema conocido por un tiempo. Usar un FS sintonizado con SSD como Btrfs puede ayudar, pero puede que no.

En última instancia, es un error en los sistemas de gestión de memoria / planificador de E / S. Recientemente, ha habido algunos parches que tienen como objetivo abordar este problema. Ver solucionado: ¿El problema de la capacidad de respuesta del escritorio de Linux?

Estos parches eventualmente pueden llegar al núcleo de la línea principal, pero por ahora, probablemente tendrá que compilar su propio núcleo si desea solucionar este problema.

Hay algunas cosas que puede verificar para intentar mejorar el rendimiento de SSD en Linux.

1. Establezca el punto de montaje en 'noatime'. La actividad adicional que actualiza los tiempos de acceso generalmente se desperdicia en la mayoría de los casos de uso. Especialmente en el caso de bombear continuamente líneas individuales en un archivo, está forzando múltiples actualizaciones al sistema de archivos para cada acceso.

2. Revisa el elevador. El ascensor predeterminado para la mayoría de las distribuciones está configurado para bandejas giratorias de acceso aleatorio. Los SSD no necesitan la lógica adicional, por lo que establecer el elevador en noop puede mejorar el rendimiento al permitir que el hardware administre las escrituras.

3. Escritura directa v almacenamiento en caché de reescritura. Esto es un poco más esotérico, pero puede verificar el método de almacenamiento en caché utilizado hdparmpara el dispositivo. El almacenamiento en caché de reescritura puede tener un impacto positivo en el rendimiento de SSD en comparación con la reescritura.

El almacenamiento en caché de su archivo probablemente esté ajustado incorrectamente para su carga de trabajo. Desafortunadamente, el kernel de Linux es lo suficientemente estúpido como para no manejar esto automáticamente y los valores predeterminados son bastante malos si tiene mucha RAM y dispositivos de bloqueo lo suficientemente lentos. Ver https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ para más detalles.

Sugeriría intentar modificar /etc/sysctl.confcualquiera

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

para reducir en gran medida la presión RAM causada por el almacenamiento en caché de escritura para permitir que el núcleo maneje mejor otras tareas. Esto cambiará la latencia mejorada por un menor rendimiento.

Otra posibilidad es aumentar el almacenamiento en caché, pero si su proceso sigue escribiendo constantemente nuevos datos todo el tiempo, alcanzará una latencia muy mala si el caché se llena alguna vez. Si quieres probarlo, puedes hacer algo como

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

Tenga en cuenta que la *_ratioconfiguración se refiere al porcentaje de RAM disponible. Si desea un mejor control, use la *_bytesconfiguración. Yo personalmente uso la siguiente configuración para mi estación de trabajo:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

Eso limita la caché de escritura en segundo plano a 50 MB y fuerza la escritura sincrónica si hay 200 MB en la caché.