CPU使用率持续高于90%通常表明有进程持续抢占CPU资源，可能引发响应延迟或被OOM Killer终止；需先区分us（用户态）高还是sy（系统态）高，再用top -H、ps -T、perf top等工具定位线程与热点函数。
CPU使用率持续高于90%意味着什么
这通常不是瞬时抖动，而是有进程在持续抢占CPU资源，可能引发服务响应延迟甚至进程被OOM Killer终止。别急着杀进程，先确认是用户态（us）还是系统态（sy）高——us高大概率是应用逻辑问题或死循环；sy高则要查系统调用、锁竞争或频繁上下文切换。
- 用
top -H查看线程级占用，配合ps -T -p定位具体线程 -
perf top -g可定位热点函数（需安装perf工具） - 注意区分“平均负载（load average）”和“CPU使用率”：负载高但CPU使用率低，可能是大量进程在等待I/O
内存中的cached与buffers容易被误判为“被占满”
free -h 输出里的 cached 和 buffers 是内核可随时回收的内存，不等于真实压力。真正危险的是 available 值持续低于总内存10%，或 SwapUsed 持续增长。
- 关注
/proc/meminfo中的MemAvailable字段，比free的估算更准 -
cat /proc/查单个进程实际物理内存占用/status | grep -E "VmRSS|VmSize" - 如果
kswapd0进程CPU持续升高，说明内核正在频繁回收内存，此时PageOut和pgmajfault计数会明显上升
磁盘I/O等待（%iowait）高但util接近100%的典型矛盾
iostat -x 1 中 %iowait 高而 %util 接近100%，说明设备确实饱和；但如果 %iowait 高而 %util 很低（比如
- 重点看
await（平均IO响应时间）是否突增，>100ms 通常已异常 -
avgqu-sz（平均队列长度）持续 >1 表示IO请求积压，结合svctm（服务时间）判断是设备慢还是请求太多 - SSD场景下
%util失效（因并行能力强），应优先看r/s、w/s和rkB/s、wkB/s是否触及硬件上限
网络连接数监控不能只看netstat的ESTABLISHED
netstat -an | grep :80 | grep ESTABLISHED | wc -l 容易漏掉TIME_WAIT、SYN_RECV，也忽略连接分布。真正要预警的是：单IP连接数突增（可能被CC）、本地端口耗尽（net.ipv4.ip_local_port_range 被打满）、或 netstat -s | grep -i "packet receive errors" 显示接收错误上升。
- 用
ss -s看全局连接统计，比netstat更快更准 - 查特定端口连接分布：
ss -tn src :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10 - 观察
/proc/net/sockstat中sockets: used是否持续增长，避免内核socket内存耗尽
watch -n 1 'echo "== CPU =="; mpstat 1 1 | grep all; echo "== MEM =="; free -h; echo "== IO =="; iostat -x 1 1 | grep nvme0n1; echo "== NET =="; ss -s'
监控不是堆指标，而是建立因果链：比如CPU高 → 查哪个进程 → 查它在做什么系统调用 → 查它访问的文件或网络端点是否异常。很多“异常”其实是上游服务慢导致本地线程堆积，最终表现为本地CPU或内存升高。这点最容易被忽略。
