真实压力看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 1 看线程级行为。如果某个 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 自建采集更轻量、更可靠——尤其在资源吃紧的边缘节点上。

# linux  # 大模型  # ios  # ai  # app  # docker  # js  # centos  # java  # python  # linux系统