¿Por qué los sistemas se vuelven lentos cuando se realizan grabaciones masivas en el disco?


8

Quiero saber por qué los sistemas se vuelven lentos al escribir datos masivos en el disco.

Creo que para que el sistema se vuelva lento, debería haber algún problema con la CPU. Pero escribir solo está vinculado a E / S.

¿Se producen interrupciones de hardware al escribir datos? Si es así, puede ser debido a las interrupciones que la CPU siempre cambia de contexto.


1
Creo que casi todas las aplicaciones leerán / escribirán datos del disco, ¿no?
jilen

1
Tal vez se está cambiando a la memoria y, por lo tanto, se está ralentizando, cuando el disco está bajo un uso intensivo de lo contrario. Un plugin systemload podría decirle si está utilizando swap de forma gráfica. Para la línea de comandos, use free.
usuario desconocido

1
Si ha configurado / ejecutado sysstat, puede consultar los informes SAR para ver los tiempos lentos y le mostrará lo que está sucediendo en ese momento (cambios de contexto, E / S de disco, carga de CPU, tráfico de red, etc.).
Bratchley

También eche un vistazo a su $PATH(s) configuración (es) si utiliza la finalización de comandos o comete muchos errores ortográficos. Mirar a través de muchos directorios, especialmente aquellos con muchas entradas de directorio, puede llevar un tiempo que es notable cuando los recursos son escasos.
MattBianco

Respuestas:


3

La razón principal es que lo habitual: la E / S es mucho más lenta que la CPU / RAM. Incluso si los procesos que realizan operaciones de E / S usan DMA (que descarga la CPU), en algún momento es probable que tengan que esperar a que se completen sus solicitudes.

En el caso más habitual de un HDD, simplemente agregue varias aplicaciones que intenten acceder a los archivos dispersos por el disco, y puede prepararse un café (té, lo que sea). Con los SSD, la situación mejora, pero incluso un SSD, que tiene un rendimiento medido en cientos de MB / s en SATA (en comparación con decenas de MB / s de un HDD de placa giratoria) y tiempos de búsqueda realmente insignificantes (en comparación con milisegundos para una placa giratoria): puede convertirse en un cuello de botella.

El problema, según tengo entendido, no está solo en las transferencias de datos, sino en los gastos generales necesarios: la E / S está controlada por el núcleo, pero rara vez ocurre sin espacio de usuario. Por lo tanto, puede haber una gran cantidad de cambios de contexto, solo desde las aplicaciones que esperan la E / S para verificar si algo está sucediendo (depende de la implementación, por supuesto). En el caso de las transferencias de disco, puede haber varios subprocesos del núcleo que compitan por los recursos o la espera ocupada (que a veces es la estrategia adecuada). Recuerde, por ejemplo, copiar datos de una partición a otra requiere un sistema de archivos moderno para: averiguar dónde están los datos de origen, leerlos, asignar espacio en el sistema de archivos de destino, escribir metadatos, escribir datos, repetir hasta que termine.

Y si, en algún momento, su sistema comienza a intercambiarse (que generalmente tiene mayor prioridad que las E / S normales), el desastre finaliza.

EDITAR : Después de hablar con algunos desarrolladores de kernel de Linux, la situación se volvió un poco más clara. El principal problema es el planificador de E / S, que no tiene mucha idea sobre qué E / S debe priorizar. Por lo tanto, cualquier entrada del usuario y la siguiente salida gráfica está compartiendo la cola con la actividad del disco / red. Como consecuencia de eso, también puede suceder que deseche los datos del proceso en caché de la memoria caché de la página (por ejemplo, bibliotecas cargadas) cuando concluya que puede usar la memoria caché de la página de manera más efectiva en otras E / S. Eso, por supuesto, significa que una vez que el código deba ejecutarse nuevamente, tendrá que recuperarse nuevamente, desde el disco que ya puede estar bajo una gran carga.

Dicho esto, en lo que respecta al kernel de Linux, muchos de estos problemas se han solucionado recientemente (el problema se conoce), por lo que digamos que 4.4.xo 4.5.x deberían comportarse mejor de lo que solían y los problemas deberían informarse (en general la gente del núcleo está contenta cuando alguien quiere ayudar mediante informes y pruebas de errores).


¿Podría explicar un poco, por qué el sistema en general se retrasa cuando IO está muy ocupado? Por ejemplo, no veo ninguna conexión entre el Administrador de Windows y el IO; obviamente, WM no hace ningún IO, entonces, ¿por qué comenzaría a retrasarse (al menos, cuando no se intercambia) ?
Hola Ángel,

En realidad, WM puede hacer muchas E / S a través del servidor X / compositor de Wayland (no tanto como copiar cuatro flujos de datos entre 2 HDD, pero no tiene que ser completamente insignificante, lo que probablemente sea una de las razones por las que awesomeparece estar trabajando un poco mejor que kwinen este sentido).
Peter

Pero, ¿qué tipo de IO hace? ¿Es simplemente por iniciar sesión en xsession-errors/ Xorg.ₙ.log? ¿No está el registro simplemente almacenado, sin interrumpir el trabajo de WM? ¿Algo más? UPD: Acabo de mirar /proc/AwesomePID/fdel archivo que mi WM ha abierto es xsession-errors. Todo lo demás no es realmente un archivo - tomas /dev/null, /proc/stat...
Hola-Angel

1
Pero es que usted dijo que WM puede estar haciendo muchas E / S a través del servidor X / compositor Wayland . Pero lo que sea, ¿por qué crees que no tiene suficiente CPU? Cuando sucede, la CPU suele ser bastante gratuita: puedo ver la carga en el widget de la CPU en mi panel, y desempacar un archivo no toma mucho.
Hola Angel

1
@ Hi-Angel comprueba la actualización de la respuesta si aclara un poco las cosas.
Peter

2

Mi experiencia es que la actividad de E / S por sí sola no ralentiza un sistema. Este efecto ocurre cuando otras tareas también necesitan E / S. La situación se volverá realmente malvada si el sistema se está intercambiando (forzado a hacerlo) y si usted ocasiona una gran carga de E / S.

Puede influir en el impacto de las tareas pesadas de E / S mediante ionice. Si los idleprioriza, la latencia para otras tareas aún puede aumentar, pero no más allá del mínimo. La tarea de E / S se interrumpe inmediatamente si otra tarea (no inactiva) tiene E / S que hacer. Si está utilizando un programador que admite esta configuración.

Consulte Selección de un programador de E / S de Linux


1
Mi experiencia es la opuesta: es decir, puedo comenzar a desempaquetar un gran archivo, lo que provoca una carga de E / S, e intentar en este momento cambiar a otro «escritorio», siento retrasos en el cambio. ¿Cómo es el gestor de ventanas incluso relevante para IO? Y sí, tengo una RAM libre, por lo que no se intercambia (e incluso si no lo hubiera hecho, ¿no se intercambiaría WM en el último turno?) . FWIW, estoy usando un Awesome WM liviano, y anteriormente con kwin las cosas eran aún peores.
Hola Angel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.