Linux 系统中怎么使用 systemd-analyze 诊断启动性能瓶颈-linux运维-PHP中文网

直接用 systemd-analyze 就能系统性诊断启动慢问题：time 查 kernel/initrd/userspace 三阶段耗时，blame --all --no-pager 找卡在 activating 或 failed 的慢 mount 单元，critical-chain 揭示最长依赖链中真实阻塞点，plot 生成 svg 时序图可视化并行与阻塞关系。

linux 系统中怎么使用 systemd-analyze 诊断启动性能瓶颈

直接用 systemd-analyze 就能系统性诊断启动慢的问题，它不依赖额外安装，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+、麒麟、UOS 等）都自带。关键不是看“哪个服务名字长”，而是分阶段查清时间在哪被吃掉、谁在等谁、哪些环节实际串行阻塞。

看三阶段耗时分布：kernel / initrd / userspace

运行：

systemd-analyze time

输出类似：

Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s

这三段是严格串行的，顺序不能颠倒：

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 或 GRUB

注意：该命令不统计 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间，只反映 systemd 接管后的可测部分。

找真正拖后腿的服务：用 blame --all --no-pager

运行：

systemd-analyze blame --all --no-pager

--all 很关键——默认只列 active 状态的服务，但真正卡住启动的，常是处于 activating 或直接 failed 的 .mount 单元（比如 /mnt/backup.mount 指向已拔掉的 USB 盘，或 fstab 里写了不可达的 NFS 地址）。

--no-pager 防止终端截断长名（如 dev-disk-by\x2duuid-1234567890abcdef.mount 显示不全）。

重点关注耗时 ≥ 500ms 的条目，尤其是：

Yuanfang Design System

yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。

下载

NetworkManager-wait-online.service：常因 DHCP 超时卡住，默认等待 30 秒才放弃
docker.service：启动时扫描本地镜像、初始化存储驱动，可能阻塞数秒
各种 .mount 单元：检查是否漏写 nofail 或 x-systemd.timeout=5

注意：blame 只统计 unit 从 start 到 running 的 active 时间，不包含依赖等待、I/O 延迟等前置开销，所以实际耗时常被低估。

查真实依赖瓶颈：critical-chain 揭示最长阻塞链

运行：

systemd-analyze critical-chain --no-pager

它展示的是从 default.target（或 graphical.target）向上回溯的**最长依赖路径**，每一步的时间是“该 unit 自身启动耗时”，不包含上游等待时间。

例如输出：

default.target @18.420s
└─multi-user.target @18.420s
  └─ssh.service @15.200s +0.850s
    └─network-online.target @12.105s
      └─NetworkManager-wait-online.service @2.199s +10.000s

这里关键不是看 +10.000s 最大，而是看 @2.199s → @12.105s 这个近 10 秒的间隔——说明 NetworkManager-wait-online.service 启动很早，但它自己只花了 0.85 秒，却让下游等了 10 秒，问题大概率出在它依赖的上游（比如网络接口未就绪、DHCP 未响应）。

实用技巧：