Linux uptime 命令：查看运行时长与平均负载

uptime 用一行显示当前时间、系统自启动以来的运行时长、登录用户数，以及最近 1、5、15 分钟的平均负载。它适合快速查看系统是否重启、负载是在上升还是缓和；平均负载不是 CPU 使用率，不能直接当成百分比。

uptime

Linux 平均负载反映可运行任务与不可中断等待任务的平均数量。判断性能问题时，还应同时查看 CPU 数量、CPU 使用率、存储与网络存储等待、内存和服务响应时间。

如何读取 uptime 的输出？

典型格式如下。这里的时间和数值用于说明字段，并非本机检测结果：

14:32:10 up 12 days, 3:41, 2 users, load average: 0.42, 0.51, 0.48

procps-ng 的 uptime 官方手册说明了这些字段及其顺序：

各个字段应该怎样理解？

当前时间

最前面的时间是系统当前认定的本地时间。如果与日志时间不一致，先核对日志是否使用 UTC，再检查时区及同步状态。在具备相应 systemd 服务的环境中，可执行：

timedatectl status

timedatectl 官方手册介绍了状态查询。最小镜像、非 systemd 系统或缺少服务连接的容器可能无法使用此命令；查询失败不等于时钟一定异常。

系统运行时长

up 后的值表示启动后经过的时间。如果明显短于预期，应结合启动记录和系统日志检查是否发生计划外重启、内核故障、电源问题或维护操作。

uptime -p
uptime -s

-p 输出便于阅读的时长，-s 输出推算的启动时间。不同发行版或实现支持的选项可能不同，先用 uptime --help 核对。较短的运行时长只是线索，无法单独确定重启原因。

登录用户数

用户数依据登录会话记录计算。同一用户同时打开 SSH 和控制台会话，可能被计数多次。可用以下命令查看会话、终端与登录时间：

w
who

这些记录不等于所有网络连接或应用会话。容器可能没有完整的登录记录；向他人提供输出前，也应检查用户名和连接来源等信息。

平均负载与 CPU 使用率有什么区别？

三个数值对应的时间范围

平均负载（load average）的三个值依次对应 1、5、15 分钟尺度。它们不是固定窗口中的简单算术平均；Linux 内核的负载计算实现使用指数衰减平均，因此不是某一瞬间的任务数。

• 1 分钟值高于 5、15 分钟值，可能说明近期负载上升。
• 1 分钟值更低，可能说明此前的高负载正在缓和。
• 三个值都持续较高，可能说明高负载已维持一段时间。

一次采样只能提供趋势线索，应连续观察并与服务响应时间对应。

结合 CPU 数量比较

平均负载没有按 CPU 数量归一化。可以先查看当前进程可用的处理单元数量：

nproc

例如，可用逻辑 CPU 为 4 个的环境与只有 1 个 CPU 的环境，同样的负载 1.00 不能按相同方式理解。如果任务主要受 CPU 限制，负载接近可用逻辑 CPU 数量，可作为处理能力占用较高的粗略线索；它并不能证明 CPU 使用率为 100%，也不能单独确定瓶颈。

GNU Coreutils 的 nproc 文档说明，默认值针对当前进程，可能小于系统在线 CPU 数量；新版还可能受 cgroup v2 CPU 配额及 OMP_NUM_THREADS、OMP_THREAD_LIMIT 环境变量影响。应核对本机版本、CPU 亲和性和容器限制，避免将不同范围的负载与 CPU 数量直接相除。

CPU 不忙，负载为什么仍然高？

Linux 负载不仅包含正在执行或等待 CPU 的任务，也包含不可中断状态的等待任务，常见原因是存储 I/O。慢磁盘或网络存储等待可能推高负载，同时 CPU 使用率仍然不高。普通网络连接等待并不会全部计入负载。

应分别查看 CPU 使用率、运行队列、I/O 等待、内存与交换空间。以下命令按需分别运行：

top
vmstat 1
iostat -xz 1
free -h

top 是交互程序，按 q 退出后再运行下一项；vmstat 1、iostat -xz 1 持续采样，按 Ctrl+C 停止。不要把这几行当成会自动执行完毕的批处理。

可结合 vmstat 的运行队列、阻塞任务和换入换出，iostat 的设备等待指标，以及 free 的可用内存进行判断。vmstat 手册和sysstat 的 iostat 手册说明，首份报告中的部分统计可能覆盖开机以来的情况，进程与内存等字段的范围则有所不同；应继续观察后续采样。iostat 通常来自 sysstat 包，未必已安装；字段和支持功能以本机手册为准。

常用 uptime 选项

输出易读的时长

uptime --pretty

-p 或 --pretty 只输出便于人阅读的运行时长，例如以天、小时和分钟表示。文本会受语言环境影响，不适合在脚本中依靠固定词语拆分。

查看启动时间

uptime --since

-s 或 --since 以 YYYY-MM-DD HH:MM:SS 格式显示推算的启动时间。上游实现用当前墙上时钟减去运行时长计算，因此系统时间大幅调整时，应与启动日志交叉核对；它不是一条独立保存的启动事件记录。

容器与原始格式

支持这些选项的 procps-ng 提供 --container，用于请求容器运行时长；--raw 则以原始格式显示数值，其中当前时间与运行时长使用秒：

uptime --container
uptime --raw

旧版 procps-ng 或其他 uptime 实现可能没有这些选项。容器信息不可访问时，查询可能失败；应检查退出状态和错误信息，不能将错误当成 0 秒。此处两行是分别查询，不表示原始格式会自动使用容器时长。

支持该功能的版本还可通过 PROCPS_CONTAINER 环境变量选择容器模式。原始格式的具体字段与选项组合，应按已安装版本的帮助和手册确认，不能假设所有发行版都相同。

负载偏高时，按什么顺序排查？

先确定趋势与资源范围

1. 连续观察 uptime 的 1、5、15 分钟值，确认上升、下降或持续情况。
2. 用 nproc 查看进程可用 CPU 数量，并核对宿主机、虚拟机或容器的统计范围。
3. 用 top 或 ps 查找消耗 CPU 的进程，确认是单个任务还是整体负载。
4. 用 vmstat、iostat 观察运行队列与 I/O 等待，并结合存储故障和网络存储状态。
5. 用 free 查看可用内存与交换空间，同时检查服务延迟和业务错误。

不要凭一个数值判定故障

短时压缩或备份可能使 1 分钟负载暂时升高。若 15 分钟值也持续上升、响应时间同时变差，才更需要调查持续瓶颈。阈值应结合平时流量、任务类型、CPU 数量、存储性能与服务目标制定。

持续观测时，在监控系统中同时收集负载、CPU、I/O、内存和应用指标，比反复看一次性输出更有用。先确认原因，再决定调整任务或资源，避免只因负载数值高就结束进程。

容器与虚拟机有哪些注意事项？

虚拟机中的 uptime 通常反映该客户操作系统的运行时长。容器共享宿主机内核，默认查询可能显示宿主机时长；应核对 procps-ng 的 --container 支持、运行时的命名空间配置及监控数据来源。

选择容器时长并不意味着平均负载也自动变成容器专属指标。负载可能仍来自宿主机范围，而容器 CPU 配额只限定本容器，二者不能直接套用同一阈值。还应检查编排平台的 CPU 请求、限制和节流指标，以及实际使用的 Coreutils 版本。

常见问题

平均负载 1.00 就表示 CPU 使用率 100% 吗？

不是。负载反映可运行任务和不可中断等待任务的平均数量，未按 CPU 数量归一化。CPU 使用率应另用 top、mpstat 等工具确认。

为什么运行时长突然变短？

常见原因是系统重启，但还要先确认是否切换了容器或统计范围。可结合 journalctl --list-boots、系统日志与维护记录检查更新、电源和内核问题；日志保留设置可能使旧启动记录不可用。

登录用户数为什么不同于实际人数？

同一个人可能同时建立多个 SSH 或控制台会话，也可能存在遗留或不完整的登录记录。用 w、who 查看终端和登录时间，不能将该值作为不同用户人数或所有应用连接数。

如何定时刷新 uptime？

安装了 watch 时，可以每 5 秒重新执行一次：

watch -n 5 uptime

按 Ctrl+C 停止。需要历史趋势与告警时，应使用监控系统，而不是长期盯着终端。

判断时的要点

uptime 是了解运行时长与负载趋势的起点。三个平均负载对应 1、5、15 分钟尺度，不能替代 CPU 使用率；负载偏高时，应结合 CPU、运行队列、I/O、可用内存和交换空间判断。内存字段的具体含义可参照英文 free 命令说明。