Linux系统如何查看系统启动耗时 systemd-analyze用法【详解】-LINUX-PHP中文网

systemd-analyze time 仅统计 systemd 接管后的三阶段耗时，不含 bios/uefi、grub、内核解压等前置时间；kernel 阶段超 1s 查固件设置与驱动，initrd 高耗时查加密/lvm 配置，userspace 占比超 80% 则需用 blame --all 定位慢服务及挂载单元。

linux系统如何查看系统启动耗时 systemd-analyze用法【详解】

systemd-analyze time 显示三阶段耗时不准？

直接运行 systemd-analyze time 得到的数值，是 systemd 从自身接管控制权开始计时的，并不包含 BIOS/UEFI 自检、GRUB 菜单停留、内核解压等前置时间。所以它反映的是“可测量的启动链”起点，不是整机通电到登录界面的全程。

输出中三个字段含义必须分清：kernel 是从内核第一条指令执行到 init 进程被创建的时间；initrd 只在启用 initramfs 时出现，含加密卷解锁、LVM 扫描等动作；userspace 才是 systemd 加载所有 unit 的总耗时——这个值最值得盯紧。

如果 kernel 阶段 > 1s，优先检查 BIOS/UEFI 设置（如 Fast Boot 是否开启）、NVMe 驱动是否内置、Secure Boot 是否引发额外验证
initrd 耗时高，重点查 /etc/crypttab 中密码提示方式、rd.md=0 rd.lvm=0 等内核参数是否误禁用了必要模块
userspace 占比超 80%，说明问题在服务层，下一步必须用 blame

systemd-analyze blame 排查慢服务时漏掉 mount 单元？

systemd-analyze blame 默认只显示已成功激活（active）的 unit，但挂载失败或卡在 activating (start) 状态的 .mount 单元不会出现在列表里——它们会拖慢整个关键路径，却隐身了。

真正要抓全，得加两个参数：systemd-analyze blame --no-pager --all。其中 --all 强制列出所有已加载 unit（包括 failed 和 activating 状态），--no-pager 避免因终端宽度截断长服务名（比如带 UUID 的 dev-disk-by\x2duuid-xxx.mount）。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

重点关注耗时 > 500ms 的 .mount 单元：它们往往对应 /etc/fstab 中配置了但设备不可达的条目（如拔掉的 USB 盘、未挂载的 NFS 服务器）
看到 NetworkManager-wait-online.service 耗时高，别急着禁用——先用 journalctl -u NetworkManager-wait-online.service -b 看日志，大概率是 DHCP 超时或 IPv6 RA 等待卡住
第三方服务（如 docker.service、prometheus-node-exporter.service）若耗时突增，用 systemctl show -p ExecMainPID <code>service-name 查 PID，再结合 strace -p <code>PID 看卡在哪个系统调用上

critical-chain 显示的“瓶颈”其实可以绕过？

systemd-analyze critical-chain 输出的是依赖树中最长的一条串行链，但它不等于“必须优化的点”。有些 unit 处于关键路径上，只是因为设计如此（比如 multi-user.target 依赖 network.target，而后者又依赖 NetworkManager.service），并非性能缺陷。

判断是否真瓶颈，要看两点：一是该 unit 自身耗时是否异常（对比 blame 结果）；二是它是否真的被下游服务强依赖。例如 getty@tty1.service 出现在关键链末端，但除非你必须秒级登录，否则它不影响业务就绪时间。

若发现某个服务（如 cloud-init.service）长期霸占关键链头部，且耗时稳定在 3~4s，大概率是云平台元数据服务响应慢，可考虑在 /etc/cloud/cloud.cfg.d/99-disable.cfg 中设 disable_root: true 并关掉非必要模块
想临时跳过某环节？不要直接 systemctl disable，而是改 unit 文件，在 [Unit] 段加 Wants= 替代 After=，或用 systemctl mask 彻底切断依赖（慎用）
critical-chain 不显示并行启动的服务，所以总耗时永远 ≤ 最长链耗时 —— 这也是为什么优化单个服务未必缩短整体启动时间

plot 生成的 SVG 图打不开或报错？

systemd-analyze plot > boot-time.svg 生成的图本质是 XML 格式 SVG，浏览器能打开，但部分旧版 Chrome 或 Firefox 会因安全策略拒绝加载本地文件中的脚本（SVG 内嵌 JS）。这不是生成失败，是渲染限制。

更可靠的方式是用 systemd-analyze dot | dot -Tpng -o boot-time.png 转成 PNG——前提是系统装了 graphviz。CentOS/RHEL 需 yum install graphviz，Ubuntu/Debian 用 apt install graphviz。

图中横向色块越长，代表该 unit 启动越慢；色块重叠越多，说明并行度越高；空隙越大，说明等待依赖越久
如果发现大量服务在某个时间点后才开始启动（比如 8s 后突然密集出现），说明前面有个隐形的同步点（如 local-fs.target 或自定义 target）卡住了
注意：图中显示的耗时是相对时间（从 systemd 启动开始），和 time 命令的绝对值一致，但和 blame 的倒序排列逻辑不同——plot 更适合看并发关系，而非排序找“最慢”

实际排查时，time 定范围、blame 锁目标、critical-chain 看依赖、plot 验并发，四者缺一不可。最容易被忽略的是：很多“慢启动”根本不是 systemd 层面的问题，而是硬件响应（如 SATA Link Down 重试）、固件 Bug（某些 Intel RST RAID 卡在 initrd 阶段死等）、甚至 BIOS 电池没电导致 CMOS 时间回滚触发证书校验延迟——这些在任何 systemd-analyze 输出里都不会体现。