# Rendimiento > Cómo el analizador maneja logs de 100 MB sin consumir la memoria de tu servidor, y qué puedes hacer para mantener las conversiones rápidas. --- LLMS index: [llms.txt](/llms.txt) --- Los logs de depuración DNS en un controlador de dominio ocupado son grandes. `Convert-DNSDebugLogFile` está diseñado para ese caso: ha sido probado con logs de 100 MB y más, y los procesa en minutos en hardware de servidor común. ## Por qué es rápido No necesitas saber esto para usar el módulo, pero explica el comportamiento que observarás. | Técnica | Efecto que notarás | |---|---| | `StreamReader` / `StreamWriter` con buffers de 64 KB | El archivo se lee y escribe en fragmentos en lugar de un gran `Get-Content` | | Transmisión, pasada única | El uso de memoria se mantiene aproximadamente constante sin importar el tamaño del log | | Operaciones con cadenas (`.Substring()`, `.IndexOf()`) en lugar de expresiones regulares | Mucho menos CPU por línea, y hay millones de líneas | | CSV escrito a mano en lugar de `Export-Csv` | Sin sobrecarga de pipeline de objetos por registro | | Agregación basada en tabla hash para estadísticas | Los resúmenes cuestan casi nada extra durante la misma pasada | La consecuencia importante: **el log completo nunca se mantiene en memoria.** Un log de 500 MB no necesita 500 MB de RAM. Esta es la diferencia entre el módulo y el enfoque de "leer el archivo, dividirlo, construir objetos" que la mayoría de los scripts caseros usan — ese enfoque funciona bien con una muestra de 5 MB y falla en un DC real. ## Cómo sacar el máximo provecho de una ejecución ### Convierte fragmentos rotados, no un archivo gigante Configura el Servidor DNS para que rote el log a un tamaño manejable — entre 50 y 200 MB es un buen rango. Varios archivos medianos se convierten en un tiempo predecible y permiten que un trabajo programado termine dentro de su ventana. Un archivo que crece sin parar eventualmente no. La rotación también te da archivos cerrados con los que trabajar, que es lo que quieres de todos modos: ```powershell Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" | Sort-Object LastWriteTime -Descending | Select-Object -Skip 1 | Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME ``` ### Omite el análisis de detalles cuando no lo necesites Si el servidor DNS escribe detalles completos de paquetes, convertir esos bloques a JSON es la parte más costosa de la conversión. ```powershell Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing ``` Espera ejecuciones un 30–50 % más rápidas en logs que contienen muchos bloques de detalle, además de un CSV mucho más pequeño. Aún obtienes los datos a nivel de consulta y la línea de encabezado de detalle TCP/UDP en `Information`. Consulta [Parámetros y Opciones](../03-parameters-and-options/). ### Filtra temprano `-ContextFilter Packet` descarta notas y eventos del servidor antes de que se escriban. Menos salida significa menos E/S, archivos más pequeños y menos trabajo posterior. ### Pide solo lo que necesitas `-OutputType Statistic` omite por completo la escritura del CSV a nivel de fila. Si tu panel solo muestra conteos diarios, esta es con diferencia la opción más económica. ### Convierte localmente, mueve los resultados El módulo lee rutas SMB/UNC, pero transferir un log bruto de 200 MB por la red para analizarlo centralmente es la forma lenta. Convierte en el servidor DNS y luego mueve el CSV (comprimido), que suele ser una décima parte de los bytes. Este es el diseño detrás del [ejemplo de recopilación impulsada por GPO](../examples/gpo-driven-collection/). ### Comprime para transferencia y archivo ```powershell Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput ``` Un CSV de esta forma típicamente se reduce en un 90 % o más. La compresión cuesta un poco de CPU al final de la ejecución y ahorra mucho espacio en disco y red después. ## Cuando una ejecución es más lenta de lo esperado Revisa estos puntos en orden: 1. **Disco, no CPU.** La conversión es intensiva en E/S. Un log en un volumen ocupado, o leído por un enlace lento, domina el tiempo de ejecución. 2. **Bloques de detalle.** Si el log contiene detalles completos de paquetes y no usaste `-NoDetailsParsing`, ahí se va el tiempo. 3. **Tamaño del archivo.** Un log único de varios gigabytes tardará un rato de todas formas. Soluciona esto con rotación, no con parámetros. 4. **Antivirus.** El escaneo en tiempo real tanto del log fuente como del CSV generado puede duplicar el costo efectivo de E/S. Una exclusión para el directorio del log es una medida común y razonable. 5. **Presión de memoria.** El módulo usa streaming, así que no debería ser la causa — pero un servidor que ya está intercambiando hará que todo sea lento. Más síntomas y soluciones están recopilados en [Solución de problemas](../08-troubleshooting/).