Prestazioni
For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /it/docs/04-performance/index.md.
I log di debug DNS su un controller di dominio molto trafficato sono grandi. Convert-DNSDebugLogFile è stato progettato proprio per questo caso: è stato testato con log da 100 MB e oltre, e li elabora in pochi minuti su hardware server ordinario.
Perché è veloce
Non devi sapere nulla di tutto questo per usare il modulo, ma spiega il comportamento che osserverai.
| Tecnica | Effetto che noterai |
|---|---|
StreamReader / StreamWriter con buffer da 64 KB | Il file viene letto e scritto a blocchi invece che con un unico grande Get-Content |
| Streaming, singolo passaggio | L’uso di memoria resta più o meno costante indipendentemente dalla dimensione del log |
Operazioni su stringhe (.Substring(), .IndexOf()) invece di espressioni regolari | Molto meno CPU per riga, e ci sono milioni di righe |
CSV scritto a mano invece di Export-Csv | Nessun overhead di pipeline oggetti per ogni record |
| Aggregazione basata su Hashtable per le statistiche | I riepiloghi costano quasi nulla durante lo stesso passaggio |
La conseguenza importante: l’intero log non viene mai caricato in memoria. Un log da 500 MB non richiede 500 MB di RAM. Questa è la differenza tra il modulo e l’approccio “leggi il file, dividilo, crea oggetti” che la maggior parte degli script fatti in casa usa — quell’approccio funziona bene su un campione da 5 MB ma fallisce su un DC reale.
Come ottenere il massimo da una conversione
Converti i chunk ruotati, non un unico file gigante
Configura il server DNS per far ruotare il log a una dimensione gestibile — da 50 a 200 MB è un buon intervallo. Diversi file medi si convertono in tempi prevedibili e permettono a un job schedulato di finire entro la sua finestra. Un file che cresce sempre invece no.
La rotazione ti dà anche file chiusi con cui lavorare, che è quello che vuoi comunque:
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -Skip 1 |
Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
Salta il parsing dei dettagli se non ti serve
Se il server DNS scrive dettagli completi dei pacchetti, trasformare quei blocchi in JSON è la parte più costosa della conversione.
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing
Aspettati esecuzioni dal 30 al 50% più veloci su log che contengono molti blocchi di dettaglio, più un CSV molto più piccolo. Otterrai comunque i dati a livello di query e la riga di intestazione TCP/UDP in Information. Vedi Parametri e Opzioni.
Filtra presto
-ContextFilter Packet scarta note ed eventi del server prima che vengano scritti. Meno output significa meno I/O, file più piccoli e meno lavoro a valle.
Chiedi solo ciò che ti serve
-OutputType Statistic salta completamente la scrittura del CSV a livello di riga. Se la tua dashboard mostra solo conteggi giornalieri, questa è di gran lunga l’opzione più economica.
Converti localmente, sposta i risultati
Il modulo legge percorsi SMB/UNC, ma trasferire un log grezzo da 200 MB in rete per analizzarlo centralmente è il modo più lento. Converti sul server DNS, poi sposta il CSV (compresso) — di solito è un decimo dei byte. Questo è il design dietro l’esempio di raccolta guidata da GPO.
Comprimi per trasferimento e archivio
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput
Un CSV di questa forma tipicamente si riduce del 90% o più. La compressione costa un po’ di CPU alla fine della conversione e risparmia molto spazio su disco e rete dopo.
Quando una conversione è più lenta del previsto
Controlla questi punti in ordine:
- Disco, non CPU. La conversione è intensiva in I/O. Un log su un volume molto occupato, o letto su un collegamento lento, domina il tempo di esecuzione.
- Blocchi di dettaglio. Se il log contiene dettagli completi dei pacchetti e non hai usato
-NoDetailsParsing, lì va il tempo. - Dimensione del file. Un singolo log multi-gigabyte richiederà comunque tempo. Risolvi con la rotazione, non con i parametri.
- Antivirus. La scansione in tempo reale sia del log sorgente che del CSV generato può raddoppiare il costo effettivo di I/O. Un’esclusione per la cartella dei log è una misura comune e ragionevole.
- Pressione sulla memoria. Il modulo usa lo streaming, quindi non dovrebbe essere la causa — ma un server già in swapping rallenterà tutto.
Altri sintomi e soluzioni sono raccolti in Risoluzione dei problemi.