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模拟混合负载，观察系统响应和资源水位变化
