Linux怎么查看系统启动详细耗时

直接运行systemd-analyze time命令，就能清晰地看到总耗时以及瓶颈所在阶段：它会输出kernel、initrd、userspace这三段连续的耗时，分别对应内核初始化、initramfs执行、systemd加载所有unit的时间。当userspace的耗时占比超过80%时，就需要使用blame --all命令来进一步排查处于activating或failed状态的.mount单元。

直接看 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段，不用猜、不用装额外工具——所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+ 等）都自带这个命令。

用 systemd-analyze time 快速定位三段耗时分布

它输出类似 Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s，这三个值不是并列关系，而是启动链上的连续阶段：

• kernel：从内核第一条指令执行到 init 进程（PID 1）创建完成；超 1s 就该查 BIOS Fast Boot 是否开启、NVMe 驱动是否内置、Secure Boot 是否引发额外验证
• initrd：仅启用 initramfs 时存在，含 LVM 扫描、加密卷解锁等；高耗时常见于 /etc/crypttab 配置了交互式密码，或内核参数误加了 rd.md=0 导致 RAID 初始化跳过失败重试
• userspace：systemd 加载所有 unit 的总耗时；占比超 80% 说明问题在服务层，下一步必须进 blame，而不是调 BIOS

注意：systemd-analyze time 不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。

用 systemd-analyze blame --all 抓全慢单元

systemd-analyze blame默认只会列出状态为active的.service和.mount单元，然而，真正拖慢启动速度的，常常是那些卡在activating (start)状态，或者直接处于failed状态的.mount单元。比如说，/etc/fstab里写了已经拔掉的USB盘、无法访问的NFS地址等情况。

• 必须加 --all 才能看到 failed、activating、inactive 等所有已加载 unit
• 必须加 --no-pager 防止终端截断长名字，尤其对 UUID 命名的设备（如 dev-disk-byx2duuid-xxx.mount）
• 重点关注耗时 ≥ 500ms 的条目，特别是 NetworkManager-wait-online.service（常因 DHCP 超时卡住）、docker.service（镜像扫描阻塞）、以及各种 .mount 单元（检查 /etc/fstab 是否漏写 nofail 或 x-systemd.timeout=5）

用 systemd-analyze critical-chain 看真实依赖瓶颈

systemd-analyze critical-chain 展示的是从启动起点到 default.target（或 graphical.target）的**最长依赖路径**，每一步都含实际耗时，比 blame 更能反映“为什么启动慢”。

• 例如它可能显示：default.target → multi-user.target → sshd.service → network-online.target → NetworkManager-wait-online.service，而最后一步耗时 12s——这说明 SSH 启动被网络就绪卡住，而非 sshd.service 本身慢
• 如果链条末端是 NetworkManager-wait-online.service，但 blame 显示它只花了 0.2s，而链条里显示 +6.7s，说明它前面的依赖（如 network-pre.target）在等网络通，而实际网络压根没配好
• 若链条中间出现 dev-disk-byx2duuid-xxx.device 或 initrd-switch-root.service，说明瓶颈在内核初始化、initramfs 解压/挂载、或根文件系统识别阶段——这些阶段 systemd 尚未接管，blame 统计无效

生成 SVG 时序图辅助判断并行与阻塞

systemd-analyze plot > boot.svg 导出的图表能直观看出哪些服务是串行等待、哪些是并行启动，还能发现隐性依赖导致的空档。

• 图中横向为时间轴，每条色块代表一个 unit 的启动过程；重叠表示并行，空隙反映等待依赖
• 需安装 graphviz（部分系统已预装）；若提示 Failed to get dependency graph，可能是权限不足，尝试加 sudo（但通常不需要）
• 红色高亮常指向问题点，比如某个 .mount 单元长时间独占启动线程，或某 service 在中间突然拉长整个链条

真正卡住启动的单元，往往藏在 blame --all 里，尤其是那些没显示耗时数字、只卡在 activating 状态的 .mount 单元——它们不会出现在默认 blame 输出中，却可能让整条 critical-chain 多等 30 秒。