# 负载预算与真实进程内存

## 大文件完整诊断

2026-10-23 在 Windows x64 / Node v24.15.0 上运行 `python tools/large_source_workflows.py --large`。两个文件均实际写入磁盘，由官方 Python MCAP 写入器生成，并由官方读取器逐条核对消息、负载、时间和 CRC；诊断前后 SHA-256 一致。完整 [观测报告](../examples/validation/large-source-0.15.12.json) 随仓库提供。

| 输入 | 实际编码字节 | 诊断耗时 | 诊断进程峰值 RSS | 单次读取峰值 |
| --- | --- | --- | --- | --- |
| 1,000,000 条 × 32 字节负载 | 63,006,257 | 4.82 秒 | 217,384 KiB | 524,389 字节 |
| 2,049 条 × 1 MiB 负载 | 2,148,621,208 | 137.17 秒 | 132,356 KiB | 1,048,576 字节 |

两者采用无压缩、有块和数据 CRC、无消息索引的布局，数量预算设为 3,000,000。RSS 包含运行时和垃圾回收临时分配，不能用输入大小、消息数或单块预算直接推算；百万条小消息的 RSS 在本次观测中高于少量大消息。耗时仅覆盖诊断子进程，不包括生成输入和参考比对。该证据不代表 2 GiB 压缩文件或所有布局均已进行同等规模测试；三种压缩及故障路径由常规工作流单独验证。命令、资源边界和 CI 手动规模测试见 [大文件诊断](source-diagnostics.md)。

## 查询与外部合并

```sh
python tools/memory_benchmark.py
python tools/fuzz_workflows.py
```

基准在新 Node 子进程中运行真实磁盘查询及外部合并，退出时取得操作系统维护的 `process.resourceUsage().maxRSS`（KiB）。该指标能覆盖同步计算期间的峰值，不依赖定时器采样；同时记录最后 RSS、Node/平台/架构、工具链、输入形状、耗时和算法负载峰值。结果写入 `_interop/memory/report.json`，CI 保存为构件。

固定输入为两个无压缩文件，每条消息 8192 字节，单块目标 128 KiB；每个输入分别测试 512 和 2048 条消息。查询读取 100–109；合并使用 256 KiB 排序段、256 KiB 归并头部预算、fan-in 4，独立参考工具核对输出数和 CRC。

2026-10-18 本地 Windows x64 / Node v24.15.0 观测值：

| 每个输入消息数 | 查询峰值 RSS | 外部合并峰值 RSS |
| --- | --- | --- |
| 512 | 56144 KiB | 210128 KiB |
| 2048 | 56216 KiB | 221436 KiB |

这些值包括 JavaScript 运行时、垃圾回收、对象、压缩器和宿主缓冲；不同机器/运行可不同。合并负载预算的 256 KiB 不表示整个进程只有 256 KiB。输入扩大时的观测趋势也不是任意数据分布下的性能保证；本轮用例不代表全部 ROS 实际负载。

FileCursor pending_bytes、RangeReader cache_bytes、外部合并 run_bytes/merge_bytes、临时文件 spool_bytes 各自约束不同资源，需分别设置。输入解压块、声明和输出摘要另有预算；极大重叠时间范围会使磁盘游标显式超出候选预算。未设置固定 RSS 断言，避免把特定运行时和操作系统差异误当算法错误。

固定种子差分生成 12 组官方三种压缩文件，每组 8 个主题、时间、方向、offset/limit 查询，与按物理次序读取的独立 Python 结果对照；再对 Chunk CRC 定点破坏并要求完整校验失败，共 108 项。任意翻转一个字节可能仍是合法内容，故不假定全部随机翻转都必须拒绝。已有核心变异测试继续覆盖截断、长度与状态边界。