Linux服务器如何查看系统运行时间？uptime与系统负载分析

接到一台服务器，想知道它是不是刚刚重启过、跑了多久、现在忙不忙，最快的方法就是看一眼运行时间和负载。但很多人只会敲一个 uptime，看到三个数字就开始猜：这三个数字什么意思？0.5 算高还是低？为什么 4 核的机器负载 4 就已经很满了？把这些搞明白，能让你在排查性能问题时少走很多弯路。

这篇文章会从最基础的"怎么看运行了多久"讲起，把 uptime、w、top、/proc/uptime 这些工具串起来，重点讲清楚系统负载（load average）到底代表什么、多少算正常、怎么结合 CPU 核数判断，以及负载高时怎么往下定位是 CPU 瓶颈、IO 瓶颈还是内存不足。

读完之后你应该能做到两件事：一是快速判断一台机器"健不健康、忙不忙"；二是当负载异常时，知道用哪几个命令继续深挖，而不是盯着数字干着急。文中给出的阈值都是常见经验值，具体要结合业务特点判断。

一、最直接的方式：uptime

uptime 是最简单也最常用的命令，一行输出包含了运行时长、在线用户数和负载平均值：

uptime
# 输出示例：
#  14:32:10 up 23 days,  4:11,  2 users,  load average: 0.15, 0.10, 0.05

拆开来读：

• 14:32:10：当前系统时间。
• up 23 days, 4:11：系统已经连续运行 23 天 4 小时 11 分。如果这个值很小而你没主动重启过，就要警惕是不是非计划重启或崩溃了。
• 2 users：当前登录的用户会话数（不是唯一用户数，同一用户多个终端会重复计数）。
• load average: 0.15, 0.10, 0.05：过去 1 分钟、5 分钟、15 分钟的平均负载。

很多人会把它和 w 混着用，其实 w 输出的第一行和 uptime 一模一样，下面还会列出每个登录用户在干什么：

w
# 显示第一行是 uptime 内容，下面列出 USER / TTY / FROM / LOGIN@ / IDLE / JCPU / PCPU / WHAT

还有个更精确的"运行了多少秒"，来自内核：

cat /proc/uptime
# 输出：1995600.42 1980000.10
# 第一个数字是系统已运行秒数，第二个是所有 CPU 空闲时间累加

要给脚本用、只想要一个干净的数字，可以用：

# 运行了多少秒
cut -d. -f1 /proc/uptime

# 精确到分钟
awk '{printf "%d 分钟\n", $1/60}' /proc/uptime

# 换算成"天 时:分"
awk '{d=int($1/86400); h=int(($1%86400)/3600); m=int(($1%3600)/60); printf "%d天 %d小时 %d分\n", d, h, m}' /proc/uptime

# 查看本次启动时间（很多发行版通用）
who -b
# 输出：system boot  2026-09-19 10:20

# systemd 系统更推荐用这个看启动时间与耗时
systemd-analyze
# 输出：Startup finished in 3.421s (firmware) + 2.100s (loader) + 5.200s (kernel) + 12.30s (userspace) = 23.02s

systemd-analyze 不仅能告诉你什么时候启动的，还能告诉你启动花了多久、哪一步最慢，这在排查"开机慢"时非常有用（后面第 009 篇会专门展开）。

二、关键概念：load average 到底是什么

这是全篇最重要的部分，也是最容易被误解的。

负载平均值不是 CPU 使用率。 它统计的是"在采样周期内，处于可运行状态（runnable）和不可中断睡眠状态（uninterruptible sleep，通常是等 IO）的进程数量的平均"。换句话说，它统计的是"有多少任务在排队或正在跑"，而不是"CPU 有多忙"。

这一点非常关键：

• 一个进程正在用 CPU → 计入负载。
• 一个进程在等磁盘 IO 或网络文件系统、处于 D 状态（不可中断睡眠）→ 也计入负载。
• 一个普通睡眠、等待事件的进程 → 不计入。

所以负载高不一定代表 CPU 忙，也可能是磁盘很慢。反过来，CPU 使用率 100% 但只有一个进程在跑，负载可能也就 1 左右。这是新手最容易搞混的地方。

uptime 给出的三个数字是 1 分钟、5 分钟、15 分钟的平均值。它们组合起来看趋势：

简单记：看趋势比看单点更有意义，1 分钟远高于 15 分钟说明系统正在变忙。

三、负载多少算正常？一定要结合核数

"负载 3 高不高？"这个问题没有绝对答案，必须结合 CPU 核心数。核心数可以用下面几个命令看：

# 逻辑 CPU 核数（含超线程）
nproc
getconf _NPROCESSORS_ONLN
grep -c ^processor /proc/cpuinfo

# 物理核 / 插槽 / 线程的详细信息
lscpu
# 关注：CPU(s) 总数、Thread(s) per core、Core(s) per socket、Socket(s)

经验判据（仅供参考，需结合业务）：

举例：一台 4 核机器，负载 0.5~2 属于比较从容，负载到 4 就是满载，负载 8 以上就明显过载了。而一台 32 核的机器负载 10 其实还相当轻松。所以脱离核数谈负载没有意义。

再补充一个前提：在容器（Docker/K8s）里，/proc/loadavg 反映的是宿主机的负载，而不是容器的。容器内看到的负载可能很高，但那不一定是你的容器造成的，排查时要结合宿主机的视角，或看容器的 cgroup 指标（cpu.stat 等）。

四、负载高怎么继续往下查

看到负载高，别急着下结论，用下面的顺序定位瓶颈类型。

第一步，看整体并找出消耗 CPU 的进程：

# top 交互界面，按 1 展开每核，按 P 按 CPU 排序，按 M 按内存排序
top
# 常用交互键：
#   1 展开/收起每个核心
#   P 按 CPU 使用率排序
#   M 按内存排序
#   r 给进程改优先级(nice)
#   k 杀进程

# 非交互式快照，适合脚本/日志
top -b -n 1 | head -20

# 更好用的替代：htop（需安装）
htop

# ---- 按发行版安装 htop / iotop ----
# RHEL / Rocky / AlmaLinux
sudo dnf install -y htop iotop sysstat

# Debian / Ubuntu
sudo apt install -y htop iotop sysstat

第二步，区分是 CPU 忙还是 IO 卡。 看 top 顶部的状态行：

• %Cpu(s) 里的 us（用户态）、sy（内核态）高 → CPU 计算瓶颈。
• %Cpu(s) 里的 wa（iowait）高 → 磁盘或网络 IO 瓶颈。
• %Cpu(s) 里的 st（steal）高 → 虚拟机/容器被宿主机"偷走"了 CPU，云主机上常见。

# iostat 看磁盘 IO（sysstat 包，首次用前可能要先启动采集）
iostat -x 1 5
# 关注 %util（接近 100% 说明磁盘接近饱和）、await（平均等待毫秒）、r/s w/s

# vmstat 综合看，第 1 列 r 是运行队列长度，b 是阻塞进程数
vmstat 1 5
# r 持续 > 核数 说明 CPU 排队；b 大说明有进程卡在 IO

# sar 看历史趋势（sysstat 需开启定时采集）
sar -q 1 5      # 队列和负载
sar -u 1 5      # CPU

第三步，定位具体是什么进程在制造负载：

# 按 CPU 排序取前 10
ps -eo pid,ppid,user,%cpu,%mem,stat,cmd --sort=-%cpu | head -11

# 找出处于 D 状态（卡在 IO）的进程
ps -eo pid,stat,cmd | awk '$2 ~ /D/'

# 看某个进程的 IO 情况
sudo iotop -oP
sudo pidstat -d 1 5        # sysstat 提供

状态列的几个字母要记住：R 运行中、S 可中断睡眠、D 不可中断睡眠（通常等 IO）、Z 僵尸、T 停止。如果 b 列和 D 状态进程很多，基本可以锁定是 IO 问题，去查磁盘阵列、云盘 IOPS、NFS 挂载这些。

五、几个常见误区

误区一：负载高就是 CPU 满。 前面说过，负载包含等 IO 的进程。磁盘慢、NFS 卡、甚至某些内核问题都会推高负载。要结合 wa 和进程状态判断。

误区二：负载必须低于 1 才正常。 这是把单核经验套到多核上了。多核机器负载可以到核数都没问题。

误区三：在容器里用 uptime 判断自身负载。 容器共享宿主内核，/proc/loadavg 是宿主机的。容器内要结合 cgroup 限制和宿主的 %st 来看。

误区四：只看 1 分钟负载。 单点数字波动大，一定要看 1/5/15 分钟的组合趋势，必要时用 sar 看历史。

误区五：把在线用户数当并发用户。 uptime 里的 2 users 是登录会话，和业务并发量完全无关。

六、把负载纳入日常监控

单看一次 uptime 只能了解当下，真正有价值的做法是把负载记录下来看趋势。用 sysstat 定时采集，sar -q 可以回看任意一天的负载曲线；再结合 sar -u、sar -r、sar -b 分别看 CPU、内存和 IO，基本能把"哪天几点开始变慢"还原出来。经验上，一台稳定运行的服务器其 15 分钟负载应该长期贴着一条平缓的基线上下波动，如果这条基线本身在缓慢抬升，往往意味着业务量在持续增长、存在慢查询或内存泄漏，属于需要提前扩容或优化的信号，而不是等到告警拉满才处理。

设置告警阈值时不要照搬固定数字，建议以"CPU 核数的 0.8 倍"作为提醒线、"1.5 倍"作为严重线（经验值），再结合业务能否接受短时排队来调整。对容器环境，更应该看 cgroup 的 CPU 使用与限流指标，而不是宿主机的负载值。把负载、CPU 各态时间（us/sy/wa/st）和磁盘 IO 一起采集，才足以支撑一次可靠的容量判断；只看负载单个指标容易误判，尤其是当瓶颈其实在 IO 或内存时。

常见问题

Q1：怎么快速知道服务器上次重启是什么时候？
用 who -b 看启动时间，用 uptime 看已运行时长，用 last reboot | head 看历史重启记录，用 systemd-analyze 看本次启动耗时。

Q2：负载 1.0 在单核上是快满了吗？
是的，单核机器负载接近 1 就基本满载，超过 1 开始排队。多核要按核数放大。

Q3：为什么 CPU 使用率不高但负载很高？
典型是 IO 瓶颈——大量进程处于 D 状态等磁盘或网络文件系统。用 iostat -x、ps 查 D 状态进程确认。

Q4：云主机负载不高但业务很卡，怎么回事？
看 top 里的 %st（steal），如果偏高说明宿主机资源争抢，你的虚拟机被"偷"了 CPU，需要联系云厂商或升级规格。

Q5：怎么持续监控负载而不只是看当前值？
安装 sysstat 并启用采集服务，用 sar -q 看历史；或接入 Prometheus node_exporter + Grafana 做可视化告警。

总结

• uptime 一行就能给出运行时长、登录数和 1/5/15 分钟负载；/proc/uptime 给精确秒数，who -b 和 systemd-analyze 看启动信息。
• 负载平均值统计的是运行和不可中断睡眠的进程数，不等于 CPU 使用率，IO 阻塞同样会推高负载。
• 判断负载是否正常必须结合 CPU 核心数（nproc/lscpu），经验上超过核数即为过载，具体阈值需结合业务。
• 负载异常时按"top 看整体 → 用 wa/st 区分 CPU 与 IO → ps/iostat/iotop 定位具体进程"的顺序排查。
• 容器内看到的是宿主机负载，云主机要额外关注 %st，持续观察比看单点更有价值。