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. 运行方法与安全边界

从仓库根目录执行：

./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. 失败记录与工具修正

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

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

7.0 KiB Raw Blame History Unescape Escape