边缘计算为何越跑越占内存

很多节点上线头几天一切正常，跑到一两个月后才开始变慢、重启或误报内存不足。边缘计算里的内存风险，常见的不是一次性爆掉，而是碎片和小泄漏长时间叠加后把系统推到边界。

碎片问题经常被平均占用掩盖。推理链会反复申请不同尺寸的临时张量，采集层又持续创建和释放变长报文，日志系统还在偶发拼接大字符串；这些对象单次都能正常释放，但堆区逐渐被切成很多不连续小块。监控上看总可用内存还不少，需要连续页的大缓冲却再也拿不到，最终表现成相机初始化失败、DMA 映射失败或某次热更新突然起不来。

泄漏更隐蔽，因为它未必发生在业务对象上。映射句柄、文件描述符关联缓冲、图形驱动上下文、推理会话缓存，很多资源挂在库或内核扩展里，应用层对象早已释放，底层占用却还没回收。现场团队看到的通常是 RSS 缓慢爬升，重启后又恢复，于是误以为只是系统老化，真正原因却是某条异常路径少了一次 unmap 或 close。

对象池也会把问题伪装成优化。为了减少频繁分配，很多节点把报文、帧缓存或张量包进池里复用；但若池上限只增不减，高峰时扩出来的对象会长期留存，低峰期也不回收。池本来是为了抑制抖动，设计不当却会把偶发高水位固化成常驻内存。对长期在线设备，池不仅要能扩，还要能在安全窗口收缩。

内存诊断不能只靠一次快照。真正有用的是长时探针：定期记录堆区分配分布、最大连续块、主要缓存命中率和句柄数量，并和业务事件对齐。若某类任务执行后句柄数台阶式上升但不回落，基本就能锁定泄漏路径；若总占用平稳而连续页越来越小，更多是碎片在作祟。没有时间维度，团队很容易把两类问题混为一谈。

必要时还应把分配器统计暴露出来，确认问题出在应用对象、运行时缓存，还是底层 allocator 的碎片策略本身。

页回收策略也会影响体感故障。系统在内存紧张时触发回收、压缩或交换，看似还没 OOM，却已经把实时线程拖慢。推理和采集一边忙着抢页，一边又被后台回收打断，尾延迟就会突然变大。更稳的方式，是给关键链路预留固定工作集，把可再生缓存设硬上限，宁可提前丢弃非关键数据，也不要等回收风暴来了再被动挨打。

热更新和插件加载要特别小心残留对象。新版本模块加载后，旧版本若只卸掉代码、不清理关联缓存和工作线程，内存会在每次更新后多留一层壳。现场很难马上察觉，因为单次上涨不大，但半年后会累积成真实风险。把更新前后的内存基线做成强制对比，能比用户投诉更早发现问题。

治理内存的关键不是把所有缓存都关掉，而是让每一类占用都有边界、有释放时机、有观测点。只要碎片趋势和泄漏来源能被提前看见，修复成本通常远低于现场宕机之后再补救。

长期在线不是把系统放着不动，而是持续证明资源仍在可控范围。把碎片和泄漏都拉进常态监控后，边缘计算才不会在最熟悉的现场被慢性内存问题拖垮。