直接运行 systemd-analyze time 即可获取总耗时及 kernel/initrd/userspace 三阶段连续耗时，精准定位 systemd 接管后的瓶颈；kernel 超 1s 查 BIOS/驱动，initrd 高耗时查加密/LVM 配置，userspace 占比超 80% 则需用 blame --all 深挖挂载失败或激活中服务。
直接运行 systemd-analyze time 就能获得系统开机引导的总耗时和三阶段分布，这是 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+ 等）自带的最简准确定位方式，无需安装额外工具。
看总耗时与三阶段拆解
执行命令：
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 扫描、加密卷解锁、RAID 初始化等；耗时高常见于 /etc/crypttab 配置了交互式密码，或内核参数误加 rd.md=0 导致设备识别失败
- userspace：systemd 加载所有 unit 的总耗时；若占比超 80%，说明瓶颈在服务层，下一步必须用 blame --all 深入分析
注意：该命令不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。
查真正拖慢启动的服务和挂载单元
默认的 systemd-analyze blame 会漏掉卡在 activating 或已 failed 的单元，尤其是那些写在 /etc/fstab 里但设备已拔掉、NFS 不可达、UUID 错误的 .mount 单元——它们常是隐形瓶颈。
务必加上两个参数：
systemd-analyze blame --no-pager --all
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
重点关注耗时 ≥ 500ms 的条目，特别是：
- NetworkManager-wait-online.service：大概率因 DHCP 超时（默认 30s）或等待 IPv6 RA 卡住，先查日志：journalctl -u NetworkManager-wait-online.service -b
- docker.service：可能被镜像扫描阻塞
- dev-disk-by\x2duuid-*.mount 等挂载单元：检查是否漏写 nofail 或 x-systemd.timeout=5
理清依赖链路，避免误判瓶颈
systemd-analyze critical-chain 展示的是从启动起点到 default.target（或 graphical.target）的最长依赖路径，每级显示的是该 unit 自身启动耗时，不含上游等待时间。
例如输出末尾是：
└─NetworkManager-wait-online.service @12.345s +6.7s
而 blame 显示它自身只花了 0.2s，说明问题不在它，而在它的上游依赖（如 network-pre.target），实际可能是网络根本没配好。
常用命令：
- systemd-analyze critical-chain --no-pager（防截断）
- systemd-analyze critical-chain graphical.target（桌面环境适用）
可视化验证并行与阻塞关系
生成 SVG 时序图，直观查看哪些服务本应并行却因依赖被串行化：
systemd-analyze plot > boot.svg
用浏览器打开 boot.svg，观察：
- 长条服务是否真的独立耗时，还是被前面某个灰色空闲段“吊着”
- 多个服务是否集中在同一时间段启动（说明缺乏并行度）
- 是否存在明显空档（提示某关键服务提前退出或失败）
这个图配合 blame 和 critical-chain 使用，能快速区分是服务本身慢，还是被依赖拖累。
