# Sense 本地 16 路容量与批量收敛基线

> T-014 正式证据，运行日期：2026-08-10。本文只证明固定主机、固定版本和低码率合成负载下的本地软件基线，不是生产 SLA。

## 1. 结论

在 24 个逻辑处理器、15.78 GiB 内存的 Windows 主机上，提交 `d029067aa750ad75a2d79ef8e6c51b6bad55096d` 使用隔离 PostgreSQL、真实 Sense Control API、两套独立 MediaMTX 和 16 个独立 FFmpeg publisher 完成正式验收：

- 16 个 disabled 视频设备创建后，三轮 16 项批量操作全部成功，生产 MediaMTX 配置 Path 数按 `16 → 0 → 16` 收敛。
- 16 路 enabled 后，第 17 路 enabled 创建稳定返回 `quota_exceeded`，设备台账仍为 16 项；disabled 项不冒充已占用视频通道。
- 同时停止固定第 5～8 路后，精确 4 路受影响、其余 12 路保持在线；恢复后 5.1 秒回到 16 路在线和 `unconverged=0`。
- 正式稳定窗口为 1800.1 秒，每 10 秒绝对节拍采样，共 180 个样本；最大与最终未收敛数均为 0，最终在线 Path 为 16，入站帧错误增量为 0。

因此，默认 16 路的 Sense/PostgreSQL/MediaMTX 控制面与拉流闭环具备可重复的本地软件基线。该结论不证明 16 台真实摄像头、客户网络、录像、下游观看、AI 解码/推理、GPU、64/128 路分片或生产 SLA，也不解除 T-007/T-013。

## 2. 固定环境与负载

| 项目 | 正式值 |
| --- | --- |
| 仓库提交 | `d029067aa750ad75a2d79ef8e6c51b6bad55096d` |
| Sense 二进制 SHA-256 | `e6fa01991152cf7e9f2a1e420422a12d474dfe7be10530ff2924671d46cc7871` |
| Go | `go1.26.5 windows/amd64`（在 `Sense/` 模块上下文读取） |
| PostgreSQL | `17.10`，单次运行隔离临时集群 |
| MediaMTX | `v1.19.3` |
| MediaMTX Windows amd64 ZIP SHA-256 | `5d82148d1032a6a190d9909a2997d9989457aaadf49af87dd02cd4512d31bebe` |
| MediaMTX EXE SHA-256 | `1cda85249312cb9463f9f94c5a712b9f160c9af3fd9490f0d4723911d7880e05` |
| FFmpeg | `8.1.2-full_build-www.gyan.dev` |
| 主机 | Windows，24 logical processors，15.78 GiB memory |
| 单路夹具 | 640×360、10 fps、H.264、无音频、无人物 |
| 发布方式 | 16 个独立 FFmpeg 进程，各自循环预编码夹具并以 `-c copy` 发布独立 RTSP Path |

预编码 copy 发布是为了不把 16 路软件编码负载混入 Sense/MediaMTX 基线。它仍产生 16 个可独立停止和恢复的发布进程，但不能代表真实摄像头编码器、复杂 GOP、高码率、音频或公网抖动。

## 3. 运行方法与安全边界

从仓库根目录执行：

```powershell
./Sense/scripts/t014-capacity.ps1 -PgRoot D:\pgsql17 -PreflightOnly
./Sense/scripts/t014-capacity.ps1 -PgRoot D:\pgsql17 -OutputPath (Join-Path $env:TEMP 'yovision-t014-formal-final.json')
```

调试可显式传入 `-ObservationMinutes 1`，但输出固定标记 `formal_eligible=false`，不能作为正式验收。

脚本在系统临时目录生成媒体、Sense 二进制、凭据文件和 PGDATA，只绑定随机回环端口；migration 读取 `001`～`011` 并重复回放，不读取或修改 `D:\pgsql17\data`。结果 JSON 不包含 token、DSN、临时端口、设备 ID、Path/source URI 或凭据引用。正式退出后复查 session、FFmpeg、MediaMTX 和 Sense 数量均为 0，本机现有 5432 listener 前后未变化。

## 4. 功能与时序结果

| 门禁 | 正式结果 |
| --- | ---: |
| 16 个独立 publisher 就绪 | 7.6 s |
| 首轮 enable batch | `succeeded`，16 项，请求 0.041 s |
| 首轮 enable 收敛 | 3.1 s |
| 第 17 路 enabled | 拒绝，`quota_exceeded` |
| disable batch | `succeeded`，16 项，请求 0.015 s |
| disable 收敛 | 1.0 s |
| 第二轮 enable batch | `succeeded`，16 项，请求 0.046 s |
| 第二轮 enable 收敛 | 3.1 s |
| 配置 Path | `16 → 0 → 16` |
| 四路故障检测 | 1.0 s，影响 4 路，其余 12 路在线 |
| 四路恢复 | 5.1 s，最终未收敛 0 |

批量启停使用真实 `/api/v1/sites/{site_id}/devices:batchDesiredState`，每轮提交前重新读取各设备最新 ETag；不能用创建响应中的旧 ETag 与后台调和竞速。每轮 operation 必须为 `succeeded` 且 16 个逐项结果全部成功。

## 5. 30 分钟稳定性与资源观测

| 指标 | 正式结果 |
| --- | ---: |
| 观察时长 | 1800.1 s |
| 采样节拍 / 样本 | 10 s / 180 |
| 最大未收敛数 | 0 |
| 最终未收敛数 | 0 |
| 最终在线 Path | 16 |
| 聚合入站码率 | 15.443 Mbps |
| 入站帧错误增量 | 0 |
| Sense CPU 总时间 | 5.594 s |
| Sense working set 峰值 | 69.99 MiB |
| Sense private bytes 峰值 | 57.58 MiB |
| Sense handle 峰值 | 228 |
| 生产 MediaMTX CPU 总时间 | 26.812 s |
| 生产 MediaMTX working set 峰值 | 45.27 MiB |
| 生产 MediaMTX private bytes 峰值 | 79.23 MiB |
| 生产 MediaMTX handle 峰值 | 295 |
| PostgreSQL 业务库连接峰值 | 3 |
| PostgreSQL 数据库大小 | 8.90 MiB |

归一化 CPU 平均值与峰值在 24 逻辑处理器主机上四舍五入到三位小数后为 0.000%，因此报告保留进程 CPU 总秒数作为低负载证据；不能据此推导通用硬件下限。

## 6. 失败记录与工具修正

正式结论只取最后一次完整成功运行。研发过程中保留以下失败，不拼接为成功证据：

1. MediaMTX 发布 ZIP 与解压后 EXE 的 SHA-256 不同，脚本分别冻结并校验两者。
2. disabled 设备不消耗视频通道；第 17 路门禁改为在 16 路 enabled 后创建 enabled 设备，符合实际配额语义。
3. PowerShell 读取 `application/problem+json` 时可能得到 byte array；脚本显式按 UTF-8 解码后校验稳定错误码。
4. 把 `pg_ctl start` 接入 PowerShell 输出管道会让 PostgreSQL 继承管道句柄并阻塞；启动改为直接执行并检查退出码。
5. Windows 退出时 `sense-api.exe` 曾短暂持有文件锁；清理改为共享截止时间内终止全部进程、完成异步输出读取、释放 `Process` 句柄并重试删除。
6. “固定睡 10 秒再查询”会把查询耗时累计进采样间隔，30 分钟不足 180 个样本；改为按绝对时间点调度第 1～180 个样本。
7. 根目录 Go launcher 为 1.23.0，但 `Sense/go.mod` 冻结并实际构建使用 1.26.5；版本证据改为在 `Sense/` 模块上下文读取。
8. 首轮 batch 曾复用创建响应 ETag，与后台调和的资源版本更新竞速；现在三轮 batch 都在提交前读取最新 ETag，失败诊断只输出状态/错误码计数。

每次失败都没有生成正式成功 JSON，且相关临时 PostgreSQL、媒体和 Sense 进程已停止，单次 session 已清理。

## 7. 后续验收

- T-007 仍需至少 5 条独立真实摄像头上游与现场网络，才能形成真实多路故障隔离和生产试点证据。
- T-013 等客户网络拓扑、地址规划和部署权限具备后，再验证 WireGuard 与断网补传。
- 64/128 路必须在后续任务中分别验证媒体分片、带宽、解码、AI/GPU、证据存储和单分片故障域；本报告不外推这些结论。
- 进入 M3 前应优先冻结并实现 Bell 事件不可变存储，以及 Sense Outbox 到 Bell 全局审计的 relay 边界。