Linux怎么查看系统的启动项耗时 Linux下systemd-analyze详解

systemd-analyze time 的三阶段分别指 kernel（内核初始化至 init 创建）、initrd（initramfs 阶段，含 LVM/加密卷处理）和 userspace（systemd 加载所有 unit 总耗时），其中 userspace 占比超 80% 时需用 blame --all 定位卡在 activating 或 failed 的 .mount 单元。

systemd-analyze time 显示的不是整机通电到登录的全程耗时，只是 systemd 接管后的三段计时；真正拖慢开机的单元，往往藏在 systemd-analyze blame --all 里，尤其是卡在 activating 状态的 .mount 单元。

systemd-analyze time 输出的三个阶段分别代表什么

运行 systemd-analyze time 得到类似这样的输出：
Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 16.479s

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

systemd-analyze blame 默认不显示挂载失败的 .mount 单元

systemd-analyze blame 默认只列出状态为 active 的 unit，但很多启动慢的根因是 .mount 单元卡在 activating (start) 或直接 failed —— 比如 /etc/fstab 里写了已拔掉的 USB 设备、未响应的 NFS 服务器、或 UUID 错误的磁盘。

• 必须加 --all 才能强制列出所有已加载 unit（含 failed/activating）
• 必须加 --no-pager，否则终端宽度截断长名，比如 dev-disk-by\x2duuid-1234567890abcdef.mount 会显示不全
• 看到某 .mount 耗时异常（如 10s+），先用 systemctl status 看其 LoadState 和 ActiveState，再查 journalctl -u -b 确认是设备不可达还是权限/超时

NetworkManager-wait-online.service 高耗时别急着禁用

这个 service 经常排在 blame 前几名，但直接 systemctl disable NetworkManager-wait-online.service 可能导致依赖它的服务（如 docker、nfs-client）启动失败或网络不可用。

Media.io

多功能的AI视频和图像处理平台

下载

• 先看日志：journalctl -u NetworkManager-wait-online.service -b，90% 场景是 DHCP 获取 IPv4 超时（默认 30s）或等待 IPv6 RA（Router Advertisement）
• 临时绕过：在 /etc/NetworkManager/conf.d/10-no-wait.conf 中加 [main] dns=none; rc-manager=unmanaged 并重启 NetworkManager
• 更稳妥的改法：编辑 /etc/systemd/system/NetworkManager-wait-online.service.d/override.conf，设 ExecStart=/usr/bin/nm-online -s -q -t 5（把超时从 30s 缩到 5s）

critical-chain 显示的“最慢路径”不等于必须优化的点

systemd-analyze critical-chain 输出的是依赖树中最长的一条串行链，但它反映的是设计上的关键路径，不是性能瓶颈本身。例如：

• 某 mariadb.service 在链上耗时 8s，但它可能只是因为 multi-user.target 依赖它，而其他服务并不等它——此时优化它对整体启动时间几乎没影响
• 真正要盯的是那些 @ 时间晚（启动晚）、+ 时间长、且被多个 target 依赖的单元，比如 network-online.target 或自定义的 storage-ready.target
• 用 systemctl list-dependencies --reverse 查谁依赖它，比单看 critical-chain 更准

最容易被忽略的是：.mount 单元和 .target 单元的启动状态不会出现在默认 blame 列表里，而它们恰恰最常造成“启动卡住但看不出哪慢”的现象。每次排查前，先跑一遍 systemd-analyze blame --no-pager --all | head -30，比盯着 time 数字更有用。