﻿P10-13 云端 2GB 内存下的资源预算与优化（必须遵守）

## 用户约束（2026-10-20 10:00）
「我用的是 2G 的服务器，内存比较小，所以优化这块你也要做好。」

## 服务器现状（实测）
```
已有常驻：nginx(80/443)、MySQL(3306)、HermesAgent 多个 python、BaradAgent、
          sgagent、tat_agent、宝塔相关、以及 8000/8001/8765/8790 四个 python 服务
总内存只有 2GB —— 余量很小，任何新服务都必须"轻"
```

## 一、硬性预算（写进代码，超了就降级）
| 项 | 上限 |
|---|---|
| `bridge_worker.py` 常驻 RSS | **≤ 40 MB** |
| 单次任务峰值 RSS | ≤ 120 MB |
| 并发执行任务数 | **1**（串行，绝不并行） |
| 轮询间隔 | ≥ 30 秒（不许 1 秒轮询） |
| 日志文件 | 单文件 ≤ 5 MB，保留 3 个滚动 |
| index.json | ≤ 500 条，超出按时间淘汰最旧 |

## 二、实现要求
1. **只用标准库**：`os/json/time/pathlib/sqlite3/socket/http.server`。
   **禁止**在服务器侧 import pandas / numpy / matplotlib / 任何大库
   （本机可以，云端不行）。
2. 任务执行用 **子进程**（`subprocess`）跑具体脚本，跑完立即回收；
   绝不在常驻进程里加载业务代码（避免长期占内存）。
3. 处理大文件（NC 几十 MB）要**流式**读，不许一次性 read() 全文件进内存；
   逐行统计，边读边算。
4. 内存自检：每轮开始读一次自身 RSS（`/proc/self/status` 或 `psutil` 不用，用 ctypes 读取，
   或直接读 Windows 的 `Get-Process`），超过 40MB 写日志并 gc。
5. 资源看门狗 `GET /v1/system/status`（我们自己的小服务）返回：
   `{"mem_total_mb":2048,"mem_avail_mb":?, "our_rss_mb":?, "queue_len":?, "ok":true|false}`
   `mem_avail_mb < 200` 时返回 `ok:false` 并拒绝新任务（明确错误，不硬撑）。
6. 与 Hermes 共存：**不启动第二个 Hermes**、不改 Hermes 的并发设置、
   不在同一时间跑多个 NX 任务（NX 只在本地，本就唯一）。

## 三、优化手段（按性价比排序）
1. 串行队列（最省内存，且加工本就串行）—— **必做**
2. 流式解析 NC（不整文件入内存）—— **必做**
3. 结果只存摘要 + 文件路径，不把内容塞进 JSON —— **必做**
4. 定期清理 `inbox/`、`outbox/` 里 7 天前的临时文件到 `archive/`
5. 日志按大小滚动，不写 debug 级全量
6. 若 `mem_avail_mb < 200`：暂停 worker、只保留接收队列（等内存恢复再干活）

## 四、验收（实测）
1. 贴出 `bridge_worker.py` 启动后 5 分钟的 RSS 实测值（要求 ≤40MB）
2. 贴出处理一个 20MB+ NC 时的峰值内存（要求 ≤120MB，并证明是流式，不是全读）
3. 贴出 `/v1/system/status` 的真实返回
4. 构造 `mem_avail_mb < 200` 场景（可用参数模拟），贴出"拒绝新任务"的日志与返回
5. 贴出日志滚动与 index 淘汰的效果（构造 600 条验证淘汰到 500）
6. 门禁全绿 + 新增 .py 含 `P2-02 控制台编码护栏`

## 约束
- 不改 Hermes 核心、不装软件、不改系统环境变量
- 服务器侧禁止引入大依赖
- 完成后写 `状态\P10-13.done.json`
