# 性能

> 解析器如何处理 100 MB 的日志而不占用服务器内存，以及 你可以做些什么来保持转换速度。

---

LLMS index: [llms.txt](/llms.txt)

---

繁忙域控制器上的 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 是个不错的范围。多个中等大小的文件转换时间可预测，且允许计划任务在时间窗口内完成。而一个不断增长的文件最终会拖慢速度。

日志轮换还会生成已关闭的文件，这正是你想要的：

```powershell
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
```

### 不需要详细解析时跳过

如果 DNS 服务器写入了完整的数据包详情，将这些块转换为 JSON 是转换过程中最耗时的部分。

```powershell
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing
```

在包含许多详情块的日志上，转换速度可提升 30–50%，且生成的 CSV 文件更小。你仍然会获得查询级别的数据和 `Information` 中的 TCP/UDP 详情头行。详见[参数和选项](../03-parameters-and-options/)。

### 早期过滤

`-ContextFilter Packet` 会在写入之前丢弃服务器注释和事件。输出减少意味着 I/O 减少，文件更小，下游处理更轻松。

### 只请求你需要的内容

`-OutputType Statistic` 完全跳过写入行级 CSV。如果你的仪表盘只显示每日计数，这是最节省资源的选项。

### 本地转换，移动结果

模块支持读取 SMB/UNC 路径，但将 200 MB 的原始日志通过网络拉取到中央解析效率低下。建议在 DNS 服务器上转换，然后移动（压缩后的）CSV 文件——通常只有原始日志大小的十分之一。这是[基于 GPO 的收集示例](../examples/gpo-driven-collection/)的设计思路。

### 压缩以便传输和归档

```powershell
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput
```

此类 CSV 通常可压缩 90% 以上。压缩会在运行结束时消耗少量 CPU，但之后节省大量磁盘和网络资源。

## 当运行速度比预期慢时

请按顺序检查以下几点：

1. **磁盘，而非 CPU。** 转换过程 I/O 密集。日志位于繁忙卷上或通过慢速链路读取，会成为运行时间的瓶颈。
2. **详情块。** 如果日志包含完整数据包详情且未使用 `-NoDetailsParsing`，时间主要花在这里。
3. **文件大小。** 单个多 GB 的日志无论如何都会耗时。应通过日志轮换解决，而非参数调整。
4. **杀毒软件。** 实时扫描源日志和生成的 CSV 会使有效 I/O 成本翻倍。为日志目录设置排除是常见且合理的措施。
5. **内存压力。** 模块采用流式处理，理论上不会导致问题，但服务器如果已经在交换，会导致整体变慢。

更多症状和解决方案请参见[故障排除](../08-troubleshooting/)。
