Performance

Wie der Parser 100 MB große Logs verarbeitet, ohne den Speicher deines Servers zu fressen, und was du tun kannst, um die Konvertierung schnell zu halten.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /de/docs/04-performance/index.md.

DNS-Debug-Logs auf einem stark genutzten Domänencontroller sind groß. Convert-DNSDebugLogFile ist genau für diesen Fall gemacht: Es wurde mit Logs von 100 MB und mehr getestet und verarbeitet sie in Minuten auf gewöhnlicher Server-Hardware.

Warum es so schnell ist

Du musst das nicht wissen, um das Modul zu nutzen, aber es erklärt das Verhalten, das du beobachten wirst.

Technik	Effekt, den du bemerkst
`StreamReader` / `StreamWriter` mit 64 KB Puffern	Die Datei wird in Stücken gelesen und geschrieben, statt mit einem großen `Get-Content`
Streaming, ein Durchlauf	Der Speicherverbrauch bleibt ungefähr konstant, egal wie groß das Log ist
String-Operationen (`.Substring()`, `.IndexOf()`) statt regulärer Ausdrücke	Deutlich weniger CPU pro Zeile, und es sind Millionen von Zeilen
CSV wird manuell geschrieben statt mit `Export-Csv`	Kein Overhead durch Objekt-Pipeline pro Datensatz
Hashtable-basierte Aggregation für Statistiken	Zusammenfassungen kosten während des gleichen Durchlaufs fast nichts extra

Die wichtige Konsequenz: Das gesamte Log wird nie komplett im Speicher gehalten. Ein 500 MB großes Log braucht nicht 500 MB RAM. Das ist der Unterschied zwischen dem Modul und dem „Datei lesen, splitten, Objekte bauen“-Ansatz, den die meisten selbstgebastelten Skripte verwenden – dieser Ansatz funktioniert bei einer 5 MB Probe gut, aber bei einem echten DC bricht er zusammen.

Das Beste aus einem Lauf herausholen

Konvertiere rotierte Dateien, nicht eine riesige Datei

Konfiguriere den DNS-Server so, dass das Log bei einer handhabbaren Größe rotiert – 50 bis 200 MB sind ein guter Bereich. Mehrere mittelgroße Dateien werden in vorhersehbarer Zeit konvertiert und erlauben einem geplanten Job, innerhalb seines Zeitfensters fertig zu werden. Eine immer größer werdende Datei irgendwann nicht mehr.

Rollover gibt dir außerdem geschlossene Dateien zum Arbeiten, was du sowieso willst:

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Überspringe Detail-Parsing, wenn du es nicht brauchst

Wenn der DNS-Server vollständige Paketdetails schreibt, ist das Umwandeln dieser Blöcke in JSON der mit Abstand teuerste Teil der Konvertierung.

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing

Erwarte 30–50 % schnellere Läufe bei Logs mit vielen Detailblöcken, plus eine deutlich kleinere CSV. Du bekommst trotzdem die Abfrage-Daten und die TCP/UDP-Detail-Kopfzeile in Information. Siehe Parameter und Optionen.

Früh filtern

-ContextFilter Packet lässt Server-Notizen und Events weg, bevor sie geschrieben werden. Weniger Ausgabe bedeutet weniger I/O, kleinere Dateien und weniger Arbeit danach.

Fordere nur an, was du brauchst

-OutputType Statistic überspringt das Schreiben der zeilenweisen CSV komplett. Wenn dein Dashboard nur Tageszählungen anzeigt, ist das bei weitem die günstigste Option.

Lokal konvertieren, Ergebnisse verschieben

Das Modul liest SMB/UNC-Pfade, aber eine 200 MB große Rohdatei über das Netzwerk zu ziehen, um sie zentral zu parsen, ist der langsame Weg. Konvertiere auf dem DNS-Server und verschiebe dann die (komprimierte) CSV – die ist meist nur ein Zehntel der Bytes. Das ist das Konzept hinter dem GPO-gesteuerten Sammelbeispiel.

Für Transfer und Archiv komprimieren

Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput

CSV dieser Art schrumpft typischerweise um 90 % oder mehr. Komprimierung kostet am Ende des Laufs etwas CPU und spart danach viel Festplatten- und Netzwerkplatz.

Wenn ein Lauf langsamer als erwartet ist

Prüfe diese Punkte der Reihe nach:

Festplatte, nicht CPU. Die Konvertierung ist I/O-lastig. Ein Log auf einem stark genutzten Volume oder über eine langsame Verbindung gelesen, bestimmt die Laufzeit.
Detailblöcke. Wenn das Log vollständige Paketdetails enthält und du nicht -NoDetailsParsing verwendet hast, geht dort die Zeit drauf.
Dateigröße. Eine einzelne mehrgigabyte große Datei braucht einfach seine Zeit. Löse das mit Rollover, nicht mit Parametern.
Antivirus. Echtzeit-Scanning von Quell-Log und generierter CSV kann die effektiven I/O-Kosten verdoppeln. Eine Ausnahme für das Log-Verzeichnis ist eine übliche und sinnvolle Maßnahme.
Speicherdruck. Das Modul streamt, sollte also nicht die Ursache sein – aber ein Server, der bereits swappt, macht alles langsam.

Weitere Symptome und Lösungen findest du in Fehlerbehebung.