CPU 与内存容量评估需结合负载类型、系统指标及联动效应：计算密集型重单核性能，高并发重多核；内存看 available 而非 free，警惕 OOM；二者失配会引发 swap 或上下文切换激增；建议 CPU 峰值≤70%、内存预留 15%~20%，并做压测验证。
CPU 需求评估：看负载类型，别只盯核心数
评估 CPU 容量不能只看物理核心数量，关键要看业务负载特性。计算密集型任务（如视频转码、科学计算）需要高主频和强单核性能；而高并发 Web 服务或数据库则更依赖多核并行处理能力。
建议方法：
- 用 top 或htop观察 %us（用户态） 和%sy（内核态）是否持续高于 70%，长期超 85% 说明存在瓶颈
- 检查load average（1/5/15 分钟），若值长期大于逻辑 CPU 总数，表明任务排队严重
- 对 Java、Node.js 等应用，注意 GC 或事件循环阻塞可能造成伪高负载——需结合 jstat 或perf进一步定位
内存容量规划：留足系统开销，警惕隐性消耗
内存不是“够用就行”，Linux 会主动缓存文件（buffers/cache），但真正危险的是 可用内存（available）持续低于 10% 或频繁触发 OOM Killer。
实操要点：
- 用 free -h 重点看 available 列，而非 free 列（后者含可回收缓存）
- 数据库类服务（MySQL、PostgreSQL）需预留足够buffer pool / shared_buffers，通常设为总内存的 50%~75%，但需避开系统保留（至少 2GB 给 OS）
- 警惕内存泄漏：用 ps aux –sort=-%mem | head -10 查常驻内存大户；长期运行的 Python/Java 进程建议加memory limit（cgroups 或 systemd 配置）
容量联动分析：CPU 与内存不是孤立指标
很多性能问题源于二者失配。例如：内存不足导致频繁 swap，磁盘 I / O 激增，反过来拖慢 CPU 响应；又如线程数过多引发上下文切换暴涨，CPU 忙于调度而非计算。
快速交叉验证：
- 执行 vmstat 1 5，关注si/so（swap in/out） 是否非零，cs（context switch）是否突增（>10k/ s 需警惕）
- 用 pidstat -u -r 1 同时看各进程的 CPU 使用率和内存占用，识别“高 CPU+ 低内存”或“低 CPU+ 高 RSS”的异常组合
- 容器化环境要额外考虑：cgroup memory limit 设置过小会触发 OOM，而 CPU quota 设置过严可能导致进程等待，需结合 docker stats 或cAdvisor监控实际限制效果
预留与弹性：为增长和突发留出安全边际
生产环境不推荐把 CPU 或内存利用率压到 90% 以上。突发流量、日志轮转、备份任务都可能瞬时拉升资源消耗。
- CPU 建议峰值利用率控制在 70% 以内，突发可容忍短时 85%，但需有自动扩缩容机制（如 K8s HPA）或告警响应流程
- 内存建议预留 15%~20% 作为 buffer，避免因 page cache 收缩或进程 fork 失败导致服务异常
- 上线前做轻量级压测：用 stress-ng –cpu 4 –io 2 –vm 2 –vm-bytes 1G 模拟混合负载，观察系统响应和资源水位变化
