评估内存峰值与安全冗余量，核心是厘清常驻内存、上下文/会话内存、系统与守护开销三类来源，以99分位瞬时峰值为基准，按业务并发叠加后乘1.3–1.5倍冗余，并通过cgroup硬限与stress-ng压测验证余量是否充足。
评估业务运行中的内存峰值与安全冗余量，核心不是看启动时占多少，而是抓住“谁在什么时候占、占多少、会不会堆积”这三个关键点。真实压测和线上监控数据比任何经验公式都可靠。
分清三类内存占用来源
很多OOM事故，根源是把常驻内存和波动内存混为一谈：
- 常驻内存：Agent框架、JVM基础堆、向量库加载、数据库连接池初始化等，服务一启动就固定吃掉。例如LangChain+Chroma常驻约1.2GB，Java进程基础非堆（元空间+线程栈）通常200MB–1GB。
- 上下文/会话内存：对话历史、工具返回内容、推理中间缓存、PDF解析文本等，随单次任务时长和复杂度线性增长。一个活跃30分钟的AI Agent可能额外增加800MB+；若支持多轮LLM调用+文件处理，单次任务峰值可突破2GB。
- 系统与守护开销：Linux内核、sshd、logrotate、监控代理、容器运行时等，不随业务请求变化，但稳定占用500MB–1GB，必须计入总规划。
用99分位峰值代替平均值
平均内存使用率毫无参考价值。真正决定是否OOM的是瞬时最高点：
- Web应用（如Spring Boot）：取Full GC前老年代瞬时峰值，而非GC后剩余空间；建议该值 × 1.3～1.5，覆盖突发请求+会话堆积。
- 数据库（MySQL/PostgreSQL）：计算innodb_buffer_pool_size + 连接数 × 每连接临时缓冲（如MySQL per-connection buffer约2MB），再加20%用于排序、临时表、DDL操作。
- AI Agent服务：记录单次最长会话的内存轨迹（用/proc/[pid]/status或pmap -x持续采样），取最高RSS值；若支持N并发，则按N×峰值叠加后，额外+30%防上下文雪崩（例：5并发 × 峰值1.8GB = 9GB → 建议配12GB）。
设置硬限并验证余量是否真够用
只算不控等于没规划。余量必须通过机制落地：
- 在Docker或Kubernetes中，必须显式设置memory.limit等于你规划的总内存上限（如12GB），否则OOM Killer不会主动干预，宿主机可能被拖垮。
- 上线前用stress-ng --vm 1 --vm-bytes 80% -t 5m模拟压力，观察服务响应延迟是否突增、HTTP 5xx是否上升、日志是否出现java.lang.OutOfMemoryError: Java heap space或container killed due to OOM。
- 业务高峰时段执行cat /sys/fs/cgroup/memory/docker/*/memory.usage_in_bytes | numfmt --to=si，确认实际使用长期稳定在规划值的70%以下——超过80%说明余量已吃紧，需重新测算。
