Linux怎么查看系统启动耗时

systemd-analyze time 直接显示 kernel、initrd、userspace 三阶段耗时，分别对应内核启动、initramfs 执行和 systemd 服务加载；blame --all --no-pager 揭示真实瓶颈（如 activating .mount 单元）；critical-chain 展示最长依赖路径，需结合 blame 判断真因；plot 生成 SVG 时序图辅助分析。

直接运行 systemd-analyze time 就能知道总耗时和瓶颈在哪一阶段，不用猜、不用装额外工具。

看三阶段耗时分布用 systemd-analyze time

它输出类似 Startup finished in 718ms (kernel) + 1.713s (initrd) + 17.079s (userspace) = 19.511s，这三个值是连续阶段，不是并列：

• kernel：从内核第一条指令执行到 systemd 进程（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 --no-pager

systemd-analyze blame默认仅会列出状态为active的service和mount单元，然而，真正导致启动缓慢的，常常是那些处于activating状态或者直接failed的.mount单元（比如/etc/fstab中写入了已拔掉的USB盘、不可达的NFS地址等情况）。

• 必须加 --all：强制列出所有已加载 unit（含 failed、activating、inactive）
• 必须加 --no-pager：防止终端宽度截断长名，比如 dev-disk-byx2duuid-1234567890abcdef.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）的最长依赖链。要知道，这里每一步所显示的时间，指的是“该unit自身启动所花费的时间”，并不包括其上游等待的时间。这一点很容易让人产生误解，以为是这个环节慢所以需要优化它，可实际上呢，它本身可能启动得很快，只是被上游给卡住了。

• 如果链条末端是 NetworkManager-wait-online.service，但 blame 显示它只花了 0.2s，而链条里显示 +6.7s，说明它前面的依赖（如 network-pre.target）在等网络通，而实际网络压根没配好
• 若链条中间出现 dev-disk-byx2duuid-xxx.device 或 initrd-switch-root.service，说明瓶颈在内核初始化、initramfs 解压/挂载、或根文件系统识别阶段——这些阶段 systemd 尚未接管，blame 统计无效，此时应切换诊断路径：检查 initramfs 大小、确认磁盘 UUID 是否稳定、查看 dmesg -t | head -20 看内核日志起点

生成可视化时序图用 systemd-analyze plot

systemd-analyze plot > boot.svg 可导出 SVG 格式的启动时序图，直观展示服务依赖与并行/串行关系。图中横向为时间轴，每条色块代表一个 unit 的启动过程，重叠表示并行启动，空隙反映等待依赖。

• 需要系统已安装 graphviz（多数桌面发行版默认带，服务器版可能需手动装）
• 若提示 Failed to get dependency graph，通常是权限不足，尝试加 sudo（但通常不需要）
• 重点观察那些耗时长且 WantedBy=multi-user.target 或 WantedBy=default.target 的服务，它们更可能影响用户可见的启动终点

真正卡住启动的单元，往往藏在 blame --all 里，尤其是卡在 activating 状态的 .mount 单元——它们不会出现在默认 blame 列表里，却会把整条关键路径拖慢十几秒。