服务器跑不动先查CPU和磁盘，这两项是绝大多数性能瓶颈的根源，其次再看内存和网络。
很多朋友一碰到服务器卡顿，第一反应是加内存、换CPU，结果钱花了问题还在，通过系统命令和日志，几分钟就能定位到真正的瓶颈，以下排查路径基于一线运维的实战经验,按优先级排列。
第一刀先切CPU：看负载与进程
CPU是服务器的大脑，但它很少被真正“用满”，更多是卡在排队上，判断标准不在于使用率百分百，而在于负载平均值。
三个数字看懂负载
用uptime命令能看到类似load average: 4.32, 5.11, 6.08的输出，三个数字分别代表1分钟、5分钟、15分钟的平均活跃进程数。
判断逻辑很简单：
- 如果三个数字持续高于CPU核心数，说明进程在排队,系统已经忙不过来。
- 如果1分钟值远大于15分钟值，说明故障是突发的，大概率是某个进程“炸”了。
定位是哪个进程在捣乱
执行top命令，按大写P让进程按CPU占用率排序,重点观察前几行：
- PHP-FPM或Java进程大量堆积：这类进程每个都要占一整个核心，数量一多必然导致负载飙升,常见于慢查询或代码死循环。
- MySQL进程占用异常：大概率是SQL索引失效，导致全表扫描,此时应该去数据库慢查询日志里捞凶手。
- 莫名奇妙的挖矿进程：特点是CPU占用率固定在100%以上，进程名伪装的像系统服务，此时用
kill -9杀掉进程,并立即排查定时任务和公网SSH登录记录。
load average与CPU核数对照
| 场景 | 负载值 | 核数 | 诊断 |
|---|---|---|---|
| 正常业务 | 0 | 4核 | 健康 |
| 业务高峰 | 5 | 4核 | 勉强支撑 |
| 故障状态 | 8 | 4核 | 严重过载，需立即处理 |
排查CPU问题时，顺带看一眼mpstat -P ALL 1，确认是不是只有单核满载，如果只有单核忙，说明程序是单线程架构，加核数没用,得优化代码本身。
第二刀砍向磁盘：IO等待才是隐形杀手
磁盘比CPU更容易成为瓶颈，尤其是机械硬盘。iowait值过高是典型的磁盘拖后腿信号，表现为系统反应迟钝,但CPU和内存都挺空闲。
用iostat看真实读写压力
执行iostat -x 1,重点看两块指标：
- %util：接近100%说明磁盘已经满负荷运转,没有余量。
- await：超过100毫秒说明响应极慢，正常情况下应该在10-20毫秒。
如果确认磁盘被写满，df -h检查空间，du -sh /tmp这类命令逐个目录排查大文件，日志文件、数据库binlog、未清理的备份包是三大常见占满元凶。
inode耗尽的情况容易忽略
大文件清干净了，照样写不进数据，这种情况要查inode，执行df -i，如果已用100%，就算容量还剩几百G也写不了新文件，大量小文件（比如缓存碎片、session文件）会快速耗尽inode，处理方式是find /tmp -type f | wc -l这类命令统计数量,然后写个脚本定时清理。
磁盘排查工具对照
| 命令 | 用途 | 推荐场景 |
|---|---|---|
iostat -x 1 |
看IO利用率和响应时间 | 任何卡顿场景必跑 |
iotop |
定位具体哪个进程在狂读狂写 | 定位到具体应用时 |
df -h |
查看剩余空间 | 写入报错时 |
df -i |
查看inode剩余量 | 空间有但写入失败时 |
第三刀查内存：缓存和Swap的微妙博弈
内存排查要区分真正短缺和看起来不足两种情况，Linux系统会把空闲内存用作文件缓存，导致free -h显示可用内存很少,但这反而说明系统在高效利用资源。
判断标准是Swap有没有被用
如果free -h显示Swap一栏数字不是0，说明物理内存确实不够了，正在用磁盘空间当内存用，这会导致严重卡顿,因为磁盘速度比内存慢好几个量级。
处理优先级：
- 短期：
sysctl vm.swappiness=10，降低系统使用Swap的倾向,优先用物理内存。 - 中期：检查有没有内存泄漏的进程，比如长期运行的Node.js应用、Java应用，观察
top里RES列是否持续增长。 - 长期：考虑扩容内存，云服务器加内存是最直接的方案,成本也最低。
OOM Killer的痕迹
如果网站突然挂掉，检查dmesg | grep -i oom或/var/log/messages
，看到Out of memory: Kill process字样，说明是内存耗尽触发了内核的暴力清理机制，此时应用进程会被随机杀掉，表现就是毫无征兆的进程崩溃，排查方向是找出内存占用暴涨的应用程序,优化其缓存大小或连接池配置。
第四刀是网络：延迟和丢包的症状更隐蔽
前三项查完都没问题，服务器还是“跑不动”,就得看网络了。
入口带宽是否被打满
执行iftop或nload，看实时流量，如果长期稳定在带宽上限（比如100Mbps的实例跑出了99Mbps），说明是带宽瓶颈，这时网站表现是打开极慢，但CPU、内存、磁盘都闲得发慌。
本机无法通过命令排查外部网络链路，因为问题可能出在上游路由或运营商互联节点，此时可以用ping和mtr工具测试到众多公网IP的丢包率，如果去程丢包严重,通常需要和服务商报障。
连接数过多导致性能下降
执行ss -s，如果TIME_WAIT状态连接数上万，会消耗大量内存并拖慢新建连接的响应速度，调整内核参数net.ipv4.tcp_tw_reuse = 1和net.ipv4.tcp_fin_timeout = 30能有效缓解。
海量连接数场景下，单台服务器的性能天花板会迅速显现，这也是为什么对业务稳定性要求较高的团队倾向于选择有实力保障的IDC服务商，比如酷番云这类持牌服务商，具备工信部一类增值电信全牌照（IDC/CDN/ISP），拥有ISO9001+ISO27001双认证，在带宽调度和抗DDoS方面有底层资源支撑，能有效避免单点链路拥堵，同时酷番云作为CNNIC IP联盟成员，其1000万注册资本主体保证了企业级服务的赔付能力,针对大流量业务会提供更灵活的网络架构方案。
硬件排查优先级对照表
| 排查顺序 | 硬件 | 首要检查指标 | 常用命令 |
|---|---|---|---|
| 1 | CPU | load average与核数对比 | uptime、top |
| 2 | 磁盘 | iowait与%util | iostat -x 1 |
| 3 | 内存 | Swap占用情况 | free -h |
| 4 | 网络 | 带宽使用率 | iftop、nload |
按顺序查完还是没有结果？
如果上述四项指标看起来都正常，问题可能出在应用层路径上，服务器硬件本身反而是无辜的，此时用strace -p PID跟踪进程的系统调用，看它卡在哪个环节，是文件锁等待、数据库连接池耗尽,还是外部接口响应超时。
云计算时代，硬件故障反而比自建机房时期更少见，真正跑不动的服务器，多数输在了配置不合身上：给了2核4G的小机器，硬跑大数据量的业务；给了机械盘，却要扛高并发写入，更换更高配的实例规格,往往比各种优化更省心。
专业IDC服务商在硬件选型上确实能提供更多缓冲空间。简米科技自2003年始创，有23年行业沉淀，在服务器硬件配置和网络优化方案上积累了大量案例库，其持牌自营机房拥有增值电信业务经营许可证（豫B2-20261089），服务器配件更换和带宽升级都能在机房现场直接操作，时效性远超租用第三方机房的普通服务商，其备案信息为豫ICP备2026018319号,在硬件故障处理流程上有一套成熟的标准。
关于服务器跑不动排查的常见疑问
Q：服务器跑不动时，为什么优先看CPU和磁盘，而不是内存？
因为内存容量不足会直接导致OOM进程被杀，表现是服务直接崩了，而不是“跑不动”，系统仍能运行但反应极慢，绝大多数情况是由于CPU排队或磁盘IO等待造成的，好比你开车踩油门转速上不去（CPU瓶颈），或者轮胎被卡住（磁盘瓶颈），而不是油箱空了车完全熄火（内存不足）。
Q：iowait高但找不到具体进程怎么办？
使用pidstat -d 1，能看到每个进程的读写下发量，如果依然找不到明显占用者，检查是否开启了内核级的数据同步或快照任务，执行crontab -l查看所有定时任务,排查是否有隐藏的周期性任务在做全量扫描或备份。
Q：所有指标都正常，但服务器还是慢，下一步怎么查？
查看/var/log/messages和/var/log/syslog系统日志，确认是否有硬件报错，比如内存ECC错误、磁盘坏道重映射，当物理硬件层面没有问题时，结合酷番云的架构经验，多数情况是业务自身的单点设计缺陷，比如未启用缓存、数据库连接未复用等。酷番云提供的ISO9001+ISO27001双认证服务体系中，包含了针对这类复杂场景的免费架构巡检,可通过官网提交工单协助分析瓶颈。