top与htop的cpu使用率常不一致，因top默认3秒采样、归一化至单核（如4核满载为400%），而htop实时刷新且默认显示内核线程；需统一设置才可比对。
看 CPU 使用率，top 和 htop 显示的为什么经常对不上
因为 top 默认按 3 秒采样周期计算平均值，而 htop 实时刷新且默认不隐藏内核线程；更关键的是，top 的 %CPU 是归一化到单核的（比如 4 核机器满载显示 400%），而部分终端或配置可能误设为“总和模式”导致数值膨胀。
- 用
top -b -n1 | head -20抓快照比肉眼盯屏更准，避免滚动干扰 -
htop按F2→ “display options” → 关掉 “Hide kernel threads” 才能和top对齐进程可见范围 - 真正要看负载压力，别只盯
%CPU，优先看load average（1/5/15 分钟）是否持续 > CPU 核数
内存指标里，free -h 的 available 列到底能不能信
能信，而且比 free 或 used 更反映真实可用余量。available 是内核估算的、无需触发 OOM killer 就能立刻分配的内存，它已扣除了可回收缓存（如 page cache）、slab 中可收缩部分，还预留了低水位缓冲。
- 如果
available接近 0，但free还剩 2G，别侥幸——系统很可能已经开始频繁回收 cache，响应延迟会上升 -
MemAvailable:在/proc/meminfo里对应同一数值，脚本监控建议直接读这行，比解析free输出更稳定 - 某些老内核（available，此时
free + buffers + cached是粗略替代，但高估严重，尤其在有大量 tmpfs 或 dentries 的场景
iostat -x 1 中 %util 长期 100% 就代表磁盘瓶颈吗
不一定。该值只是设备忙时间占比，SSD、NVMe 或多队列设备下，%util 失去意义——它们能并行处理数百请求，%util == 100% 只说明队列始终非空，不代表 I/O 延迟高或吞吐见顶。
- 重点看
await（I/O 平均等待毫秒）和r_await/w_await：持续 > 10ms（HDD）或 > 1ms（SSD）才真有问题 -
avgqu-sz（平均队列长度）比%util更反映并发压力，> 1 表示请求已在排队 - 用
cat /sys/block/nvme0n1/stat看rqm（合并请求数）突增，常是上层应用小块随机写导致，和%util无关
网络丢包排查，为什么 ping 看着正常，curl 却超时
因为 ping 走 ICMP，路径可能和 TCP 流量不同（尤其跨运营商或策略路由），且 ICMP 包常被限速或优先级调低；curl 超时更可能是 TCP 握手失败、SYN 包被丢、或防火墙拦截了特定端口。
- 先跑
tcpdump -i eth0 port 443（替换成目标端口），看 SYN 发出去没、有没有 SYN-ACK 回来 - 用
ss -i查当前连接的retrans（重传次数）和rtt（往返时间），> 5 次重传基本确认链路不稳定 -
curl -v https://example.com的输出里，卡在 “Connected to” 后，大概率是服务端未响应 SYN-ACK，不是 DNS 或路由问题
实际监控中，最常被忽略的是指标之间的关联性——比如 CPU %sys 突升伴随 iowait 下降，往往不是 CPU 问题，而是内核在密集处理中断（如网卡软中断），这时得去看 /proc/interrupts 和 softirqs 统计。