服务器出现卡顿但CPU和内存占用率均处于低位,核心原因通常指向I/O瓶颈、网络拥塞、磁盘性能衰退或内核级阻塞，而非计算资源匮乏，这种“假死”现象往往比资源耗尽更难排查，需要从系统底层机制入手，通过分层排查锁定真正的性能短板。
磁盘I/O性能瓶颈是首要诱因
当服务器响应缓慢而CPU空闲时,磁盘子系统往往是最大的嫌疑对象，传统的机械硬盘（HDD）在随机读写频繁的场景下，IOPS（每秒读写次数）极易达到上限，CPU花费大量时间在等待磁盘数据传输完成上，处于“IOWait”状态，虽然整体利用率显示不高，但系统吞吐量已严重下降。
- IOWait隐形占用：使用
top命令观察，若wa（IOWait）数值持续高于10%，即表明CPU在空转等待磁盘。 - 队列堆积：通过
iostat -x 1命令查看队列长度（aqu-sz）和服务时间（await），如果队列长度持续大于2，说明磁盘处理请求的速度远低于请求产生的速度。 - 解决方案：对于高并发读写场景，建议更换为NVMe SSD固态硬盘，或调整文件系统挂载参数，如禁用访问时间更新（noatime）以减少不必要的写操作。
网络带宽饱和与连接表溢出
网络层面的拥塞同样会导致服务器“很卡”的假象，尤其是遭受DDoS攻击或突发流量激增时，此时CPU仅需处理中断请求，负荷并不高，但数据包的进出通道已完全堵塞。
- 带宽跑满：使用
iftop或nethogs工具实时监控流量，若出站或入站带宽达到服务器购买上限，TCP重传率会飙升，导致用户端感知为连接超时或卡顿。 - TCP连接数耗尽：检查
netstat -an或使用ss -s，如果处于TIME_WAIT或ESTABLISHED状态的连接数接近系统设定的文件句柄上限（ulimit），新的连接请求将被拒绝或延迟处理。 - 防御措施：优化内核参数，如开启
tcp_tw_reuse快速回收TIME_WAIT连接，或增加最大文件打开数限制，针对攻击流量，需部署防火墙清洗或接入CDN服务。
进程与线程的锁竞争死锁
在多线程应用程序中,锁机制的不当使用会导致“很多线程在等待，少数线程在干活”的局面，这种情况下，CPU利用率看似很低，因为大部分线程处于休眠或阻塞状态，并未执行计算指令。
- 资源竞争：数据库死锁或应用程序内的互斥锁竞争，会导致请求队列堆积。
- 排查手段：对于Java应用，需抓取线程堆栈分析锁持有情况；对于数据库，需检查慢查询日志和锁等待日志。
- 优化路径：优化代码逻辑，减少锁的粒度，或使用无锁数据结构，确保计算资源能被有效利用而非空转等待。
系统内核参数配置失当
默认的Linux内核参数往往偏向通用性,在高性能服务器场景下可能成为短板，如果TCP缓冲区设置过小，数据传输效率会大打折扣，导致服务器很卡但是内存cpu都不高的现象。
- 缓冲区限制：检查
net.core.rmem_max和net.core.wmem_max参数，过小的缓冲区会导致数据包丢失和重传。 - 中断均衡：多核CPU若未开启IRQ均衡，可能导致单个核心处理所有网卡中断，单核软中断负载过高，而整体CPU使用率依然显示为低水平。
- 调优建议：根据服务器内存大小，适当扩大TCP读写缓冲区范围，并确保
irqbalance服务正常运行。
硬件故障与隐性降级
硬件的老化或故障往往具有隐蔽性,不会立即导致宕机，而是通过降低性能来表现。
- 磁盘坏道：硬盘出现坏道时，磁头需要多次重试读取数据，导致极大的延迟。
- 内存ECC错误：服务器内存若频繁出现可纠正的ECC错误，系统会反复进行纠错操作，导致卡顿。
- 检测方法：定期运行SMART工具检测硬盘健康状态，查看系统日志中是否有Hardware Error相关记录。
相关问答
问：服务器负载很高但CPU使用率很低是怎么回事？
答：这通常是由于I/O Wait过高导致的，负载代表了系统等待运行的进程队列长度，不仅包括等待CPU的进程，还包括等待磁盘I/O、网络I/O的进程，当磁盘读写速度跟不上请求速度时，大量进程处于阻塞等待状态，导致负载飙升，但CPU因为无事可做而显示低使用率，建议优先检查磁盘状态和I/O性能。
问：如何快速区分是网络卡顿还是服务器本身卡顿？
答：可以通过Ping测试和本地命令结合判断，如果在服务器内部执行命令（如ls, vi）响应迅速，但外部访问Web服务缓慢，大概率是网络带宽跑满或链路拥堵，如果服务器内部执行基础命令都出现明显延迟，则是服务器本地资源（如磁盘、内存交换）出现问题，需重点排查磁盘I/O和系统日志。
如果您在排查过程中遇到更复杂的特殊情况,欢迎在评论区留言交流。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/123641.html
