Linux卡顿需分层排查：先看CPU（us/si/hi异常）、再查内存（available
Linux系统卡顿通常不是单一原因导致，而是CPU、内存、磁盘I/O或网络等某类资源达到瓶颈后的综合表现。快速定位需结合实时监控与历史趋势，优先排查最可能的瓶颈点。
看CPU是否过载
CPU持续100%不等于一定有问题，但若用户态（us）长期高于70%，或软中断（si）/硬中断（hi）异常升高，说明程序或驱动在频繁抢占CPU。用 top 或 htop 观察排序后前几位进程的CPU占用；进一步用 pidstat -u 1 查看每秒各进程的CPU使用变化。若发现某个进程周期性飙高，可用 perf top -p PID 定位热点函数。
查内存是否耗尽并触发Swap
真正危险的是可用内存（free + cache可回收部分）持续低于5%且Swap使用量上升。运行 free -h 看 available 列和 swap used；再用 cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree" 核对。若Swap被大量使用，配合 vmstat 1 观察 si（swap in）和 so（swap out）是否持续非零——这会导致严重延迟。此时应检查是否有进程异常驻留（如Java堆配置过大）、或内核内存泄漏（dmesg | tail 查OOM或slab警告）。
盯磁盘I/O是否成为瓶颈
即使CPU和内存宽松，iowait高（top中wa列＞20%）+ IOPS或吞吐接近设备极限也会让系统响应迟滞。用 iostat -x 1 关注：
• %util 接近100% 表示设备忙饱和
• await 显著高于正常值（SSD一般＜10ms，HDD＜50ms）说明请求排队严重
• r/s 和 w/s 结合设备标称IOPS判断是否超限
再用 iotop -o 找出实际读写大户，注意区分后台日志刷盘、数据库同步、临时文件拷贝等行为。
留意内核与服务级干扰
某些卡顿并非资源不足，而是调度或锁竞争引发：
• uptime 显示load average远高于CPU核心数（如16核机器load达30），但top里CPU idle仍高 → 可能大量进程处于D（不可中断睡眠）状态，常见于磁盘或NFS挂起
• ps auxf 查看是否有进程树深度异常、子进程僵死
• systemctl list-jobs 检查是否有长时间pending的unit任务阻塞启动流程
• 时间跳变（timedatectl status）或NTP频繁校正也可能引发短时调度抖动
