performance - superfetch - system consume mucho disco windows 10
Compresión para mejorar el rendimiento de escritura del disco duro (12)
Esto depende de muchos factores y no creo que haya una respuesta correcta. Todo se reduce a esto:
¿Se pueden comprimir los datos brutos más rápido que el rendimiento de escritura sin procesar de su disco multiplicado por la relación de compresión que está logrando (o la velocidad múltiple que está tratando de obtener) dado el ancho de banda de la CPU que tiene disponible para este propósito?
Dadas las relativamente altas tasas de escritura de datos en los 10 de MBytes / segundo, este es un obstáculo bastante alto para superar. Al punto de algunas de las otras respuestas, es probable que tenga que tener datos fácilmente comprimibles y simplemente deberá compararlos con alguna prueba de experimentos de tipo de razonabilidad y averiguarlo.
Relativo a una opinión específica (¿adivinar?) Al punto sobre núcleos adicionales. Si subes la compresión de los datos y mantienes los núcleos alimentados, con la alta relación de compresión del texto, es probable que esa técnica dé algún fruto. Pero esto es sólo una conjetura. En una sola aplicación de subprocesos que alterna entre escrituras de disco y operaciones de compresión, parece mucho menos probable para mí.
En un sistema moderno, ¿se pueden mejorar las velocidades de escritura del disco duro local al comprimir el flujo de salida?
Esta pregunta se deriva de un caso en el que estoy trabajando, en el que un programa genera en serie y arroja entre 1 y 2 GB de datos de registro de texto en un archivo de texto en bruto en el disco duro y creo que está vinculado a IO. ¿Debo esperar poder disminuir los tiempos de ejecución al comprimir los datos antes de que lleguen al disco o la sobrecarga de compresión consumiría cualquier ganancia que pudiera obtener? ¿Tener un segundo núcleo inactivo afectaría esto?
Sé que esto se vería afectado por la cantidad de CPU que se utiliza para generar los datos, por lo que sería bueno tener reglas generales sobre cuánto tiempo de CPU inactiva se necesitaría.
Recuerdo una conversación en video donde alguien usó la compresión para mejorar las velocidades de lectura de una base de datos, pero la compresión de IIRC requiere mucha más CPU que la descompresión.
Esto solía ser algo que podría mejorar el rendimiento en bastantes aplicaciones mucho tiempo atrás. Supongo que hoy en día es menos probable que valga la pena, pero podría serlo en su circunstancia específica, particularmente si los datos que está registrando son fácilmente compresibles,
Sin embargo, como comentó Shog9:
Las reglas generales no te ayudarán aquí. Es su disco, su CPU y sus datos. Configure un caso de prueba y mida el rendimiento y la carga de la CPU con y sin compresión: vea si vale la pena la compensación.
Las CPU han crecido más rápido a un ritmo más rápido que el acceso al disco duro. Incluso en los años 80, muchos archivos comprimidos podían leerse en el disco y descomprimirse en menos tiempo del necesario para leer el archivo original (sin comprimir). Eso no habrá cambiado.
Sin embargo, en general, en la actualidad, la compresión / descompresión se maneja en un nivel inferior al que se estaría escribiendo, por ejemplo, en una capa de E / S de la base de datos.
En cuanto a la utilidad de un segundo núcleo, solo cuenta si el sistema también realizará una cantidad significativa de otras cosas, y su programa tendría que ser de subprocesos múltiples para aprovechar la CPU adicional.
Sí, esto ha sido cierto por al menos 10 años. Hay documentos de sistemas operativos al respecto. Creo que Chris Small pudo haber trabajado en algunos de ellos.
Para la velocidad, la compresión gzip / zlib en niveles de calidad inferiores es bastante rápida; si eso no es lo suficientemente rápido, puedes probar FastLZ . Una forma rápida de usar un núcleo extra es simplemente usar popen(3) para enviar resultados a través de gzip .
Si solo se trata de texto, la compresión definitivamente podría ayudar. Simplemente elija un algoritmo de compresión y configuraciones que hagan que la compresión sea económica. "gzip" es más económico que "bzip2" y ambos tienen parámetros que puede modificar para favorecer la velocidad o la relación de compresión.
Por lo que vale, el sistema de archivos de Sun ZFS tiene la capacidad de tener la compresión sobre la marcha habilitada para disminuir la cantidad de IO de disco sin un aumento significativo en la sobrecarga como un ejemplo de esto en la práctica.
Registrar los datos en forma binaria puede ser una mejora rápida. Escribirá menos en el disco y la CPU perderá menos tiempo convirtiendo números en texto. Puede que no sea útil si las personas van a leer los registros, pero tampoco podrán leer los registros comprimidos.
Sí, sí, sí, absolutamente.
Mírelo de esta manera: tome su velocidad máxima de escritura contigua en megabytes por segundo. (Avanza y mídelo, cronometra un fwrite enorme o algo así). Digamos 100mb / s. Ahora tome su velocidad de CPU en megahercios; digamos 3Ghz = 3000mhz. Divida la velocidad de la CPU por la velocidad de escritura del disco. Ese es el número de ciclos que la CPU está pasando inactivo, que puede gastar por byte en la compresión. En este caso 3000/100 = 30 ciclos por byte.
Si tuvieras un algoritmo que pudiera comprimir tus datos en un 25% para una velocidad de escritura efectiva de 125 mb / s, tendrías 24 ciclos por byte para ejecutarlo y básicamente sería gratis porque la CPU no estaría haciendo nada más de todos modos mientras espera que el disco se agite. 24 ciclos por byte = 3072 ciclos por línea de caché de 128 bytes, fácil de lograr.
Hacemos esto todo el tiempo cuando leemos medios ópticos.
Si tienes un segundo núcleo inactivo, es aún más fácil. Simplemente transfiera el búfer de registro al hilo de ese núcleo y puede tomar todo el tiempo que quiera para comprimir los datos, ¡ya que no está haciendo otra cosa! El único inconveniente es que realmente quieres tener un anillo de almacenamientos intermedios para que no tengas el hilo productor (el que está haciendo el registro) esperando en un mutex para un buffer que el hilo consumidor (el que está escribiendo en el disco) está aguantando.
Windows ya es compatible con File Compression en NTFS, por lo que todo lo que tiene que hacer es establecer el indicador "Comprimido" en los atributos del archivo. Luego puede medir si valió la pena o no.
The Filesystems y el laboratorio de almacenamiento de Stony Brook publicaron una evaluación bastante extensa de rendimiento (y energía) sobre compresión de datos de archivo en sistemas de servidor en la conferencia de investigación de sistemas SYSTOR de IBM este año: ponencia en ACM Digital Library , presentación .
Los resultados dependen de
- algoritmos y configuraciones de compresión usados,
- la carga de trabajo del archivo y
- las características de tu máquina.
Por ejemplo, en las mediciones del papel, usar una carga de trabajo textual y un entorno de servidor usando lzop con bajo esfuerzo de compresión son más rápidos que la escritura simple, pero bzip y gz no lo son .
En su entorno específico, debe probarlo y medirlo. Realmente podría mejorar el rendimiento, pero no siempre es así.
Si está encuadernado con E / S guardando texto legible para el usuario en el disco duro, espero que la compresión reduzca su tiempo de ejecución total.
Si tiene un núcleo inactivo de 2 GHz y un disco duro de 100 MB / s relativamente rápido, la reducción del tiempo de registro de red requiere al menos una compresión de 2: 1 y no más de aproximadamente 10 ciclos de CPU por byte sin comprimir para que el compresor evalúe datos. Con un procesador de doble tubería, eso es (aproximadamente) 20 instrucciones por byte.
Veo que LZRW1-A (uno de los algoritmos de compresión más rápidos) usa de 10 a 20 instrucciones por byte, y comprime el texto típico en inglés sobre 2: 1. En el extremo superior (20 instrucciones por byte), está justo en el límite entre IO bound y CPU bound. En el extremo medio e inferior, todavía está vinculado a IO, por lo que hay unos pocos ciclos disponibles (no mucho) para que un compresor un poco más sofisticado considere los datos un poco más de tiempo.
Si tiene un disco duro más antiguo que no es el mejor, o si el disco duro es más lento por alguna otra razón (fragmentación, otros procesos de multitarea usando el disco, etc.), entonces tendrá aún más tiempo para un futuro compresor sofisticado para ponderar los datos.
Puede considerar configurar una partición comprimida, guardar los datos en esa partición (permitiendo que el controlador del dispositivo la comprima) y comparar la velocidad con su velocidad original. Eso puede tomar menos tiempo y es menos probable que introduzca nuevos errores que cambiar su programa y vincular un algoritmo de compresión.
Veo una lista de sistemas de archivos comprimidos basados en FUSE , y escuché que NTFS también admite particiones comprimidas.
Si esta máquina en particular a menudo está vinculada a IO, otra forma de acelerarla es instalar una matriz RAID. Eso daría una aceleración a cada programa y cada tipo de datos (incluso datos incompresibles).
Por ejemplo, la popular configuración RAID 1 + 0 con 4 discos en total da una aceleración de casi 2x.
La casi tan popular configuración de RAID 5, con los mismos 4 discos en total, ofrece una aceleración de casi 3 veces.
Es relativamente sencillo configurar una matriz RAID con una velocidad de 8 veces la velocidad de una sola unidad.
Las altas relaciones de compresión, por otro lado, aparentemente no son tan sencillas. La compresión de "meramente" 6.30 a uno le daría un premio en efectivo por romper el récord mundial actual de compresión (Premio Hutter).