3、启动时间测量工具：使用systemd-analyze、bootchart、dmesg等工具量化启动耗时

启动优化工作的第一步，也是最关键的一步，是建立可量化的时间基线。没有精确的测量，任何优化都只是猜测。Linux 系统提供了多个强大的工具来剖析启动过程，其中 systemd-analyze 是 systemd 系统下的核心分析工具，bootchart 提供图形化的进程时间线，而 dmesg 则能揭示内核初始化阶段的耗时细节。本章将深入讲解这三类工具的原理、使用方法和实战技巧，帮助您建立一套完整的启动时间测量与诊断体系。

上图展示了 Linux 启动的三个主要阶段与对应测量工具的映射关系。内核阶段主要依赖 dmesg 和 bootchart 获取底层时间戳，用户空间阶段以 systemd-analyze 为主力，而应用阶段则需要结合多种工具进行综合分析。理解这个全景图有助于我们在面对启动性能问题时，快速定位应该使用哪种工具、关注哪个时间区间。

3.1 核心原理：启动时间如何被记录与呈现

Linux 启动过程的时间测量基于内核与 systemd 内置的时间戳机制。内核在启动过程中会在特定节点记录 printk 时间戳，这些时间戳以毫秒为单位，从内核启动的起始点开始计数。systemd 作为用户空间的第一个进程（PID 1），会记录每个单元（服务、挂载点、套接字等）的激活时间、启动完成时间以及依赖关系，从而构建出一棵完整的启动时间树。

systemd-analyze 的核心原理是读取 systemd 存储在内存中的启动事务日志（通过 D-Bus 接口获取），这些日志包含了每个单元的 activating 和 active 状态切换时间点。通过计算这些时间差，工具能够生成以下关键指标：

• 固件时间（firmware）：BIOS/UEFI 初始化耗时，从按下电源键到引导加载器开始执行。
• 加载器时间（loader）：GRUB 等引导加载器从开始执行到加载内核完成。
• 内核时间（kernel）：内核自解压、初始化核心子系统、挂载根文件系统的时间。
• 用户空间时间（userspace）：systemd 启动到默认目标（如 graphical.target）完成的时间。

对于 dmesg，它直接读取内核环形缓冲区中的消息，每条消息都带有精确的时间戳（自内核启动以来的秒数）。通过分析这些带时间戳的消息，可以精确到毫秒级地定位是哪个驱动初始化耗时过长，或者哪个硬件探测过程出现了延迟。

bootchart 则采用不同的策略：它在启动早期（通过内核参数或 systemd 服务）启动一个守护进程，以极高频次（通常每 200ms）采样系统的进程状态、CPU 使用率、I/O 等待等数据，最终生成一张 SVG/PNG 格式的图表，直观展示每个进程的启动时间线、CPU 负载和磁盘 I/O 活动。

3.2 判断方法与操作流程：从安装到输出解读

要有效使用这些工具，需要掌握正确的安装、配置和输出解读方法。以下是标准化的操作流程：

3.2.1 systemd-analyze 基础用法

在 systemd 系统上，systemd-analyze 通常预装。最常用的命令组合如下：

# 查看总体启动时间分解
systemd-analyze time

# 查看每个服务的启动耗时排序（关键命令）
systemd-analyze blame

# 生成 SVG 格式的启动过程依赖图
systemd-analyze plot > boot_plot.svg

# 生成关键链（critical chain）分析
systemd-analyze critical-chain

blame 命令的输出是优化工作的核心依据。它会列出所有已启动的服务，并按耗时从高到低排序。例如，输出可能显示 NetworkManager-wait-online.service 耗时 12.3s，这通常意味着网络等待是主要瓶颈。而 critical-chain 则显示从目标单元回溯到根依赖的完整链路，帮助理解哪些服务的延迟是串行依赖导致的。

3.2.2 dmesg 内核时间分析

内核日志的分析需要结合时间戳过滤。以下命令可以提取关键阶段耗时：

# 查看内核启动总耗时（最后一条消息的时间戳）
dmesg | tail -1

# 查看特定驱动初始化耗时（例如 USB 控制器）
dmesg | grep -i usb

# 查看根文件系统挂载时间
dmesg | grep -E "VFS|Mounting root"

# 使用 -T 选项显示人类可读时间
dmesg -T | grep "Kernel command line"

一个实用的技巧是使用 dmesg | grep -E "Freeing|Run /sbin/init" 来定位内核与用户空间的切换点。例如，如果看到 [1.234567] Run /sbin/init，说明内核阶段耗时约 1.23 秒。如果这个值异常高（如超过 5 秒），则需要深入检查驱动初始化。

3.2.3 bootchart 图形化分析

bootchart 有两种使用方式：传统独立工具和 systemd 内置的 systemd-bootchart。推荐使用后者，因为它与 systemd 集成更紧密：

# 安装 systemd-bootchart（Debian/Ubuntu）
sudo apt install systemd-bootchart

# 启用 bootchart 服务
sudo systemctl enable systemd-bootchart

# 重启后，图表生成在 /var/log/bootchart.png

生成的图表包含四个主要区域：CPU 使用率曲线、磁盘 I/O 曲线、进程执行时间线（每个进程一条横线，长度代表运行时间）、以及内存使用情况。通过观察进程时间线的重叠程度，可以判断系统并行度是否充分。如果发现大量进程串行执行，说明存在依赖关系需要优化。

3.3 案例拆解：一次真实的启动延迟诊断

下面通过一个实际案例，展示如何综合运用上述工具定位并解决启动缓慢问题。某嵌入式设备（基于 Intel Atom 平台，运行 Yocto Linux）报告启动时间长达 45 秒，而产品需求是 20 秒以内。

初始测量：首先运行 systemd-analyze time 获得基线数据：

Startup finished in 3.2s (firmware) + 1.8s (loader) + 8.5s (kernel) + 31.5s (userspace) = 45.0s

初步判断：固件和加载器时间尚可，但内核时间 8.5s 和用户空间 31.5s 均异常偏高。接下来使用 systemd-analyze blame 查看用户空间瓶颈：

 12.3s NetworkManager-wait-online.service
  8.2s mysql.service
  5.1s systemd-udev-settle.service
  3.4s docker.service
  2.5s postgresql.service

显然，NetworkManager-wait-online.service 是最大瓶颈。该服务会等待网络接口完全就绪，在无 DHCP 或网络不可达的环境中会持续超时。同时，systemd-udev-settle 等待所有设备事件处理完毕，也拖慢了启动。

深入分析：使用 dmesg 检查内核阶段耗时分布：

[0.000000] Linux version 5.10.9
[1.234567] ACPI: IRQ9 used by pinctrl
[3.456789] usb 1-1: new high-speed USB device
[6.789012] i915 0000:00:02.0: [drm] Initialized i915
[8.123456] Run /sbin/init

发现 USB 设备探测耗时约 3.3 秒（从 3.4s 到 6.7s），i915 显卡驱动初始化耗时约 2.3 秒。进一步检查发现，USB 总线上挂载了一个响应缓慢的触摸屏控制器，其固件在枚举阶段需要等待超时。

优化措施：

1. 禁用 NetworkManager-wait-online.service：sudo systemctl mask NetworkManager-wait-online.service。由于设备使用静态 IP，无需等待网络在线。
2. 调整 udev 规则，将 systemd-udev-settle 替换为更精确的设备匹配规则，避免全局等待。
3. 在设备树中为触摸屏控制器添加 broken-cd 属性，跳过 CD 检测，减少 USB 枚举超时。
4. 将 MySQL 和 PostgreSQL 的启动顺序延后，并启用 systemd 的 socket 激活，使其在收到连接请求时才真正启动。

结果对比：优化后再次测量：

Startup finished in 3.1s (firmware) + 1.7s (loader) + 5.2s (kernel) + 8.3s (userspace) = 18.3s

总启动时间从 45 秒降至 18.3 秒，满足需求。其中内核时间减少 3.3 秒（USB 优化），用户空间减少 23.2 秒（服务优化）。

复盘经验：本次优化成功的关键在于：首先用 blame 快速锁定用户空间的最大耗时服务，然后用 dmesg 深入内核阶段定位硬件初始化问题。值得注意的是，NetworkManager-wait-online 在无网络环境下的超时等待是嵌入式设备常见陷阱，应默认禁用。此外，systemd-udev-settle 的滥用也值得警惕，它往往被用于掩盖不完善的 udev 规则。

3.4 常见误区与总结复盘

在使用这些测量工具时，工程师常陷入以下误区：

为了获得准确、可复现的测量结果，建议遵循以下最佳实践：

• 每次测量前确保系统状态一致（关闭不必要的后台任务，使用相同的内核参数）。
• 至少测量 3 次取平均值，排除偶发因素（如磁盘缓存、网络延迟）。
• 使用 systemd-analyze plot 生成 SVG 图，并保存每次优化的版本，便于对比。
• 对于内核阶段，开启 initcall_debug 内核参数，获取每个驱动函数的精确耗时。
• 结合 perf 工具（如 perf sched）分析调度延迟，但注意 perf 本身会引入一定开销。

最后，需要强调的是，启动时间优化是一个迭代过程。测量工具的价值不仅在于发现问题，更在于验证优化效果。每次修改后，都应重新运行完整的测量流程，确保没有引入新的瓶颈。下表总结了三个工具的核心特性与适用场景：

工具	主要输出	适用阶段	优势	局限性
systemd-analyze	文本/SVG 时间线、服务耗时排序	用户空间	精确到服务级别，支持依赖链分析	无法深入内核内部函数
dmesg	带时间戳的内核日志	内核阶段	毫秒级精度，可定位驱动问题	日志量大，需要 grep 过滤
bootchart	SVG/PNG 图表	全阶段	直观展示并行度、CPU/I/O 负载	采样频率有限，无法精确到毫秒

在实际项目中，建议将 systemd-analyze 作为主要分析工具，dmesg 作为内核问题定位的补充，bootchart 用于宏观并行度评估。三者结合，能够覆盖从按下电源键到系统完全就绪的每一个环节，为启动优化提供坚实的数据基础。