服务器突然卡顿？这5个应急运维技巧让你10分钟内恢复业务

快小二编导 2026-07-25 10:01:01 运维技巧

凌晨3点，客服群突然炸了：“APP加载不出来了！”“网页一直转圈圈！”作为运维工程师，你猛地从床上弹起，远程登录服务器——CPU使用率99%、内存占用接近饱和、磁盘IO红得刺眼……服务器突然卡顿就像一场“数字急症”，处理不及时可能导致用户流失、业务中断，甚至引发连锁故障。

其实，服务器卡顿并非无迹可寻，应急处理也有章法。本文结合一线运维经验，总结出5个关键应急技巧，帮你快速定位问题、恢复服务，避免小故障演变成大事故。

一、先“止血”：优先保障核心业务可用

服务器卡顿的第一原则是：先恢复业务，再排查根因。如果一上来就钻到日志里找问题，可能错过最佳恢复时机。

首先通过监控工具（如Zabbix、Prometheus）或命令行确认：

比如，若只有一台应用服务器卡顿，可先将其从负载均衡集群中摘除（如Nginx的upstream临时注释该节点），让流量切换到其他正常节点，避免影响整体业务。

如果服务器资源已耗尽（CPU/内存100%），最直接的方式是释放资源。但“杀进程”不能乱杀，需遵循“先非核心，后核心”的原则：

注意：若核心进程（如Java应用、数据库）占用过高，不要直接杀死，需先检查是否有内存泄漏或死循环（可通过jstack分析Java线程，或strace跟踪系统调用）。

业务暂时恢复后，必须快速找到卡顿的根因，否则问题可能复发。服务器卡顿的核心原因通常集中在CPU、内存、磁盘IO、网络四大资源上，可通过以下命令逐一排查。

CPU使用率高不一定是“计算多”，也可能是“等待多”。用top命令看%us（用户态CPU）和%sy（内核态CPU）：

若%us高：说明应用程序本身计算量大（如复杂算法、大量循环），需优化代码或升级CPU；
若%sy高：可能是系统调用频繁（如频繁读写文件、网络请求），或进程上下文切换过多（用vmstat看cs列，正常值因服务器而异，若远高于平时需警惕）。

进阶排查：用pidstat -u 1查看单个进程的CPU使用情况，定位具体是哪个进程在“吃CPU”；用mpstat -P ALL 1查看单个CPU核心的负载，若某核心使用率100%，可能是单线程程序导致的“核心绑定”问题。

内存不足会导致服务器频繁使用交换空间（Swap），从而引发卡顿。用free -h查看内存使用：

若available（可用内存）接近0，且Swap使用率高：说明内存真的不够，需临时增加Swap（swapon -s查看，fallocate -l 4G /swapfile && mkswap /swapfile && swapon /swapfile），或升级内存；
若内存占用高但Swap使用率低：可能是内存泄漏（如Java应用的堆内存无法释放）。此时用jmap -heap [PID]查看Java堆内存使用，或pmap -x [PID]查看进程的内存分布，确认是否有异常占用。

磁盘IO慢会导致所有依赖磁盘的操作（如数据库查询、日志写入）卡顿。用iostat -x 1查看磁盘性能：

快速验证：用dd if=/dev/zero of=/tmp/test bs=1G count=1测试磁盘写入速度，若远低于正常水平（如SSD正常写入应>200MB/s），需检查磁盘硬件。

网络问题容易被忽略，但也是卡顿的常见原因。用iftop（或nload）查看带宽使用：

若带宽接近上限（如100M带宽跑满）：可能是DDOS攻击、大文件下载或异常流量导致，需用tcpdump抓包分析（tcpdump -i eth0 port 80），或通过防火墙限制异常IP；
若连接数过多：用netstat -an | grep ESTABLISHED | wc -l查看已建立连接数，若超过系统限制（ulimit -n查看），需修改/etc/security/limits.conf提高文件描述符上限。

不同卡顿场景的修复方法不同，以下是运维中最常遇到的3种情况及应对策略。

很多时候，服务器卡顿的根源是慢SQL。比如某电商平台突然卡顿，经查是一个未加索引的SELECT * FROM orders WHERE user_id = ?查询，在订单表数据量达100万时，每次查询都要全表扫描。

应急步骤：

用数据库自带工具查看慢查询：MySQL用show slow logs，PostgreSQL用pg_stat_statements；
临时优化：给user_id字段加索引（ALTER TABLE orders ADD INDEX idx_user_id (user_id)），但注意高峰期加索引可能锁表，建议先在从库测试；
限流降级：若慢查询无法立即优化，可通过应用层限流（如限制该接口的QPS），避免数据库被压垮。