¿Es una buena práctica utilizar la compresión NTFS en las carpetas de registro de IIS?

¿Es una buena práctica usar la compresión NTFS en las carpetas y archivos de registro de IIS?

Pude bajar de 20GB a 7GB haciendo esto. Los registros de IIS son por día y tienen un tamaño promedio de 20 MB, pero algunos días extremos tienen 200 MB.

Me pregunto si IIS tiene que abrir todo el archivo en la memoria, ¿obligando a NTFS a descomprimir 20 MB (o 200 MB en caso extremo) cada vez? ¿O hay alguna magia que permita a IIS agregar contenido? ¿Cuál es el impacto del sistema? ¿Podría convertirse en un problema si aumentamos nuestro tráfico?

¿Debería dividirlos por hora en lugar de por día?

¿Algún documento oficial de Microsoft sobre esto? No pude encontrar uno.

— Malartre
fuente

Si necesita mantener los registros a largo plazo, ¿por qué no moverlos? Mantenga los registros del día actual en el servidor y mueva / archive el resto en otro lugar. ¿Para qué estás usando los registros?

— joeqwerty

Moverse es agregar otro proceso que puede fallar. Estaba tratando de besarme.

— Malartre

Respuestas:

Como Evan ya dio una respuesta general, me gustaría abordar dos de sus subpreguntas:

¿IIS vacía los registros cada X minutos?

http.sys, la parte del modo kernel de IIS es responsable del registro y almacena los datos en la memoria antes de escribirlos en los archivos de registro. No estoy seguro, pero no creo que haga el lavado cada x segundos, más probablemente después de que su búfer se esté llenando.

¿Es necesario leer todo el archivo al agregar una sola línea?

No, NTFS escribe actualizaciones en un archivo en su propia caché y luego comprime y agrega los datos de forma asíncrona al archivo. Escribir en un archivo comprimido no es significativamente más lento que en un archivo sin comprimir.

Por lo tanto, no debería haber ningún problema con el uso de la compresión NTFS en los archivos de registro IIS.

Fuentes:

Kit de recursos de IIS 7, Capítulo 15: Registro - Microsoft Press 2008

Windows Internals 6th Edition Part2, Capítulo 12: Sistemas de archivos Microsoft Press 2012

— Peter Hahndorf
fuente

¡Exactamente la respuesta que estaba buscando, @ peter-hahndorf!

— Malartre

Curiosamente, este artículo de Microsoft recomienda lo contrario: la

If you run a program that uses transaction logging and that constantly writes to a database or log, configure the program to store its files on a volume that is not compressed. If a program modifies data through mapped sections in a compressed file, the program can produce "dirty" pages faster than the mapped writer can write them.

pregunta es, ¿cuál es la definición de constantemente ?

— Zero3

@ Zero3 El registro de transacciones es algo un poco diferente de los registros de IIS. Ahí es donde una función dentro de su programa en realidad no puede regresar con éxito hasta que un cambio transaccional se haya hecho duradero al haber sido escrito en el disco, por lo que el rendimiento de la aplicación está directamente relacionado con la velocidad de escritura de su disco para sus registros de transacciones.

— NReilingh

@NReilingh Puede que tengas razón. En realidad, no sé si IIS escribe en sus archivos de registro sync / async. De cualquier manera, creo que el punto general que plantea el artículo (hay otros ejemplos en él, como las carpetas de usuario con muchas lecturas y escrituras) es que la E / S pesada podría ser un problema con las carpetas comprimidas.

— Zero3

Comprimo mis registros IIS en muchos servidores IIS, aunque principalmente en servidores que alojan aplicaciones / aplicaciones web de Outlook o sitios web de bajo volumen. No tengo problemas para hacerlo, y me gusta bastante el ahorro de espacio en disco.

En general, está cambiando la CPU por almacenamiento al tomar esta decisión. Si, para empezar, está obligado a utilizar la CPU, probablemente esta no sea una buena compensación. Para mis servidores OWA, que pueden crecer gigabytes de registros al día (gracias a los dispositivos ActiveSync), creo que la compensación es buena.

El controlador del sistema de archivos NTFS maneja la compresión, por lo que no cambia la forma en que IIS escribe en los archivos.

Editar:

Potencialmente, también está intercambiando parte del ancho de banda de E / S y IOPS. Si tiene un volumen lo suficientemente alto como para que sus registros de registro sean un consumo significativo de recursos de E / S, también podría ver una disminución en el consumo de E / S al habilitar la compresión.

La única forma de saber cómo te afecta esto es compararlo tú mismo. Tome una línea base con la compresión deshabilitada y luego habilitada y compárelos. No hay una varita mágica para agitar para saber cómo te afectará, hay demasiados factores no deterministas en juego.

— Evan Anderson
fuente

Golpéame por unos segundos ... ¿no tienes trabajo que hacer, en lugar de jugar ServerFault? : p De todos modos, +1. He hecho lo mismo durante años y aún así tengo un problema como resultado.

— HopelessN00b

Esta respuesta es anecdótica y divertida, pero estoy buscando más datos. Estoy viendo detalles específicos, como si IIS vaga los registros cada X minutos y si necesita leer todo el archivo solo para agregar una línea.

— Malartre

@Malartre No es anecdótico, de verdad. Como se mencionó, la compresión de archivos / carpetas NTFS es una compensación: espacio en disco para los ciclos de la CPU (y un aumento muy pequeño del uso de memoria). Eso es lo más específico y factible posible sin realizar evaluaciones comparativas y ejecutar pruebas reales en su entorno específico.

— HopelessN00b