Linux服务器突然卡顿？top+netstat+df，3条命令找出真凶

一只大侠

发布于 2025-12-31 11:19:52

5740

Linux服务器突然卡顿？top+netstat+df，3条命令找出真凶

作为一名Linux运维工程师，最让人头皮发麻的场景莫过于：凌晨三点被监控告警电话惊醒，被告知业务系统响应延迟超过10秒；或者白天上班时，开发同事集体反馈“服务器又卡了”。这种突发的卡顿问题，往往没有明显预兆，却直接影响业务连续性——电商系统卡顿可能导致订单流失，IoT平台卡顿会造成数据采集中断，后台服务卡顿则会引发全链路超时。

很多新手遇到这种情况会手足无措，要么盲目重启服务器（大概率治标不治本），要么对着满屏日志发呆。其实，Linux服务器的多数卡顿问题，都能通过“top+netstat+df”这三条基础命令快速定位。我曾靠这“三板斧”，在5分钟内解决过双11期间的数据库服务器卡顿问题，也帮过刚入行的同事排查出被挖矿程序占用资源的隐患。今天就结合三个真实案例，把这三条命令的实战用法讲透，让你遇到服务器卡顿再也不慌。

一、先搞懂：Linux服务器卡顿的核心原因

在动手排查前，我们得先明确一个逻辑：服务器卡顿本质是“资源供需失衡”——CPU、内存、磁盘I/O、网络带宽这四大核心资源中，至少有一项被过度占用，导致业务进程无法获得足够资源运行。

常见的卡顿场景主要分四类：一是CPU被高负载进程占满，比如异常的Java进程或挖矿程序；二是内存耗尽引发大量Swap交换，导致进程响应迟缓；三是磁盘I/O瓶颈，比如日志写入过于频繁或磁盘故障；四是网络堵塞，比如遭遇SYN洪水攻击或端口被异常连接占满。

而top、netstat、df这三条命令，恰好对应这些核心资源的排查：top聚焦CPU和内存，netstat专攻网络连接，df则锁定磁盘空间问题。掌握它们的组合用法，就能形成“从资源占用到问题定位”的完整闭环。下面我们从实战场景出发，一步步拆解操作。

二、第一招：top命令——CPU与内存的“透视镜”

top命令是Linux系统的“资源监视器”，执行后会实时显示进程的CPU、内存占用情况，默认按CPU使用率排序。遇到服务器卡顿时，第一步就该用它判断“是不是计算资源被耗尽了”。

1. 基础用法：3秒看懂top输出

直接在终端输入top，会出现如下核心输出（关键信息已标注）：

top - 09:23:45 up 120 days,  3:15,  2 users,  load average: 12.50, 8.30, 5.10
Tasks: 286 total,   3 running, 283 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.2 us,  1.5 sy,  0.0 ni,  0.0 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem : 32786848 total,  1254368 free, 28567480 used,  2965000 buff/cache
KiB Swap: 16777212 total,  8965344 free,  7811868 used.  3568928 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                     
1234 root      20   0 8582468 7.2g   12348 R  99.8 23.1  12:35.67 java                        
5678 mysql     20   0 6291456 2.1g   87652 S  45.2  6.6  08:12.45 mysqld                      
9012 www       20   0  152348  12456   8972 R  12.5  0.0   0:03.21 nginx

这几行输出藏着卡顿的关键线索，我们重点看三个部分：

系统负载（load average）：第一行的“12.50, 8.30, 5.10”分别代表1分钟、5分钟、15分钟的系统负载。核心判断标准是：负载值超过CPU核心数，说明系统已过载。比如4核CPU的负载达到12.5，明显是CPU资源不足导致卡顿。
CPU状态（%Cpu(s)）：“us”代表用户进程占用CPU比例，“sy”是系统进程占用比例，“wa”是等待磁盘I/O的CPU时间占比。如果“us”接近100%，说明业务进程（如java、mysqld）占用过高；如果“wa”超过50%，则要警惕磁盘I/O瓶颈。
进程列表：重点关注“%CPU”“%MEM”和“COMMAND”列。案例中PID为1234的java进程CPU占用99.8%，是明显的“罪魁祸首”；同时Swap分区已使用7.8G，说明内存也已不足，进一步加剧卡顿。

2. 进阶技巧：精准筛选关键进程

默认的top输出信息较多，我们可以用快捷键优化显示：

按CPU排序：在top界面按“P”（大写），进程会按CPU使用率从高到低排序，瞬间锁定高负载进程。
按内存排序：按“M”（大写）切换到内存排序，适合排查内存泄漏问题。
筛选特定用户进程：输入“u”，再输入用户名（如mysql），可只显示该用户的进程，避免无关进程干扰。
刷新频率调整：输入“s”，可修改刷新间隔（默认3秒），排查突发问题时设为1秒更及时。

3. 实战案例：Java进程占满CPU导致卡顿

去年双11前，公司的订单系统服务器突然卡顿，接口响应时间从500ms飙升到5s。我登录服务器后立即执行top命令，发现一个java进程CPU占用100%，内存占用也达到80%。

下一步就是定位该Java进程的具体问题线程。通过ps -mp 1234 -o THREAD,tid,time命令（1234为Java进程PID），找到占用CPU最高的线程PID（假设为1240）；然后用printf "%x\n" 1240将线程PID转为十六进制（结果为4d8）；最后执行jstack 1234 | grep 4d8 -A 30，查看该线程的堆栈信息，发现是一个订单统计的定时任务出现死循环，导致CPU被耗尽。

解决方法很简单：先通过kill -9 1234重启Java服务，临时恢复业务；再修改定时任务的逻辑，避免死循环。整个排查过程不到10分钟，比盲目重启服务器更彻底。

三、第二招：netstat命令——网络连接的“侦察兵”

如果top命令显示CPU和内存占用都正常，那卡顿很可能出在网络上——比如服务器遭遇网络攻击，或者某个服务的连接数超出上限。这时候，netstat命令就能派上用场，它能列出所有网络连接状态，帮我们找出异常连接。

1. 核心用法：聚焦连接状态与端口占用

netstat的参数很多，排查卡顿最常用的组合是netstat -tuln（查看监听端口）和netstat -an | grep ESTABLISHED（查看已建立连接），以及netstat -an | grep SYN_RECV（查看半连接状态）。

我们先拆解关键参数：

-t：只显示TCP连接（最常用的网络协议）。
-u：显示UDP连接（可选，根据业务场景判断）。
-l：只显示处于监听状态的端口（判断服务是否正常启动）。
-n：用IP地址和端口号显示，不进行域名反解析（加快查询速度）。
-a：显示所有连接（包括监听和已建立的）。

2. 关键排查方向：三类异常连接

网络导致的卡顿，通常和以下三类异常连接有关，用netstat就能快速识别：

SYN_RECV状态连接过多：执行netstat -an | grep SYN_RECV | wc -l，如果结果超过几百，大概率是遭遇了SYN洪水攻击。这种攻击通过发送大量半连接请求，耗尽服务器的连接资源，导致正常请求无法建立。
某个端口的ESTABLISHED连接暴增：比如执行netstat -an | grep :8080 | grep ESTABLISHED | wc -l，发现8080端口（假设是Web服务端口）连接数从平时的几十飙升到几千，可能是服务出现内存泄漏，导致连接无法释放，或者遭遇了CC攻击。
异常IP的大量连接：用netstat -an | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr，可以统计每个IP的连接数。如果某个陌生IP的连接数占比超过50%，很可能是恶意连接。

3. 实战案例：Web服务端口被异常连接占满

有一次，公司的API服务器突然卡顿，top命令显示CPU和内存都很正常，于是转向网络排查。执行netstat -an | grep :80 | grep ESTABLISHED | wc -l，发现80端口的连接数从平时的200左右涨到了3000+。

接着用连接数统计命令，发现一个来自境外的IP，连接数高达2800。初步判断是CC攻击，立即通过iptables -I INPUT -s 恶意IP -j DROP封禁该IP，同时执行service nginx restart重置Web服务连接。5分钟后，服务器卡顿缓解，80端口连接数恢复正常。

为了避免后续攻击，我还配置了nginx的连接限制：在nginx.conf中添加limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 10;，限制每个IP最多10个并发连接，从根本上防范类似攻击。

四、第三招：df命令——磁盘空间的“警报器”

很多人容易忽略磁盘空间问题，但实际上“磁盘满导致服务器卡顿”的场景非常常见。当磁盘空间使用率达到100%时，系统无法写入日志、临时文件，进程会陷入等待状态，表现为服务器卡顿甚至服务崩溃。df命令就是检查磁盘空间的“标配工具”。

1. 基础用法：一眼看穿磁盘占用

最常用的命令是df -h，“-h”参数会以“GB”“MB”等人类易读的单位显示磁盘信息，输出如下：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  2.0G  95% /
/dev/vdb1       100G   50G   50G  50% /data
tmpfs            16G     0   16G   0% /dev/shm

核心关注“Use%”列，通常磁盘使用率超过90%就需要警惕，超过95%很可能导致卡顿。案例中“/”分区（根分区）使用率达95%，是明显的风险点。

2. 进阶操作：定位大文件与冗余日志

df命令只能看到分区占用，要找到具体的大文件，需要结合du命令。比如根分区满了，可按以下步骤定位：

进入根目录：cd /
统计各目录大小：du -sh *（“-s”显示总和，“-h”人性化显示），找到占用最大的目录（比如/var）。
进入该目录继续排查：cd /var，再次执行du -sh *，发现是/var/log日志目录占用20G。
查看具体日志文件：ls -lh /var/log | sort -k5 -nr，按文件大小排序，找到占用最大的日志文件（比如nginx的access.log）。

3. 实战案例：日志文件占满磁盘导致MySQL卡顿

一次MySQL数据库服务器卡顿，执行mysql -u root -p连不上数据库，报错“Can’t create/write to file ‘/tmp/#sql_1234.MYI’”。立即执行df -h，发现根分区使用率100%。

通过du命令排查，定位到/var/log/mysqld.log日志文件占用35G——原来是MySQL开启了全量日志，且没有配置日志轮转，导致日志文件不断增大，占满了根分区。

解决步骤分两步：一是临时释放空间，二是永久解决日志问题。临时释放：先备份日志cp /var/log/mysqld.log /data/backup/，再清空日志echo "" > /var/log/mysqld.log（注意不能用rm删除正在写入的日志文件，否则会导致服务异常）；永久解决：编辑MySQL配置文件vim /etc/my.cnf，添加日志轮转配置，同时关闭不必要的全量日志，只保留错误日志和慢查询日志。操作完成后，MySQL恢复正常，服务器卡顿问题彻底解决。

五、组合拳：卡顿排查的完整流程与避坑指南

通过以上三个案例，我们可以总结出Linux服务器卡顿的“标准化排查流程”，按这个顺序操作，能最大程度提高效率：

第一步：用top判断CPU/内存状态——执行top，查看load average、%CPU、%MEM和高负载进程。若CPU或内存异常，定位具体进程并分析原因（如死循环、内存泄漏）。
第二步：用netstat排查网络连接——若CPU/内存正常，执行netstat -an查看连接状态，重点检查SYN_RECV和异常IP的连接数，判断是否遭遇攻击或连接泄漏。
第三步：用df+du检查磁盘空间——若网络也正常，执行df -h查看磁盘使用率，用du定位大文件，重点排查日志、临时文件和数据库文件。
第四步：验证与解决——定位问题后，执行临时解决方案恢复业务（如重启进程、封禁IP、清空日志），再制定永久方案（如优化代码、配置防护规则、设置日志轮转）。

同时，分享几个运维老手的避坑指南：

不要盲目重启：重启可能会清除日志信息，导致无法追溯问题根源。先排查再重启，必要时先备份关键日志。
注意权限问题：普通用户执行top、netstat可能看不到完整进程信息，建议用sudo切换到root用户操作。
结合日志分析：命令排查只是定位方向，最终还要结合应用日志（如Java的log、MySQL的error.log）确认问题，比如top发现MySQL负载高，就去看MySQL的慢查询日志。
提前做好监控：通过Zabbix、Prometheus等工具监控CPU、内存、磁盘、网络等指标，设置阈值告警，争取在卡顿发生前发现隐患。