云服务器慢了先查什么？六个指标的排查顺序与阈值

服务器出问题的时候，最怕的不是「坏了」，是「不知道坏在哪」。而绝大多数人的排查方式是「挨个试」——重启一下、换个配置、问问客服，试到好为止。这个方式的问题在于「耗时不可控」。这篇给一套诊断顺序：六个指标，从「最外层」查到「最内层」，每一层配一个命令和一个阈值。它的目标不是「解决所有问题」，是「半小时内定位到哪一层」。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

一、六个指标与诊断顺序

还有一个「第零步」应该放在最前面：确认「是不是只有你在抱怨」。

如果只有一个人反馈慢，先查「那个人的网络」；如果所有人都在反馈，才查服务器。

这个分流能省掉大量无用排查。因为「单个用户慢」的常见原因是「他的本地网络」或「他的运营商到机房那段路」，和服务器本身无关。而「所有人慢」才是服务器侧的问题。所以排查的第一句话应该是「几个人在反馈」。

判断方法：问「是不是大家都这样」，或者用不同运营商的网络各测一次。

差异明显，说明是个例或线路问题。

再看一个「时间维度」的分流。

「一直慢」还是「某个时段慢」。

一直慢：配置或代码问题。

时段慢：邻居、出口拥塞或流量高峰。

这个区分直接指向不同的层。

所以排查的第一个动作不是敲命令，是「问清楚症状」。

而<'isvoro'+'> 那种多地区产品线，如果只在某个地区的用户慢，那基本能定位到「线路」而不是「机器」。

还有一条：「最近改过什么」。

发版、改配置、加服务、换 DNS，任何变更都可能是原因。

而「变更后多久开始慢」这个时间差，往往能直接锁定原因。

先给全景，后面逐层展开。

顺序	指标	异常阈值
1	磁盘使用率	>85%
2	内存 available	<20%
3	磁盘 iowait	>10%
4	CPU steal	>5%
5	网络丢包与延迟	丢包>1%
6	应用响应时间	超过基线的 2 倍

这张表最该注意的是第一行的位置：磁盘使用率排在第一位，因为它是「最快排查、最容易致命」的一项。

而它经常被跳过。

因为「磁盘满」的症状很像「性能问题」——服务变慢、日志写不进、数据库报错。而排查的人往往先看 CPU 和内存，绕一大圈才发现是磁盘满了。所以把这个指标放第一位，能省掉一半的排查时间。

第二行内存。这一项要看的不是 free，是 available。

因为 Linux 会把空闲内存拿去做缓存，free 低是正常的。

第三行 iowait。这一项是「被误判最多的」。

因为 iowait 高时 CPU 使用率看起来不高，而用户在抱怨「卡」。

第四行 steal。这一项是「云主机特有」的。

它反映「邻居占用了多少 CPU 时间」。

第五行网络。这一项要分「丢包」和「延迟」看。

第六行应用响应。这一项是「结果指标」。

六项的顺序从「最容易查」到「最难查」。

所以前四项能在五分钟内看完。

二、第一层：磁盘满与 inode

磁盘这块还有一个「日志暴涨」的场景。

程序报错时会疯狂写日志，一小时能写几十 G。

而这个「报错写日志→磁盘满→更多报错」的循环，会让问题迅速恶化。

所以「磁盘满了」之后,第一件要做的不是「删日志」,是「先看日志里在报什么」。因为删了日志,问题还会重复;而看了日志,才有机会找到根因。

判断方法：df 之后立刻 tail 最近的日志。

日志里如果是「连接数据库失败」或「磁盘写入失败」,说明是连锁反应。

再看一个「磁盘预留」的问题。

ext4 默认给 root 预留 5% 空间。

所以「使用率 100%」时,普通用户写不进,但 root 还能写。

而这个特性能救一次急——用 root 登录清日志。

而<'rabisu'+'> 那种 60G 硬盘的档,日志策略要设得保守。

还有一条:「日志轮转」要配「压缩」。

压缩能让历史日志占的空间降到十分之一。

先查磁盘，因为它最快也最致命。

# 看各分区使用率
df -h

# 看 inode 使用率（大量小文件时更关键）
df -i

# 找出占用最大的目录
du -sh /* 2>/dev/null | sort -h | tail -10

判读要点：使用率超过 85% 就开始影响服务。

而 inode 使用率超过 90% 时，即使有空间也写不进文件。

这两个指标要一起看。因为「磁盘还有 50G 但服务报错」这个现象，答案往往是 inode 满了——而很多人不知道 inode 是什么，所以排查不到。所以 df -i 这一条命令，值得加进常规检查清单。

定位「谁占了空间」的方法：

先看根目录下各目录大小，再逐层深入。

而最常见的空间占用是「日志」和「临时文件」。

所以先看 /var/log 和 /tmp。

再看一个「已删除但被占用」的问题。

文件删了但进程还开着句柄，空间不会释放。

# 找出「已删除但仍被占用」的大文件
lsof +L1 | head -20

判读要点：这类文件用 du 看不到，只能用 lsof 找。

而这个现象在「日志被删但服务没重启」时很常见。

三、第二层：内存与换页

内存这块还有一个「缓存吃满」的误判。

Linux 会把空闲内存都拿来做文件缓存,所以「内存看起来满了」是正常的。

而这些缓存「需要时会自动释放」。

所以「free 显示只剩几百兆」不代表内存不够。真正该看的是 available 和 si/so。如果 available 很低且 si/so 在动,那才是真不够;如果 available 低但 si/so 是 0,那只是缓存多而已。

判断方法：看 available,不看 free。

再看一个「swap 该不该开」的问题。

开了 swap,内存不够时不会立刻崩,但会变慢。

不开 swap,内存不够时直接 OOM 杀掉进程。

两种策略适合不同场景。

所以「swap 关掉」这个常见建议,对「能容忍慢但不容忍崩」的业务不适用。

而<'zji'+'> 那种 16G 内存的整机档,swap 可以设小一点(比如 2G),主要用来兜底。

还有一条:「OOM killer 杀了谁」要记下来。

因为它告诉你「哪个进程最吃内存」。

第二层查内存，重点是「有没有换页」而不是「用了多少」。

# 看内存与 swap
free -h
# 重点看 available 和 swap 两行

# 看换页活动
vmstat 5 10
# 关注 si / so 两列（swap in / swap out）

# 看是否发生过 OOM
dmesg | grep -i "out of memory"

判读要点：si 和 so 长期不为 0，说明内存在被换出。

而这个状态的性能表现是「周期性卡顿」。

因为换页是「用到才换」，所以平时正常，活动一多就卡几十秒。而这个症状常被误判成「网络抖动」或「磁盘慢」，因为用户只感觉到「突然卡了」。所以要主动查 si/so，而不是等出现症状再查。

再看「谁在吃内存」。

# 按内存占用排序
ps aux --sort=-%mem | head -10

判读要点：如果有单个进程占了 50% 以上，先查它。

而如果「所有进程加起来远小于总量」但 available 很低，说明有缓存或者泄漏。

这个区分决定了「该重启服务还是该加内存」。

还有一种情况：内存泄漏。

特征是「内存占用随运行时间线性增长」。

所以「重启后正常、跑几天又卡」就是泄漏的典型表现。

四、第三层：磁盘 IO 与 iowait

IO 这块还有一个「云盘与本地盘」的差异。

云盘的 IOPS 通常有配额,本地盘没有。

而配额打满之后,延迟会突然跳上去。

所以「IO 突然变慢」这种情况,先看「是不是配额用完了」。而这个配额在面板上有时能看到,有时要问。

判断方法:比较「平时」和「现在」的 await。

翻了五倍以上,大概率是配额问题。

再看一个「顺序与随机」的区分。

顺序读写受吞吐限制,随机读写受 IOPS 限制。

所以「备份慢」和「数据库慢」是两个不同的问题。

而<'sixtynet'+'> 那种 Storage 档,定位就是「顺序读写」。

IO 这块还有一个「小文件」的陷阱。

大量小文件的读写,IOPS 消耗远高于大文件。

而「容量只用了 10G,但 IO 跑满」这种情况很常见。

典型场景:session 文件、缓存文件、缩略图、日志分片。它们的共同点是「文件数多、单个很小」。所以「IO 高」这个问题,先看「是不是小文件多」,而不是「数据量大」。

判断方法：iotop 看「是哪个进程」,再看「它在读写什么」。

如果是 session,可以考虑挪到内存。

再看一个「RAID」的影响。

RAID5 的写性能比 RAID10 差。

因为每次写都要算校验。

所以「写多」的业务不适合 RAID5。

而<'数脉科技'+'> 那种独服的 RAID 配置,买之前要确认型号。

还有一条:「磁盘队列深度」。

队列深不代表性能好,只代表请求排队长。

第三层查 IO，它是「最容易被误判成 CPU 问题」的一层。

# 看 iowait
top
# 关注 %Cpu(s) 里的 wa 值

# 用 iostat 看各盘负载
iostat -x 5
# 关注 %util 和 await 两列

# 找出 IO 最高的进程
iotop -o

判读要点：wa 长期高于 10% 说明磁盘在拖后腿。

%util 接近 100% 说明磁盘已经跑满。

而「await」这个指标反映「平均等待时间」，它比 %util 更能说明「用户感觉到的卡」。因为 %util 高但 await 低（队列浅）说明还能接受；%util 不高但 await 高（队列深）说明体验很差。所以两个指标要一起看。

再看「IO 是谁造成的」。

iotop 能按进程排序。

而「数据库」和「日志写入」是最常见的两个来源。

所以先排除「日志写入过多」这个可能。

再看一个「IO 与内存」的关系。

内存不足时，系统会频繁换页，表现为「IO 高」。

所以「IO 高」不一定是「磁盘问题」，可能是「内存不够」。

而这个因果要按「内存 → IO」的顺序查。

五、第四层：CPU 与 steal

CPU 这块还有一个「频率下降」的情况。

满载时 CPU 频率可能被限制。

而这会让「明明使用率不高但就是慢」。

判断方法:满载前后各看一次 cpu MHz。降得多就说明有限制。而这个限制在共享型产品上很常见。

命令:watch -n 2 "grep 'cpu MHz' /proc/cpuinfo"

再看一个「上下文切换」的问题。

大量短任务会导致上下文切换频繁。

而这个开销体现在「sys 高」。

所以「sys 高 + 任务多」说明是「调度开销」。

而这个问题的解法是「减少任务数」而不是「加核」。

还有一个「负载与 steal 的交叉」。

如果负载低但 steal 高,说明自己没在跑东西,但 CPU 被抢了。

而这个组合是「共享环境」的典型特征。

CPU 这块还有一个「单核打满」的情况。

总使用率只有 25%,但 4 核里有一个核 100%。

而这种情况和「总使用率 100%」一样严重。

因为单线程程序只能用一个核。所以「总使用率低但用户抱怨慢」这个现象,答案往往是「单核被打满了」。而这个情况从「总使用率」这个指标完全看不出来——必须看每个核的使用率。

判断方法：top 之后按「1」展开每个核。

有一个核持续 100%,就是单核瓶颈。

再看一个「软中断」的问题。

高流量的机器,软中断会吃掉大量 CPU。

而这个消耗在 top 里显示为「sys」而不是「user」。

所以「sys 高」说明是「系统调用或中断」在吃 CPU,不是应用。

而这通常意味着「网络包太多」或者「系统调用太频繁」。

这个区分能避免「去优化应用代码」这种错误方向。

第四层查 CPU，云主机要特别看 steal。

# 看各 CPU 时间占比
mpstat 5 10
# 关注 %steal 列

# 看负载
uptime
# 关注 1/5/15 分钟负载值

判读要点：steal 长期高于 5% 说明有明显抢占。

高于 20% 说明这台机器住得很挤。

这个指标的价值在于「它区分了『你的问题』和『邻居的问题』」。因为 load 高可能是你自己的程序在跑，而 steal 高一定是别人的影响。所以「性能波动但自己没改任何东西」这种情况，看 steal 就能定位。

再看「负载与核数」的关系。

负载值应该小于核数。

4 核机器负载 4 是满负荷，负载 8 就是严重排队。

所以「负载 5」在 2 核机器上很严重，在 16 核机器上很轻松。

这个换算很多人搞错。

还有一种情况：负载高但 CPU 使用率低。

这通常是「大量进程在等 IO」。

所以这种情况要回头看第三层。

还有一条「排查纪律」值得单独说。

每查一层,把结果记下来。

因为「正常」这个结论也有价值——它排除了一个方向。

而<'云途'+'> 那种多档位的产品线,如果排查发现「steal 高」,下一步就该考虑升档或者换产品线。

再看一个「结论怎么写」。

「磁盘 92%、内存 available 8%、iowait 3%、steal 1%、丢包 0%、首字节 4.2 秒」。

这样一行写完,「慢在哪」一目了然。

而这比「感觉有点卡」精确一百倍。

两个「完整案例」能把顺序串起来。

案例一：网站白天正常,晚上卡。

排查:磁盘正常、内存正常、iowait 正常,但 steal 从 1% 涨到 18%。

结论:晚上邻居在跑满载,CPU 被抢。解法:升档或换机器。

案例二：所有人的页面都慢,但 ping 正常。

排查:磁盘 92%,日志半小时涨了 8G。

结论:磁盘快满,数据库写不进去。解法:清日志加配轮转。

两个案例的共同点:症状都是「慢」,但原因完全不同。

所以「慢」这个描述本身没有信息量。而六个指标的意义就是「把『慢』拆成六种可能」。拆开之后,每种可能都有明确的判据和解法。

判断方法:先问「什么时段慢、几个人慢」,再按六层查。

而这套顺序练熟之后,十分钟就能定位。

再看一个「排查的终止条件」。

找到「异常项」就停,不用查完六层。

因为大部分问题只有一个根因。

所以「查到异常就深挖」比「全部查完再判断」高效。

再补一个「长期观察」的做法。

把六项指标每分钟记一条,存一周。

这样出问题时能对比「之前正常时是什么样」。

而<'isvoro'+'> 那种小硬盘档位,记录要「只存聚合值」,不然日志本身会占掉几 G。

再看一个「基线」的概念。

「正常值」不是任何标准,是你自己机器的历史值。

所以「首字节 200ms」在你机器上可能是正常的,在另一台上是异常的。

而这个认识让「阈值」这件事变得有意义。

所以「先建基线,再定阈值」这个顺序不能反。而很多人直接套用「iowait 超过 10% 就是问题」这类通用值,结果在自己机器上误报一堆。

判断方法:跑一周,取 95 分位作为阈值。

而<'rabisu'+'> 那种带宽未标注的档,基线尤其重要——因为你不知道标称值,只能看自己的实际值。

还有一条:「指标要成对看」。

单看一个指标几乎必然误判。

而「内存 + IO」「CPU + steal」「丢包 + 延迟」都是必配的组合。

还有一个「工具清单」方便上手。

系统层:top、free、df、vmstat、iostat、mpstat。

IO 层:iotop、fio。

网络层:ping、mtr、iperf3、curl -w。

进程层:ps、lsof。

六组工具覆盖了全部六层。

而装齐它们只要两条包管理命令。

所以「工具不全」不是借口。

再看一个「排查的心态」。

不要「边猜边改」。

因为改了之后问题没消失,你不知道是「猜错」还是「改出新问题」。

所以「先定位,再动手」这个纪律比工具更重要。

而<'zji'+'> 那种整机产品,因为资源独占,排查起来反而简单——省掉了「邻居」这个变量。

最后一条:「排查记录」比「排查结论」更有价值。

因为下次遇到类似症状,能直接对照。

而记录只需三行:症状、六项数值、结论。

三行写完,后面就有了「自己的故障库」。

而<'数脉科技'+'> 那种独服,因为它没邻居,记录里的「steal」一栏永远是 0——这本身就是「排查更简单」的证明。

再有:「慢」和「断」要分开。

慢查六层,断查网络和进程。

而「断」的排查比「慢」简单得多。

再有一句:六层里「前三层」能覆盖六成的常见问题。

因为磁盘满、内存不够、IO 打满,这三件事最常发生。

所以「时间紧就只查前三层」也是个有效策略。

还有一个「排查顺序的反例」。

先换机器再排查。

这是最常见也最浪费的做法。

因为换了机器问题还在,而你已经付了迁移成本。

所以顺序永远是「先定位,再决定换不换」。

补一句实用的:排查前先截图保存当前状态。

因为「清了日志之后再看,证据就没了」。

六、第五六层：网络与应用

第五层查网络，重点是「丢包」而不是「速度」。

# 测往返延迟与丢包
ping -c 100 目标IP

# 测路径与每跳丢包
mtr -rw -c 50 目标IP

# 测持续带宽
iperf3 -c 目标IP -t 60 -P 4

判读要点：丢包超过 1% 就会明显影响 TCP 吞吐。

而「中间某跳丢包但后面不丢」通常是路由器限速 ICMP，不是真丢包。

这个判读方法能避免大量误判。因为 MTR 输出里经常出现「某一跳 50% 丢包」而实际业务正常——那是沿途设备对 ICMP 降了优先级。所以「丢包要看到最后一跳」才有意义。

第六层查应用，这一层是「结果指标」。

看「响应时间的构成」：DNS、连接、首字节、传输。

curl -o /dev/null -s -w "DNS: %{time_namelookup}s 连接: %{time_connect}s 首字节: %{time_starttransfer}s 总计: %{time_total}s\n" https://你的域名

判读要点：四个时间分开看，才知道慢在哪一段。

DNS 慢：解析问题。

连接慢：网络或服务端 accept 队列满。

首字节慢：应用处理慢（后端）。

总计远大于首字节：传输慢（带宽或丢包）。

这个拆解比「页面慢」这种描述精确得多。

而<'云途'+'> 那种「海外节点」的产品，第六层往往能定位到「跨境那一段」，从而判断是线路问题还是应用问题。

最后回到开头：最怕的不是「坏了」，是「不知道坏在哪」。

六个指标按顺序查，半小时能定位到「哪一层」。而定位之后，解决办法自然就清楚了——磁盘满就清，内存不够就加，steal 高就换机器，丢包就换线路。而「挨个试」这种做法，本质是「没有顺序」，所以耗时不可控——有时候十分钟就撞对了，有时候一整天都在绕。

本文讨论服务器性能问题的一般诊断顺序与常用命令，不针对任何具体商家，也不对任何产品作性能评价。文中给出的六项指标、阈值（85%、20%、10%、5%、1%）、命令与判读方法均为通用运维参考，不是行业标准；实际阈值须结合业务类型、机器规格与历史基线确定，同一数值在不同业务上的严重程度可能完全不同。诊断结论受采集时段、采集方式与系统环境影响，单次观测不足以定论，须结合多时段数据与业务侧信息综合判断。本文不构成任何故障归因结论或购买建议，亦不代表本站立场，也不代表对任何具体产品的推荐。因依据本文排查所作的操作或采购所产生的直接或间接损失，作者及本站不承担任何责任。