性能

解析器如何处理 100 MB 的日志而不占用服务器内存，以及 你可以做些什么来保持转换速度。

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

繁忙域控制器上的 DNS 调试日志文件很大。Convert-DNSDebugLogFile 就是为这种情况设计的：它已经经过测试，能够处理 100 MB 及以上的日志，并且在普通服务器硬件上几分钟内完成处理。

为什么它很快

你不需要了解这些细节就能使用该模块，但了解这些可以解释你观察到的行为。

技术你会注意到的效果
使用带有 64 KB 缓冲区的 StreamReader / StreamWriter文件以块的形式读取和写入，而不是一次性用 Get-Content 读取整个文件
流式处理，单次遍历无论日志多大，内存使用量基本保持平稳
使用字符串操作（.Substring()、.IndexOf()）代替正则表达式每行 CPU 使用率显著降低，而日志行数以百万计
手动写入 CSV 而非使用 Export-Csv每条记录没有对象管道的开销
基于哈希表的统计聚合在同一次遍历中，汇总几乎不额外消耗资源

重要的结果是：整个日志文件从未全部加载到内存中。 一个 500 MB 的日志不需要 500 MB 的内存。这就是该模块与大多数自制脚本“读取文件、拆分、构建对象”方法的区别——后者在处理 5 MB 样本时表现良好，但在真实的域控制器日志上会崩溃。

如何最大化运行效率

转换轮换的日志块，而不是一个巨大的文件

配置 DNS 服务器在可控大小时滚动日志——50 到 200 MB 是个不错的范围。多个中等大小的文件转换时间可预测，且允许计划任务在时间窗口内完成。而一个不断增长的文件最终会拖慢速度。

日志轮换还会生成已关闭的文件，这正是你想要的：

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

不需要详细解析时跳过

如果 DNS 服务器写入了完整的数据包详情，将这些块转换为 JSON 是转换过程中最耗时的部分。

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

在包含许多详情块的日志上，转换速度可提升 30–50%，且生成的 CSV 文件更小。你仍然会获得查询级别的数据和 Information 中的 TCP/UDP 详情头行。详见参数和选项。

早期过滤

-ContextFilter Packet 会在写入之前丢弃服务器注释和事件。输出减少意味着 I/O 减少，文件更小，下游处理更轻松。

只请求你需要的内容

-OutputType Statistic 完全跳过写入行级 CSV。如果你的仪表盘只显示每日计数，这是最节省资源的选项。

本地转换，移动结果

模块支持读取 SMB/UNC 路径，但将 200 MB 的原始日志通过网络拉取到中央解析效率低下。建议在 DNS 服务器上转换，然后移动（压缩后的）CSV 文件——通常只有原始日志大小的十分之一。这是基于 GPO 的收集示例的设计思路。

压缩以便传输和归档

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

此类 CSV 通常可压缩 90% 以上。压缩会在运行结束时消耗少量 CPU，但之后节省大量磁盘和网络资源。

当运行速度比预期慢时

请按顺序检查以下几点：

  1. 磁盘，而非 CPU。 转换过程 I/O 密集。日志位于繁忙卷上或通过慢速链路读取，会成为运行时间的瓶颈。
  2. 详情块。 如果日志包含完整数据包详情且未使用 -NoDetailsParsing，时间主要花在这里。
  3. 文件大小。 单个多 GB 的日志无论如何都会耗时。应通过日志轮换解决，而非参数调整。
  4. 杀毒软件。 实时扫描源日志和生成的 CSV 会使有效 I/O 成本翻倍。为日志目录设置排除是常见且合理的措施。
  5. 内存压力。 模块采用流式处理，理论上不会导致问题，但服务器如果已经在交换，会导致整体变慢。

更多症状和解决方案请参见故障排除。