服务器一直卡顿，先别急着重启，按“CPU → 内存 → 磁盘IO → 带宽 → 应用日志”的顺序快速定位，多数情况下是配置不够或异常进程在偷偷吃资源，找到元凶再对症处理，比盲目重启管用得多。
服务器卡顿原因及解决方法：先把病灶揪出来
服务器卡顿不是突然的脾气,它背后一定有个“肇事者”在占用资源，行业共识认为，超过一半的服务器卡顿案例，根源都集中在五个方向：CPU跑满、内存不足、磁盘读写慢、带宽被打爆、应用代码出问题，你不需要懂太深的内核知识，学会用几个基础命令，就能把问题圈定在一个很小的范围里。
CPU爆满：应用在“空转”还是真的忙
登录服务器后,第一件事打开终端，执行 top 命令，然后按 1 展开每个逻辑核心的使用率，观察 %Cpu(s) 一行的 us（用户态）和 sy（内核态）数值，这两个值长期超过90%，CPU就是卡顿的元凶。
us高：多半是应用业务逻辑在疯狂计算，比如死循环、正则匹配过于复杂、图片处理脚本没限制并发，用top -Hp <进程ID>找到具体线程，再结合jstack（Java应用）或py-spy（Python应用）导出线程栈，一眼就能看出卡在哪段代码上。sy高：内核态CPU占用过大，常见原因是频繁的上下文切换或磁盘中断风暴，可以执行vmstat 1，观察cs（上下文切换）列，数值持续超过几万，说明进程/线程数量太多，系统忙于“换人”而不是干活。
内存吃紧：Swap开始“倒腾”机器就慢
执行 free -h，available 所剩无几，而 Swap 的 used 数值持续增长，说明物理内存已不够用，系统开始拿磁盘当内存使，内存和磁盘的速度差距，业内专家指出通常在两到三个数量级，一旦大量读写Swap，卡顿几乎是必然。
查看具体是谁在吃内存,用 ps aux --sort=-%mem | head -20 列出内存占用前十的进程，常见大户包括：
- 数据库缓冲池设置过大,挤占了操作系统的可用内存。
- Java或Node.js应用堆内存配置超出实际物理内存。
- PHP-FPM开启了过多进程，每个进程都占着固定内存。
此时不要盲目加内存条,先判断是“配置错误”还是“真实需求”，如果只是参数调大了，改配置文件后重启对应服务即可；如果确实是业务增长需要，升级配置才合理。
磁盘IO拖后腿：读写慢半拍
用 iostat -x 1 循环观察磁盘使用率（%util），接近100%说明磁盘满负荷运转，卡顿表现在：网站打开缓慢、数据库查询迟迟不返回、文件上传下载像老牛拉车。
常见诱因有三个：
- MySQL慢查询产生了大量临时文件,写入磁盘时把IO通道堵死了。
- 日志系统没有做切割,单日日志文件达到几个GB，写日志本身就把磁盘拖垮。
- 云服务器使用了突发性能型实例,CPU积分耗尽后磁盘IO被限制，每秒钟的读写次数被压低。
查看日志文件大小,用 du -sh /var/log/ 快速定位大文件，业务日志要配置 logrotate 定期切割，数据库慢查询日志只在排查期间临时开启，不要长期运行。
网站服务器卡顿怎么办：分场景处理不硬扛
不同场景下,网站服务器卡顿的应对策略截然不同，用一个万能重启去应付所有情况，往往只是把问题延后，而且重启后不久又会复现。
高峰期并发突增：先挡流量再扩容
典型的场景：某个活动页面被分享到社交平台，瞬时涌入大量请求，你看到 nginx 的 active connections 数值飙到好几万，后端应用响应时间从50毫秒拉长到5秒。
处理步骤按优先级来：
- 立即开启Web应用防火墙（WAF）的CC防护规则，设定单IP访问频率上限，把恶意刷请求的流量挡在门外。
- 确认Redis或Memcached缓存是否生效,热点数据（如商品详情、公告内容）应直接命中缓存，不穿透到数据库。
- 登录云控制台,对服务器走“升级配置”操作，或新建一台同等配置的实例挂到负载均衡后面。
如果每次活动高峰都频繁手动操作,说明架构需要改：把静态资源（图片、CSS、JS）迁移到对象存储加CDN，让访问流量大头打在CDN节点上，而不是源站服务器上。
数据库成为瓶颈：慢查询和缺索引
排查数据库问题,先打开慢查询日志，以MySQL为例，执行：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;
运行一会儿后查看慢查询日志文件,找出执行时间超过1秒的SQL语句，拿这些语句前加上 EXPLAIN 执行，看 type 列，如果看到 ALL（全表扫描）或 index（全索引扫描），基本没走索引，数据量一上来就卡顿。
修正方案明确：
- 给
WHERE条件涉及的字段加普通索引（B-Tree）。 - 多条件查询用联合索引,注意遵循“最左前缀”原则。
- 尽量不要在查询中对字段做函数运算,
WHERE DATE(create_time) = '2026-01-01'，这会让索引失效，改成范围查询WHERE create_time >= '2026-01-01' AND create_time < '2026-01-02'。
攻击流量打满带宽：停掉异常连接
站点的访问量没涨,带宽却先跑满了，用 iftop 或 sar -n DEV 1 观察网络流量，发现某个IP或某段IP连接数异常庞大，执行 ss -s 和 netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 列出连接数排名前十的IP。
处理动作要快：
- 云平台安全组里直接拒绝异常IP的入方向规则。
- 服务器上用
iptables -A INPUT -s <异常IP> -j DROP临时封禁。 - 如果攻击流量持续超过带宽上限,联系云服务商开启高防IP或DDoS清洗服务。
云服务器卡顿如何排查：从CPU到带宽的清单式操作
云服务器和物理服务器在排查手法上大同小异,但多了虚拟化层这一变量，有时候卡顿根源不在你自己身上，而是宿主机资源竞争导致的性能抖动，行业共识认为，这一类情况占比不大，但需要了解判断方法：如果宿主机的邻居“吵闹”（大量IO密集型操作），你的云磁盘IO等待会变高。
建立一套标准排查流程,每次卡顿出现时按清单执行，效率最高。
| 排查维度 | 核心命令 | 判断标准 |
|---|---|---|
| CPU | top |
us + sy 总和长期超过90% |
| 内存 | free -h |
available 低于10%，Swap used 持续增长 |
| 磁盘IO | iostat -x 1 |
%util 接近100%，await 大于几十毫秒 |
| 网络带宽 | sar -n DEV 1 |
当前流量接近带宽上限 |
| 进程线程 | ps aux --sort=-%cpu |
单个进程CPU占用超过100%（多核） |
| 应用日志 | tail -f /var/log/app.log |
出现大量ERROR或超时记录 |
按这个表格从上到下过一遍,最多花五分钟就能锁定问题层面，实际操作时，注意把每一步的结果截图或记下来，分析多次卡顿的共性规律。
排查完之后,针对反复出现的根因做长期优化：
- 配置了自愈脚本,比如利用
crontab每两分钟检查一次关键服务状态，异常时自动拉起。 - 监控告警用云平台自带的云监控,设置CPU使用率、内存使用率、出网带宽三个维度的阈值告警，故障在用户感知之前先一步处理。
- 调整进程参数,比如调整
nginx的worker_processes为核心数一致、修改Tomcat的最大线程数、调低数据库的连接池上限。
Q&A：关于服务器卡顿怎么解决的几个高频问题
Q1：服务器一直卡顿，为什么重启之后暂时好了，过几天又卡？
因为重启只清空了运行状态,没有改掉产生问题的根源，比如某个服务有内存泄漏，重启后内存占用量归零，但随着时间推移慢慢耗尽，卡顿重现，解决思路是：用监控工具记录卡顿前后的资源曲线，定位到具体的进程或代码逻辑，修复后升级重启，才算真正解决。
Q2：云服务器配置看起来够高，为什么网站打开还是很慢？
高配置不等于高性能,可能是网络线路不利导致的首包延迟高，比如用户群体在北方而你买了南方线路的节点；也可能是应用层处理逻辑慢，比如后端接口串行调用了多个耗时服务，用浏览器F12观察请求瀑布图，绿色等待时间和红色阻塞时间分别对应网络和应用问题，先分清是哪一环，再去针对调整，还要确认磁盘类型是高效云盘还是SSD云盘，IO性能差距相当大。
Q3：服务器卡顿期间，网站还能正常访问吗？
取决于卡顿的严重程度,CPU在低位运行、内存稍有不足时，网站可能只是响应变慢，页面要转好几秒才能打开；CPU完全占满或磁盘IO满负荷时，服务可能直接超时无响应，这时需要快速介入处理，比如在云控制台通过VNC登录强制结束异常进程，或执行安全重启操作，尽快恢复对外服务。
服务器卡顿本质上是一个资源分配的问题,找到卡点、分清主次、按步骤处理，大部分情况都能在十分钟内解决，长期积累的优化习惯比临时救火更有价值。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774430.html
