真实压力看mpstat %usr+%sys是否持续>70%及free -h中available是否长期低于总内存15%；I/O瓶颈需结合await、avgqu-sz判断；资源争用与应用低效需用perf/pidstat分析线程级行为；容量规划须关注内核参数、swap策略及cgroup差异。
怎么看当前 CPU 和内存的真实压力？
别只看 top 里那个平均负载（load average）——它反映的是就绪队列长度，不是 CPU 使用率。真实压力要看 mpstat -P ALL 1 的 %usr + %sys 是否持续 >70%，以及 free -h 中 available 列是否长期低于总内存的 15%。
注意：Linux 的 cached 内存可被快速回收，不等于“被占用”；真正危险的是 available 持续逼近 0，或 swpd 在 vmstat 1 中非零且增长。
-
mpstat要装sysstat包，CentOS/RHEL 默认不带 -
free -h的available字段在内核 3.14+ 才准确，老系统得用free -m算Mem: free + buffers + cached - 短时 spike 不代表容量不足，需连续观察 15 分钟以上趋势
磁盘 I/O 瓶颈不能只盯 iostat %util
%util 接近 100% 只说明设备忙，但不等于慢——NVMe 盘可能 100% util 下延迟仍 iostat -x 1 的 await（单次 I/O 平均耗时）和 r_await/w_await：
- SSD：持续 >10ms 需警惕
- HDD：持续 >30ms 通常已成瓶颈
-
avgqu-sz>1 表示请求排队，结合高await基本可判定 I/O 压力过大
另外，iotop 能定位具体进程，但默认只显示活跃 I/O 进程，加 -a 参数才统计所有线程累计值。
如何判断是资源争用还是应用自身低效？
用 perf top -p 或 pidstat -t -p 看线程级行为。如果某个 Java 进程 %CPU 高但 perf 显示大量时间花在 Unsafe_Park 或 ObjectSynchronizer::fast_enter，大概率是锁竞争，不是 CPU 不够；若 Python 进程 %CPU 高但 perf record -g -p 显示集中在 PyEval_EvalFrameEx，更可能是算法或 GC 问题。
- Java 应用优先查
jstat -gc看 GC 频率和停顿时间 - Python 查
ps -o pid,ppid,comm,%cpu,%mem -C python确认是否多进程重复加载大模型 - 避免直接 kill 掉高 CPU 进程——先
strace -p看系统调用分布-c
容量规划时最容易被忽略的三个点
一是内核参数限制：比如 fs.file-max 和进程级 ulimit -n 不匹配，导致高并发服务在连接数刚到 65535 就报 Too many open files；二是 swap 使用策略：即使禁用 swap（swapoff -a），也要确认 vm.swappiness=1，否则内存紧张时内核仍可能换出匿名页；三是容器环境下的 cgroup v1/v2 差异：docker stats 显示的内存使用可能不含 page cache，而 cat /sys/fs/cgroup/memory/.../memory.usage_in_bytes 才是真实上限依据。
历史数据必须保留至少 30 天，用 sar（来自 sysstat）比用 Prometheus 自建采集更轻量、更可靠——尤其在资源吃紧的边缘节点上。
