上一篇沿网络链路定位超时本篇把视角转回主机。性能分析不是找一个“神奇指标”而是先定义用户可见的延迟和吞吐再用 CPU、内存、磁盘、网络四类资源证据解释变化。一、痛点高负载不等于 CPU 忙Linux load average 统计可运行任务以及不可中断睡眠任务后者常在等待磁盘或某些内核资源。因此 load 高而 CPU idle 也高可能是 I/O 堵塞在 2 核与 64 核机器上load 8 的含义完全不同。先按逻辑 CPU 数归一化再查看运行队列、iowait 和每个进程状态。单次top截图价值有限。性能是时间序列需要基线、发生窗口和对照。CPU 使用率 90% 若吞吐稳定可能是高效利用平均 30% 也可能每隔一分钟打满并造成尾延迟。监控至少保留 p50、p95、p99 延迟而不是只看平均值。二、原理利用率、饱和度与错误对每项资源问三件事利用率有多高、是否有等待队列、是否发生错误。CPU 的饱和可看运行队列和 PSI内存看可用量、回收、swap in/out 与 OOM磁盘看延迟、队列和设备利用率网络看丢包、重传和队列。百分比必须结合速率和硬件能力解释。Linux 会用空闲内存做页缓存“free 很少”不是内存不足MemAvailable更接近在不大量换页时可供应用使用的估计。Swap 使用非零也不必立刻报警持续si/so与延迟上升才值得关注。OOM 发生后应查 cgroup 和内核日志因为容器可能在主机尚有余量时触及自己的上限。PSIPressure Stall Information衡量任务因 CPU、内存或 I/O 资源不足而停顿的时间比纯利用率更接近饱和。some表示至少部分任务受阻full表示所有非 idle 任务同时受阻。它适合触发持续压力告警但阈值要依据业务基线。三、实现采集低开销性能快照下面脚本连续采样/proc、vmstat、磁盘和 PSI把时间戳与证据放到同一目录。它不安装软件存在iostat和pidstat时自动增加细节。输出目录权限收紧因为进程参数可能包含内部信息。#!/usr/bin/env bashset-euopipefailduration${1:-30}interval${2:-5}[[$duration~^[0-9]$$interval~^[0-9]$]]||exit2((durationintervalinterval0))||exit2stamp$(date-u%Y%m%dT%H%M%SZ)out${TMPDIR:-/tmp}/perf-snapshot-$stampinstall-d-m0700$outuname-a$out/uname.txtlscpu$out/lscpu.txtfree-w$out/memory.txtcat/proc/loadavg$out/loadavg.txtforresourceincpu memory io;dotest-r/proc/pressure/$resourcecat/proc/pressure/$resource$out/psi-$resource.txtdonesamples$((duration/interval))vmstat-w$interval$samples$out/vmstat.txtpids($!)ifcommand-viostat/dev/null21;theniostat-xz$interval$samples$out/iostat.txtpids($!)fiifcommand-vpidstat/dev/null21;thenpidstat-durh$interval$samples$out/pidstat.txtpids($!)fiforpidin${pids[]};dowait$pid;donedmesg--ctime2/dev/null|tail-n100$out/dmesg-tail.txt||trueechosnapshot$outsamples$samplesinterval${interval}s运行输出snapshot/var/tmp/perf-20260818T022000Z samples6 interval10s下面的独立脚本从/proc/stat两次采样计算整机 CPU busy 百分比。它展示计数器差分原理累计值本身没有意义必须在时间窗口内求差。结果包含所有 CPU 时间类型生产分析仍应结合mpstat看每核与 steal。#!/usr/bin/env bashset-euopipefailinterval${1:-1}read_cpu(){localcpu usernicesystem idle iowait irq softirq steal guest guest_niceread-rcpu usernicesystem idle iowait irq softirq steal guest guest_nice/proc/statlocalidle_all$((idleiowait))localtotal$((usernicesystemidleiowaitirqsoftirqsteal))printf%s %s\n$total$idle_all}read-rtotal1 idle1(read_cpu)sleep$intervalread-rtotal2 idle2(read_cpu)delta_total$((total2-total1))delta_idle$((idle2-idle1))((delta_total0))||{echo采样间隔无有效计数2;exit1;}busy$((100*(delta_total-delta_idle)/delta_total))printfcpu_busy%d%% interval%ss logical_cpus%s\n\$busy$interval$(getconf _NPROCESSORS_ONLN)printfloadavg%s\n$(cut-d -f1-3 /proc/loadavg)printfmemory_available_kb%s\n$(awk/MemAvailable/ {print $2}/proc/meminfo)运行输出cpu_busy7% interval1s logical_cpus4 loadavg0.18 0.22 0.20 memory_available_kb6123480四、踩坑观测工具也有成本高频抓包、全量调用栈和详细审计会改变被测系统。先用低开销计数器定位资源再缩小到进程、线程和调用路径。strace适合确认系统调用阻塞却可能显著降低高频进程性能分析生产前先在预发布测开销并限定 PID 与持续时间。虚拟机的 steal 表示 CPU 时间被宿主机拿走容器的 CPU throttling 则来自 cgroup 配额二者不会只靠进程%CPU解释。磁盘%util100在并行设备上也不直接等于达到最大吞吐应结合 await、队列深度和厂商规格。五、验证用假设驱动实验形成可证伪假设“延迟上升由磁盘写饱和导致”然后寻找同时发生的写吞吐、await、队列和应用调用证据。一次只改变一个变量在相同流量下比较。扩容能缓解资源不足却可能掩盖锁竞争、泄漏和无界队列修复后仍要做容量测试确认性能随资源或并发合理变化。有了可量化基线下一篇将把重复检查变成可靠自动化设计幂等脚本、锁、超时、退出码和 systemd/cron 调度边界并从失败路径验证。参考来源Linux KernelPSIproc_loadavg 手册vmstat 手册Brendan GreggLinux Performance 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《Linux 服务器运维实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。