Linux 开机慢怎么查：用启动分析工具看耗时、依赖链和网络等待

一台 Linux 服务器重启后半天起不来业务，登进系统跑启动分析工具的 blame 子命令，排在最前面的刚好是个占了30秒的服务。不少人第一反应就是直接把这个服务禁用，觉得删掉启动速度立马就上来了。先别急，系统的服务管理器是并行拉起大量单元的，单个服务耗时高，不等于它真的挡住了整条启动路径。真正要排查的核心是：哪条依赖链拖慢了你要的启动目标，还有那段等待操作是不是真的对当前业务有必要。

先确认慢在内核、initrd，还是用户空间

排查第一条要跑的命令很短：

 time

它会把整机总启动时间拆成内核、initrd 和用户空间三块，同时显示主启动目标状态的耗时。这个分段判断非常关键：如果耗时大头出在 initrd 阶段，你盯着上层服务配置改半天根本不会有任何效果；只有用户空间耗时明显偏高的时候，才值得继续往下深挖各个单元之间的依赖关系。官方手册也写得很清楚，这个统计的时间点只代表目标单元已经被拉起，不代表所有服务都完成了全量初始化，更不能直接把这个时间当成磁盘资源完全空闲的时刻。

下面是一段示意输出：

Startup finished in 1.8s (kernel) + 4.2s (initrd) + 28.6s (userspace)
multi-user.target reached after 28.4s in userspace

看这个输出就能直接确定优化方向放在用户空间的服务配置上就行，没必要反复去调内核相关参数。之后再拿 blame 做筛选，排查范围一下就能缩小很多。

blame 是候选清单，不是“谁拖慢系统”的判决书

 blame | head -n 15

这条命令会按照各个单元从启动到进入就绪状态的总耗时排序。靠它你可以把几十上百个启动单元快速收敛成几个重点排查对象，但别看到排名第一的单元就直接禁用。举个例子：两个完全独立的服务并行启动，一个花了25秒，另一个花了20秒，整机新增的等待时长根本不会累加变成45秒。还有不少看起来耗时高的服务，实际只是在等前置的设备、网络或者挂载条件满足而已，自身并没有拖慢流程。

这里的判断逻辑和高并发服务排查全链路耗时的思路完全一致：先收集候选观测点，再顺着链路一步步溯源找根因。blame 给出的只是排查入口，不是最终的因果结论。

用 critical-chain 找到真正挡路的依赖

 critical-chain
 critical-chain multi-user.target

critical-chain 会以树状结构展示整条关键时间依赖路径。输出里 @ 后面标注的时间，是单元启动或者切换为active状态的相对时刻，+ 后面标注的时间，是这个单元自身启动阶段消耗的总时长。把它和 blame 的结果对照着看，就能区分开“看起来耗时久但全程并行运行”的服务，和“后续所有目标单元都在等它执行完”的阻塞节点。

假设排查得到的依赖链路上出现网络已就绪目标、网络等待单元和某个远程挂载单元，这时候要继续核对：业务服务是不是真的必须等网络完全就绪才能启动？远程挂载是不是必须阻塞默认的启动目标？不同业务场景的判断标准完全不一样，先理清楚所有依赖关系和业务启动的前置要求，再动手改配置。

网络等待与远程依赖，先看日志再决定取舍

网络相关的慢启动场景，问题基本都不是网卡本身性能不够，而是某个启动单元在等地址分配、路由生成、DNS 解析或者远端资源返回。先针对你怀疑的候选单元，查看状态和本次启动的运行日志：

 status 
journalctl -b -u  --no-pager

不同发行版的网络管理组件和候选单元名称会有区别，别直接把示例名称当成通用配置，按照本机手册把尖括号替换成对应工具和单元就行。日志里如果明确出现等待 DHCP 分配地址、链路未就绪或者远端地址不可达的记录，就回到网络配置、虚拟机网卡状态、DNS 解析规则或者挂载配置本身排查问题。单纯缩短等待超时时间，只会让启动流程更快报错，不会让对应的远端依赖突然变成可用状态。

更稳妥的架构是做分层处理：不需要网络的本地服务优先启动，确实需要访问远程数据库、NFS存储、对象存储或者授权端点的服务，再单独声明自己需要的网络就绪条件。这样局部网络抖动不会把所有服务都绑在同一条等待链路上，启动速度和故障边界也更容易梳理清楚。

每次调整后，用同一组证据验证结果

改完依赖规则、网络配置或者挂载策略之后，重启系统重复采集三类观测数据：用 time 看总耗时的分段变化，用 blame 看耗时候选项有没有更新，用 critical-chain 看关键依赖链的总长度是不是已经缩短。只看单个命令返回的时间变小不算优化到位，比如总启动时间变短了，但业务服务在远程依赖准备好之前就启动导致报错，本质上只是把启动等待转移成了后续的业务异常。

建议给核心业务服务补充就绪检查逻辑：确认监听端口、业务进程或者健康检查接口，在系统默认启动目标完成之后确实能正常响应。启动优化的目标不是拿到一个更小的秒数，而是让业务从开机到完全可用的时间更短，同时故障边界更清晰可查。

相关问题

blame 排名第一的单元就是导致开机慢的服务吗？

不一定。服务管理器会并行启动多个单元，耗时排行只能说明这个单元自身的启动消耗久，它会不会阻塞整个目标状态，还要结合 critical-chain 输出的完整依赖链做判断。

看到network-online.target耗时很长，能直接关掉对应的等待服务吗？

先确认系统里有没有远程挂载、远程数据库连接、启动阶段拉取配置或者其他必须等网络就绪的业务逻辑。没理清全部依赖就直接关闭等待，很容易把启动慢的问题转成启动完成后的业务故障。

为什么启动分析工具显示的总耗时变小了，业务服务还是不可用？

这个统计只覆盖主启动阶段耗时，不能代替业务侧的就绪检查。遇到这类问题要继续排查目标服务的运行状态、启动日志和实际的健康检查结果。

可以只针对某一个指定的目标单元做依赖分析吗？

可以。给启动分析工具的 critical-chain 子命令传入要排查的目标单元名称，就能把分析范围收窄到这个单元对应的关键时间依赖链上。

把启动耗时当成一条可以拆开的链

开机慢的时候，最容易踩的坑就是看到一个长耗时项就随手删掉对应的服务。先拆分启动阶段，再从 blame 的输出里筛选排查候选，用 critical-chain 验证实际的阻塞关系，最后回到网络、挂载和业务就绪条件层面做取舍。按照这套逻辑调整完一次之后，后续再遇到系统镜像、网络环境或者依赖关系变更的场景，你依然能用同一套排查方法把问题定位到具体单元和具体前置条件上。