Linux 系统运行速度慢有哪些排查方法？

最新推荐文章于 2026-06-23 21:23:37 发布

原创最新推荐文章于 2026-06-23 21:23:37 发布 · 328 阅读

7 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#linux #前端 #数据库

Linux 系统变慢通常是资源供需失衡导致的，建议按 CPU、内存、磁盘 I/O、网络的顺序依次排查，优先使用 top、free、iostat 等基础命令定位瓶颈。

先说结论：系统卡顿本质是核心资源被过度占用，需先定位具体瓶颈资源，再针对性处理异常进程或配置，最后验证负载是否回落。

先定位：使用 top 查看负载，free 查看内存，iostat 查看磁盘，ss 查看网络，确定哪类资源打满。
先做：确认进程非核心业务后，使用 kill -15 优雅终止；内存不足可清理缓存（需谨慎）或扩容；磁盘忙可找出高 IO 进程。
再验证：观察负载平均值是否下降，业务响应时间是否恢复正常，日志是否不再报错。

生产环境操作安全警告

在执行任何优化操作前，请务必注意以下风险：

禁止盲目重启：重启会丢失现场信息，导致无法定位根因，仅在系统完全无响应时作为最后手段。
谨慎终止进程：直接 kill 可能导致数据丢失或服务中断。务必确认进程非核心业务，优先使用 kill -15 PID 优雅终止，避免直接使用 kill -9。
清理缓存风险：手动清理缓存会触发磁盘 IO 飙升，严禁在业务高峰期执行 drop_caches 操作。
备份配置：修改系统参数前请备份原配置文件。

命令速用版与输出解读

以下是排查过程中最常用的几条命令，可直接在终端执行，并附带正常与异常输出对比：

top              # 查看 CPU 负载和进程占用
free -h          # 查看内存和 Swap 使用情况
iostat -x 1      # 查看磁盘 IO 等待和利用率
ss -s            # 查看网络连接状态统计
dmesg | grep -i oom  # 检查是否有内存溢出杀进程记录

top 负载对比：

正常情况（4 核 CPU，load < 4）：

top - 10:00:00 up 10 days,  1 user,  load average: 0.50, 0.40, 0.35

异常情况（负载过高）：

top - 10:00:00 up 10 days,  1 user,  load average: 24.00, 18.01, 12.05

iostat 磁盘对比：

正常情况（%util < 80%）：

Device  %util  await
sda      20.00   5.00

异常情况（IO 瓶颈）：

Device  %util  await
sda     100.00  500.00

分步处理

1. 检查 CPU 负载
执行top命令，关注 load average 值。若 1 分钟负载远超 CPU 核心数，说明系统过载。按P键按 CPU 占用排序，找出消耗最高的进程。区分是用户态 (%us) 还是内核态 (%sy) 占用高。

2. 检查内存使用
执行free -h，关注 available 值。若 available 接近 0 且 swap used 明显增长，大概率是内存泄漏或配置不当。检查dmesg输出是否有"Out of memory"记录。

若确需释放页缓存，可执行 sync; echo 3 > /proc/sys/vm/drop_caches。警告：此操作会触发磁盘 IO 飙升，生产环境严禁在业务高峰期执行，仅作为临时应急手段。

3. 检查磁盘 I/O
执行iostat -x 1，关注%util 和 await 列。若%util 接近 100% 且 await 数值较高，说明 I/O 成为瓶颈。使用iotop定位具体是哪个进程在大量读写。

4. 检查网络连接
执行ss -s或netstat -s，检查 TCP 重传、连接队列溢出或 TIME_WAIT 堆积。丢包或连接数打满也会导致服务“变慢”。

5. 检查系统日志
使用journalctl或查看/var/log/messages，查找与卡顿时间点相关的错误信息或警告。

典型高负载场景实战

场景：Java 应用 CPU 飙高

使用top -H -p PID找到占用 CPU 最高的线程 ID。
将线程 ID 转换为 16 进制（printf "%x\n" 线程 ID）。
使用jstack PID | grep 16 进制线程 ID -A 20查看堆栈信息。
定位代码死循环或频繁 GC 问题。

场景：磁盘 IO 等待过高

使用iostat -x 1确认%util 持续 100%。
使用iotop -oP找出读写最高的进程。
若是日志打印过多，调整日志级别；若是数据库慢查询，优化 SQL 或增加索引。

怎么验证是否生效

处理完成后，再次运行top观察 load average 是否回落至正常范围。业务侧确认页面加载速度或接口响应时间恢复。检查系统日志不再新增相关报错。若之前有监控告警，确认告警是否停止触发。

常见坑

不要盲目重启服务器，这大概率治标不治本，且可能丢失现场信息。
kswapd0 进程 CPU 使用率高通常意味着物理内存不够用，需优化应用或增加内存，而非单纯杀进程。
很多“慢”本质是下游响应延迟传导上来，排查时别忘了验外部依赖如 DNS、数据库、RPC 或存储挂载点。
top 命令中 buff/cache 占用高不一定是问题，Linux 会利用空闲内存做缓存，主要看 available 值。
终止进程前务必确认该进程是否为系统核心服务（如 sshd、systemd 等），误杀可能导致无法远程连接。

来源 https://www.zjcp.cc/ask/10925.html