Generated by Answer me with HTML 0.5.11 · 2026-11-10 14:32 · ★ Star on GitHub

运行内存账本与优化清单

物理 1708MB · 可用 480MB · 网关基线 597MB，重启无效

source/proc/meminfo · smaps_rollup · gateway.log · hy-memory db
A

结论

可用 480MB，缓存不能变成可用内存

物理内存 1708MB，已用 1227MB，可用 480MB。 文件缓存 581MB 已经算在可用里，清缓存只让 free 数字变大。 网关 597MB 是结构性基线。13:43 刚重启，14:24 又到 577MB。 真正能压的只有进程对象，合计 150–250MB，且都要付功能代价。

物理内存
1708 MB
已用
1227 MB
可用
480 MB
文件缓存
581 MB
Swap 已用
571 MB
内存压力
0.18 %
B

进程账本

进程 RSS 占比 可动性
hermes 网关 597 MB 35.0 % 结构性，只能减功能
hy-memory 237 MB 13.9 % 可压缩，需重建索引
飞书卡片 runner 92 MB 5.4 % 可关，损失卡片
mihomo 45 MB 2.6 % 必需
caddy 24 MB 1.4 % 必需
系统与内核 slab 73 MB 4.3 % 多数不可回收
合计 1068 MB 62.6 % 缺口为页表与共享内存

hy-memory 另有 148MB 在 swap 里，工作集约 385MB。 它 13:40 触发过一次记忆预取超时 8 秒，就是换入延迟。

C

网关 597MB 拆解

最大单块匿名映射
145 MB
Python heap 主区
112 MB
库文件映射合计
83 MB
线程数
51
打开文件描述符
72
state.db 打开句柄
9

匿名内存约 520MB，是 Python 运行时对象。 不是数据库缓存：state.db 的 mmap_size 为 0，每连接缓存仅 2MB。 也不是库太重：Python 与依赖映射合计只有 83MB。 所以只能减对象，也就是减插件、减工具、减会话。

插件与技能现状

启用插件 7 个：disk-cleanup、feishu-card、hfc 依赖、hy-memory、mcp-serve、feishu、web。 技能共 227 个，已禁用 82 个，仍有 145 个参与索引。

D

可优化项

措施 预期效果 代价 风险 优先级
重建 hy-memory 向量集合 省 40–70 MB 检索短暂变慢 中，先备份 P1
清 8 月 pipeline_logs 8297 条 省 5–10 MB 无 低 P1
关 disk-cleanup / mcp-serve 省 20–40 MB 失去对应功能 低，需重启 P1
飞书卡片 runner 改纯文本 省 92 MB 失去卡片 中，体验降级 P2
state.db VACUUM 磁盘省大于 100 MB 需停网关 中，内存几乎不变 P2
关 at-spi / polkitd 省 5 MB 无 可忽略 P3
清 inode 与 dentry 缓存 free 增 30–45 MB 不增可用内存 低，IO 抖动 可不做
agent_cache 阈值 500→300 仅多会话生效 冷启动变慢 低，当前单会话无效 可不做

hy-memory 存了 2946 条向量却占 106MB，平均 36KB 一条。 bge-m3 的 1024 维向量只需 4KB，超出部分是索引与冗余。 这是全表里唯一能省两位数、又不砍功能的项。

不要做 swapoff

swap 已用 571MB，可用内存只有 480MB。 执行 swapoff 会把这 571MB 拉回物理内存，直接触发 OOM。 当前压力 0.18%，swap 抖动不构成问题。

E

执行顺序

  1. 已确认网关基线597MB 属结构性，重启无效
  2. P1配置瘦身关两个插件，清旧日志，省 25–50MB
  3. P2数据重建备份后重建向量集合，省 40–70MB
  4. P3功能取舍飞书卡片改纯文本，省 92MB