systemd-analyze 是什么
启动慢、单元有隐患时，需要一个工具把问题量化出来：按耗时列出各服务的启动时间，找出关键的串行依赖链，或者在启用前校验单元文件的语法与可执行文件是否存在。它既是启动性能的分析器，也是上线前的自检工具——写好的单元先校验再启用，能避免上线后才发现路径写错、依赖缺失这类低级问题。
基本信息
| 适用平台 | 使用 systemd 的 GNU/Linux |
|---|---|
| 常用子命令 | 耗时排行、关键链分析、单元校验 |
| 输出解读 | 时刻标记表示阻塞点，加号前缀表示自身耗时 |
| 使用时机 | 启动优化与单元上线前自检 |
| 注意 | 没有 systemd 启动流程的环境没有数据 |
| 校验意义 | 警告中提到的可执行文件不存在时上线必然失败 |
典型使用场景
- 系统启动变慢时定位耗时最长的服务。
- 找出启动关键链上的串行阻塞点。
- 新写的单元文件启用前做语法与依赖校验。
- 排查服务启动失败：确认依赖单元与可执行路径。
- 变更后对比启动耗时，验证优化效果。
常用写法
常用写法
systemd-analyze time # 固件、引导与用户空间的总体耗时
systemd-analyze blame | head -n 15 # 各单元耗时排行
systemd-analyze critical-chain myapp.service # 目标服务的关键依赖链
systemd-analyze verify /etc/systemd/system/myapp.service # 单元自检
systemctl list-units --failed --no-pager | head # 启动失败的单元
systemd-analyze blame | awk '$1 ~ /s$/ {print}' | head # 只保留带时间单位的行子命令与现象读法
| 子命令或现象 | 含义 | 使用要点 |
|---|---|---|
| time | 总体启动耗时拆分 | 先看固件与引导各占多少 |
| blame | 单元耗时排行 | 找优化对象的第一步 |
| critical-chain | 关键依赖链 | 时刻标记代表阻塞点 |
| verify | 单元校验 | 上线前的必做动作 |
| 失败单元列表 | 异常单元 | 结合状态与日志定位原因 |
| 无数据 | 缺少启动流程 | 容器环境属于正常现象 |
关键链输出里的时刻标记表示阻塞点、加号前缀表示自身耗时：先解决阻塞点，再处理自身耗时大的单元，优化顺序不能反。
校验给出的警告要当真：警告中指向的可执行文件不存在时，单元一定启动失败，这类问题在启用前发现成本最低。
容器或没有 systemd 启动流程的环境里看不到启动耗时数据，属于正常现象，不代表工具坏了。