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或内存升高。这点最容易被忽略。

# linux  # 堆  # 循环  # sort  # print  # 内存占用  # 热点  # linux系统  # ios  # ai  # 工具  # 端口  # 做什么  # 更快  # 再用  # 它在  # 是有  # 太多  # 连接数  # 持续增长  # 的是  # 线程  # 只看