卡顿的四大根源

Linux 服务器性能由四种资源决定，卡顿基本都出在这里：

资源常见原因
CPU 飙满进程异常占用、死循环、批量任务堆积
内存爆满程序内存泄漏、缓存堆积
磁盘 I/O 过高日志频繁写入、大量文件传输、数据库高频读写
网络堵塞端口被占用、带宽跑满

5步排查流程

第一步：整体状态评估

先用 top 命令看全局：

top

重点关注：

  • %Cpu(s) 超过 80% → CPU 有问题
  • KiB Mem available 低于 10% → 内存告急
  • load average 持续高于 CPU 核数 → 系统过载

第二步：CPU 异常排查

# 查看 CPU 占用前10的进程
ps aux --sort=-%cpu | head -11

# 查看某个进程的详细信息
ps -p [PID] -o pid,ppid,cmd,%cpu,%mem

# 紧急处理（谨慎，确认不是核心进程）
kill -9 [PID]

不要随意 kill 这些进程：sshd、mysql、nginx、systemd。

第三步：内存异常排查

# 查看内存详情
free -h

# 查看内存占用前10的进程
ps aux --sort=-%mem | head -11

# 清理系统缓存（不影响业务）
sync && echo 3 > /proc/sys/vm/drop_caches

第四步：磁盘 I/O 异常排查

# 查看 I/O 整体情况（每秒刷新3次）
iostat -x 1 3

# 查看哪个进程在读写磁盘
iotop -o

%util 超过 80% 说明磁盘 I/O 已经饱和，需要找出对应进程。

第五步：网络异常排查

# 查看端口占用
netstat -ntlp

# 实时查看带宽使用（需安装）
iftop -n

# 查看网络连接状态统计
ss -s

真实案例：10分钟解决 CPU 飙升

某天下午，监控告警 CPU 持续 95%，业务接口超时。

排查过程：

  1. top 发现一个 Python 进程占用 90% CPU
  2. ps -p [PID] -o cmd 查到是一个定时备份脚本
  3. 脚本逻辑有 bug，陷入死循环
  4. kill -9 终止进程，CPU 立即恢复正常
  5. 修复脚本逻辑，加上超时保护

全程10分钟。

三个避坑原则

  1. 不要盲目重启服务器 — 重启会清除现场，让问题更难复现和定位
  2. 不要随意 kill 核心进程 — 先确认进程身份，再决定是否终止
  3. 建立监控体系 — 事后排查不如事前预警，用 OpsEye 等工具设置阈值告警，问题出现前就介入

常用命令速查

# 系统整体状态
top / htop / vmstat 1

# CPU
mpstat -P ALL 1
perf top

# 内存
free -h
cat /proc/meminfo

# 磁盘
df -h          # 磁盘空间
iostat -x 1    # I/O 性能
du -sh /*      # 目录大小

# 网络
netstat -ntlp
ss -tulnp
iftop / nethogs