systemd-analyze 通过 blame、critical-chain 和 plot 三命令协同诊断启动瓶颈：blame 列出各服务自身耗时，critical-chain 追踪关键依赖链定位阻塞点，plot 可视化并发与等待关系，共同识别可并行化或延迟加载的服务。
systemd-analyze 是诊断 systemd 启动性能的核心工具，blame、critical-chain 和 plot 三个子命令分别从不同角度揭示启动瓶颈。关键不是看总耗时，而是识别「谁拖慢了整个链路」以及「哪些服务可以并行或延迟加载」。
blame：找出耗时最长的单元（但不等于瓶颈）
执行 systemd-analyze blame 会按初始化耗时倒序列出所有已启动 unit（主要是 .service），例如：
12.456s nginx.service<br>8.721s mariadb.service<br>4.302s NetworkManager-wait-online.service<br>2.109s docker.service<br>...
⚠️ 注意：
– 这里的耗时是「该 unit 自身启动所花时间」，不是它导致系统变慢的时间；
– 高耗时 service 不一定拖慢整体启动（比如它可能在空闲期才运行）；
– 真正影响启动速度的是「阻塞其他服务启动」的单元（尤其是那些被大量依赖的）。
✅ 建议：
– 先检查排在前几位的是否为非必需服务（如测试用的 nginx、数据库）；
– 若是必须服务，再查其启动慢的原因（配置错误、磁盘 I/O 等）；
– 可用 systemctl show -p ExecStart,Type,RemainAfterExit <unit></unit> 查看启动方式（forking？simple？是否需要等待）。
critical-chain：定位真正拖慢启动的“关键路径”
systemd-analyze critical-chain 显示从 graphical.target（或 multi-user.target）回溯到最早启动单元的依赖链，即「最慢的那条依赖路径」：
graphical.target @15.234s<br>└─multi-user.target @15.234s<br> └─mariadb.service @6.512s +8.721s<br> └─network-online.target @6.501s<br> └─NetworkManager-wait-online.service @2.199s +4.302s<br> └─NetworkManager.service @1.987s +0.212s<br> └─dbus-broker.service @1.201s +0.785s<br> └─basic.target @1.198s<br> └─sockets.target @1.198s<br> └─dbus.socket @1.197s +0.001s<br> └─sysinit.target @1.196s<br> └─...（继续向上）
? 关键点：
– 每行末尾的 @X.XXXs 表示该 unit 实际开始启动的时间点（相对于 boot 开始）；
– +Y.YYYs 是它自身运行耗时；
– 整条链的总耗时 ≈ 最后一个 unit 的 @ 时间 + 其 + 时间；
– 链中最长的 @ 间隔（如 NetworkManager-wait-online.service 在 @2.199s 才启动，但 network-online.target 要等到它完成才能推进）往往是瓶颈所在。
✅ 建议：
– 重点优化链中「启动晚 + 耗时长」的单元（如 NetworkManager-wait-online.service）；
– 若不需要严格等网络就绪，可禁用该服务并改用 network.target 替代 network-online.target；
– 检查是否有服务错误地 Requires/After 了高延迟单元（比如某个应用强制 After mariadb.service，但其实只需数据库 socket 存在即可）。
plot：可视化整个启动过程与并发关系
systemd-analyze plot > boot.svg 生成 SVG 时间线图，横轴为时间，每行是一个 unit，颜色表示状态（浅蓝=waiting，深蓝=running，绿色=done）。图中清晰显示：
- 哪些服务是串行启动（垂直堆叠）
- 哪些服务真正并行（横向重叠）
- 是否存在大片空白（CPU/IO 空闲但无服务启动）
- 是否存在长时间 waiting（如等待某个 socket 或 target）
✅ 实用技巧：
– 用浏览器打开 SVG，Ctrl+F 搜索服务名快速定位；
– 观察「waiting」区域是否集中在某几个 target（如 network-online.target 或自定义 target）；
– 如果多数服务都在等同一个单元完成，说明它是关键阻塞点；
– 若发现大量服务启动时间非常接近（几乎同列），说明它们被正确并行化，无需干预。
常见可落地的优化方向
不必追求极致，优先解决明显不合理项：
- 禁用开机自启的非必要服务：
sudo systemctl disable snapd.service lxd.service等 - 将
Wants=network-online.target改为Wants=network.target（适用于大多数内网/有线环境） - 对启动慢但非核心的服务启用
LazyStart=yes（需 systemd v249+）或改用OnDemand=truesocket activation - 检查
/etc/fstab中挂载项：移除 noauto 或失败挂载（尤其 NFS/CIFS），或加x-systemd.device-timeout=5 - 避免在
ExecStartPre中执行耗时脚本（如 curl、复杂 grep）
优化后再次运行 systemd-analyze time 对比 total boot time 和 kernel + initrd 时间占比，验证效果。
