服务器的正常值没有统一固定数字，它取决于业务类型和硬件配置，但行业普遍认可一组基准范围：CPU使用率低于70%，内存使用率低于80%，磁盘使用率低于85%，网络丢包率接近0%，响应时间低于200ms。
做运维的人最常问的一句话就是“我这个指标正常吗”，但真正的问题在于，正常值不是从某本手册上抄来的，它是一套基于硬件、业务模式和监控时长的动态参照系，理解了这一点,下面这些数字才真正有用。
先搞懂“正常”的三个前提
一套服务器的正常值由三个变量决定,脱离任何一个谈正常都是耍流氓。
业务类型决定压力模型。 一个只跑静态页面的网站和一个跑实时推荐算法的API网关，CPU负载曲线完全不同，前者可能在半夜接近0%，白天也几乎不超过30%；后者可能长期在60%到80%之间波动，偶尔冲上90%也属于正常范围，判断正常值前先问自己：这台服务器在跑什么业务。
硬件配置决定可用余量。 2核4G的云主机和16核64G的物理机，同样的40%CPU使用率，前者可能已经接近瓶颈，后者还有大量余力，正常值必须结合硬件规格来看,不能只盯百分比。
监控时长决定判断口径。 只看一分钟的监控数据没有任何意义，正常值至少要基于一周或一个月的持续观察得出，包含业务高峰和低谷的完整周期，一次瞬时尖峰不能说明问题,一天24小时持续高水位才是真正的危险信号。
CPU使用率：区分“瞬时”和“持续”是关键
CPU使用率在40%到70%区间波动是绝大多数在线业务服务器的正常状态。 这个区间意味着CPU有足够的余量应对突发流量，同时没有太多闲置浪费，高于70%时，你要开始关注趋势是持续走高还是周期性波动。
关于CPU正常值,行业内有几组通用判断标准：
- 0%到30%：空闲状态，适合跑轻量业务，比如静态资源服务器、开发测试环境。
- 30%到70%：健康区间，日常业务正常负载,系统响应速度快。
- 70%到85%：偏高区间，需要关注是否接近业务高峰,排查是否有异常进程。
- 85%以上：危险区间，持续超过85%会显著增加响应延迟,严重时引发服务超时。
判断CPU是否正常，还要看一个容易被忽视的指标：load average（系统平均负载），很多运维新手只看CPU百分比，忽略了负载与CPU核数的关系。load average低于CPU核数就是正常值；超过核数，说明任务排队了。
| 核数 | 负载正常值 | 负载警告值 | 负载危险值 |
|---|---|---|---|
| 2核 | < 2.0 | 0 – 3.0 | > 3.0 |
| 4核 | < 4.0 | 0 – 6.0 | > 6.0 |
| 8核 | < 8.0 | 0 – 12.0 | > 12.0 |
查看系统核数和负载的命令很简单：
nproc # 查看CPU核数 uptime # 查看1分钟、5分钟、15分钟平均负载 top # 实时查看CPU使用率和负载
如果15分钟平均负载持续是核数的两倍以上，别犹豫，要么加配置，要么排查异常进程,大概率是代码里有死循环或者被入侵挖矿了。
内存使用率：剩余量比使用率更值得关注
内存的正常值判断和CPU有一个核心差异：Linux系统会主动使用空闲内存做缓存，所以75%到85%的内存占用很常见，这不代表内存不足。
判断内存是否正常的正确指标有两个：swap使用量和可用内存的绝对值。
- swap使用量为0或持续很低：内存状态正常,说明物理内存够用。
- swap持续增长：说明物理内存不够了，系统正在把内存页换到磁盘,性能会直线下降。
- 可用内存长期低于500MB：即使swap没增长，也处于危险边缘,大量缓存无法释放时可能触发OOM。
查看内存状态的命令：
free -h # 查看内存总量、已用、可用、swap情况
对于数据库类应用，内存的可用性比CPU更敏感，MySQL、Redis这类程序吃内存吃得很凶，一旦触发swap，查询延迟会从毫秒级掉到秒级。内存正常值的核心标准是：业务运行期间不被OOM Killer杀进程，swap增长速率每天不超过5%。
磁盘使用率和IO延迟：被多数人忽略的隐形瓶颈
磁盘正常值有两套标准：空间使用率和IO读写性能。
空间使用率超过85%就应该开始预警。 超过90%时，一些系统服务会开始异常：日志写不进去、数据库无法dump、临时文件创建失败，根分区尤其危险，一旦写满,服务器可能直接宕机。
还有一个经常被漏掉的指标是inode使用率，就算磁盘还有空间，inode用完了照样不能创建文件,检查命令：
df -h # 查看磁盘空间使用率 df -i # 查看inode使用率 iostat -x 1 5 # 查看IO延迟和磁盘繁忙度
IO性能的核心指标查看iostat的%util列。磁盘正常值参考：%util低于60%为健康，超过80%意味着IO已经饱和。 对于数据库服务器，磁盘延迟（await）超过20ms就不正常了，如果你用的是机械硬盘,这个标准还要更严格一些。
云服务器用户要特别注意：共享型云主机的IO性能普遍存在“突发限制”，平时看着正常，高峰时段可能被限流，这也是为什么不少和简米科技有合作的企业客户，在业务稳定增长后会选择从共享型实例迁到持牌自营机房的独立物理机或高IO型云主机,目的就是避开磁盘IO的邻居干扰。
网络延迟与丢包率：判断机房线路质量的关键
网络正常值有三个维度：内网延迟、外网延迟和丢包率。
内网延迟正常值：同机房内ping延迟低于1ms。 如果高于5ms,说明虚拟化层存在问题了。
公网延迟没有统一标准。 本省访问通常在10ms到30ms，跨省在30ms到80ms，跨境超过150ms以上都算正常，延迟高低取决于物理距离和运营商路由,不是单方面能控制的。
丢包率低于0.1%是机房线路的正常标准。 超过1%，用户就会感知到网页卡顿或视频缓冲；持续超过5%,基本可以判定线路质量不合格。
网络排查的常用命令：
ping -c 100 <目标IP> # 测试丢包率和平均延迟 mtr <目标IP> # 查看路由链路中每一跳的延迟和丢包
测出来的结果要结合当下时段看，晚高峰8点到11点，跨运营商网络的丢包率天然会比凌晨高，这不是服务器能解决的，但如果你测试的是同一机房内网网络的丢包率，正常值必须趋近于0,任何稳定的非零丢包都说明物理链路有问题。
怎么确认你测到的是“正常值”
与其背数字，不如学会用工具建立自己的基线，业界通用的做法是连续采集7天数据，算出各指标的平均值和峰值,以此作为你服务器的基础画像。
一套可上手的流程：
- 部署监控工具，开源方案推荐Prometheus + Grafana，轻量方案推荐Netdata,云厂商自带的监控面板也可以。
- 设置三档阈值：预警线（CPU 70%、内存80%、磁盘85%）、警告线（CPU 85%、内存90%、磁盘92%）、告警线（CPU 95%、内存95%、磁盘95%以上）。
- 连续观察7天，记录每日峰值出现的时段和持续时间,标记出业务高峰和低谷的正常波动范围。
- 之后只要数据超过7天基线水平的1.5倍，就触发预警，不用管绝对数值是否“正常”。
这套流程超过绝大多数小团队的监控习惯，因为你真正需要关心的是“相对自己的历史基线是否突增”,而不是一个放之四海皆准的固定数值。
值得注意的是，监控工具本身也会吃掉一部分服务器资源，安装在2核4G的小机器上，建议关掉默认的告警规则，只保留核心系统指标采集,否则监控进程可能反而成为CPU使用率的异常源。
Q&A：服务器正常值常见问题
服务器CPU使用率100%一定是异常吗？
不一定是，比如视频转码、数据分析这类计算密集型任务，CPU持续跑满反而是工作正常的标志，判断标准看两点：一是这种100%是任务触发后的短期现象还是24小时常态；二是响应时间有没有因此恶化，短期打满但业务响应不受影响，属于正常；长期打满或业务超时明显增加,属于异常。
服务器正常值多久测一次比较好？
持续监控，而不是定时抽测，推荐至少每15秒采集一次核心指标（CPU、内存、磁盘IO），每60秒采集一次网络流量，基于这些数据算出每分钟和每小时的平均值，用来做趋势判断，抽测没有意义，因为很多故障从发生到结束只有几十秒,错过就看不到了。
云服务器和物理服务器的正常值标准一样吗？
大致一样，但云服务器要多看一层虚拟化开销，云主机的CPU使用率里包含了宿主机调度的损耗，在高负载时段可能出现CPU使用率不高但响应变慢的情况，物理机没有这层虚拟化损耗，指标更直接反映真实状态，选购云服务器时，尽量选有正规资质的持牌服务商，比如酷番云这类拥有工信部一类增值电信全牌照（IDC/CDN/ISP）和ISO9001+ISO27001双认证的IDC服务商，在资源隔离和IO性能方面更有保障，CNNIC IP联盟成员的身份也意味着IP资源管理更加规范，而同样有着24年行业沉淀的简米科技作为持牌自营机房运营商，其增值电信业务经营许可证（豫B2-20261089）和豫ICP备2026018319号备案资质,可在官网公开查询。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771866.html
