Linux服务器变慢需按CPU、内存、磁盘I/O、网络顺序排查：先用top/htop查CPU负载与进程，free/vmstat查内存与swap，iostat/iotop查磁盘延迟与IO进程，ss/netstat查连接状态，辅以journalctl查日志。
Linux 服务器突然变慢，通常不是单一原因导致的，而是资源争用、配置异常或外部干扰共同作用的结果。排查要从可观测性入手，优先检查最可能“拖后腿”的几类指标：CPU、内存、磁盘 I/O 和网络，再结合进程与服务状态深入定位。
CPU 使用率异常飙升
高 CPU 占用是最常见的性能瓶颈来源。使用 top 或 htop 查看实时负载，重点关注 %CPU 列和负载平均值（load average）。若 1 分钟负载远超 CPU 核心数（例如 8 核机器 load > 15），说明系统已严重过载。
- 按 P 排序，找出 CPU 消耗最高的进程；注意区分是用户态（%us）还是内核态（%sy）占用高
- 用 pidstat -u 1 观察每个进程每秒的 CPU 变化，确认是否为持续型还是突发型占用
- 检查是否有脚本死循环、未加限制的 cron 任务、或编译/备份等临时任务正在运行
内存不足触发 OOM 或频繁换页
内存耗尽时，系统会启用 swap 并频繁进行页面换入换出（swap-in/out），导致整体响应迟缓。用 free -h 看可用内存和 swap 使用量；用 vmstat 1 观察 si（swap-in）和 so（swap-out）是否持续非零。
- 若 available 值接近 0 且 swap used 明显增长，大概率是内存泄漏或应用配置不当（如 Java 的 -Xmx 设定过大）
- 用 smem -s rss 按实际物理内存（RSS）排序进程，比 top 更准确反映内存占用
- 检查 dmesg 输出是否有 “Out of memory: Kill process…” 记录，说明 OOM killer 已介入
磁盘 I/O 延迟高或队列积压
当磁盘响应变慢（尤其是机械盘或共享存储），所有依赖磁盘的操作都会卡顿。用 iostat -x 1 关注 %util（设备饱和度）、await（平均等待时间）、r_await/w_await 和 avgqu-sz（平均请求队列长度）。
- %util 接近 100% 且 await > 50ms（SSD）或 > 100ms（HDD），说明 I/O 成为瓶颈
- 用 iotop 定位具体是哪个进程在大量读写；注意区分是随机 I/O 还是顺序大文件操作
- 检查是否有日志轮转、数据库 dump、rsync 同步或监控 agent 扫描大量小文件等行为
网络连接异常或中断
网络问题常被忽略，但丢包、连接数打满、DNS 解析失败等都可能导致服务“变慢”甚至超时。用 ss -s 查看 socket 统计，关注 ESTAB 连接数和 TIME-WAIT 数量；用 netstat -an | grep :端口 | wc -l 快速确认某服务连接是否堆积。
- 检查 cat /proc/net/snmp | grep -A 2 'Tcp' 中 RetransSegs 是否明显上升，提示丢包或重传
- 用 ping 和 mtr 测试到网关及关键上游的连通性与延迟抖动
- 确认防火墙（iptables/nftables）规则未意外限速或拦截，SELinux/AppArmor 是否阻止了正常访问
排查过程中建议同步查看系统日志：journalctl -S "2 hours ago" --since "1 hour ago" 或 /var/log/messages，搜索关键词如 “error”、“fail”、“oom”、“timeout”。不复杂但容易忽略。
