Linux系统启动项及耗时分析方法

本文深入解析了 systemd-analyze 这一内置于所有主流 systemd 发行版（如 Ubuntu 16.04+、CentOS 7+、统信UOS 等）的原生诊断利器，通过 time、blame、critical-chain 和 plot 四大子命令，精准揭示系统启动慢的真实原因——不是罗列“开机启动项”，而是追踪实际运行的 unit 及其耗时分布、依赖阻塞链路与并行关系；它帮你区分 firmware/kernel/initrd/userspace 各阶段瓶颈，识别伪装成“元凶”的拖后腿服务（如 NetworkManager-wait-online），并穿透依赖层层定位根因（例如 sshd 慢实为上游 tmpfiles 卡死），辅以 SVG 可视化图谱直观呈现启动时序，是 Linux 系统启动优化不可或缺的终极指南。

systemd-analyze 是唯一需要的工具，不用装额外包，所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 9+、麒麟OS、统信UOS）都自带。它不查“开机启动项列表”，而是查「实际启动了哪些 unit 及各自耗时」——这才是定位慢启动的真实依据。

systemd-analyze time 看总耗时与阶段分布

直接反映从硬件上电到桌面就绪的完整链条，不是“服务数”，而是“时间在哪被吃掉”：

• firmware 和 loader 阶段高，说明 BIOS/UEFI 设置、Secure Boot 或 GRUB 超时配置有问题
• kernel 高，常见于内核参数不当（如 rd.driver.pre 加载顺序错）、驱动缺失或硬件自检卡住
• initrd 高，多因加密卷解锁交互、LVM/RAID 设备扫描超时，或 initramfs 缺少必要模块（如 nvme 或 dm-crypt）
• userspace 高，才是 service 层优化主战场；注意 graphical.target reached after 的值，它才是你感知到“桌面出来了”的真实耗时

systemd-analyze blame 找真正拖后腿的服务

它只列出「本次成功启动」的 unit，失败、跳过、被 mask 的都不会出现——别误以为没列出来就安全：

• 加 --no-pager 防止卡在 less：运行 systemd-analyze blame --no-pager
• 重点关注耗时 ≥ 1s 的 .service，例如：NetworkManager-wait-online.service（等 DHCP 超时）、docker.service（镜像扫描）、plymouth-quit-wait.service（等待开机动画退出）
• 也留意 .mount 单元，比如 /mnt/nfs.mount 耗时 8s，大概率是 fstab 里写了不可达 NFS 地址且没设 nofail,x-systemd.timeout=5
• 某些服务含 RandomDelaySec=，单次结果波动大，建议重启 2–3 次再比对中位数

systemd-analyze critical-chain 锁定阻塞链路

一个服务自己快，但上游卡住，它也会被拖慢——critical-chain 显示的就是这条最长依赖路径，每级时间是「该 unit 自身启动耗时」，不包含上游：

• 默认跑 systemd-analyze critical-chain，看是否落到 multi-user.target；图形界面用 systemd-analyze critical-chain graphical.target
• 如果链条末端是 NetworkManager-wait-online.service，且它自身 blame 耗时仅 0.2s，但链条里显示 +6.7s，说明它前面的依赖（如 network-pre.target）在等网络通，而实际网络压根没配好
• 某 service 显示 not found，代表它根本没加载——可能是被 systemctl mask、WantedBy= 写错，或 unit 文件语法错误（可用 systemd-analyze verify xxx.service 检查）

systemd-analyze plot 生成 SVG 时间线图

文字命令看不清并行/串行关系？这张图能一眼揪出问题：

• 必须重定向保存：systemd-analyze plot > boot.svg，然后用浏览器打开；终端直接执行只会刷一堆 XML
• 图中横向长条越长，该 unit 实际运行越久；前方大片空白，说明它在等上游；多个条并排，说明它们是并行启动的
• 若发现某个 .service 条块颜色异常（如黄色警告或红色失败），右键查看其属性可定位具体错误日志位置
• 报 Failed to get unit properties: Connection timed out，先运行 sudo systemctl restart systemd-journald 再试

真正容易被忽略的是：userspace 阶段里，blame 排名靠前的服务未必是根源，它可能只是“最后一个等的人”。关键得用 critical-chain 往上翻两层，看是谁在它前面卡住不动——比如 sshd.service 启动慢，往往不是 sshd 本身问题，而是它依赖的 systemd-tmpfiles-setup.service 因磁盘满或权限错卡死。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。