当前位置：首页 > 文章列表 > 文章 > linux > Linux 开机慢怎么查：用启动分析工具看耗时、依赖链和网络等待

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

来源：17golang原创 2026-07-16 14:13:16 0浏览收藏

所属专题：Linux systemd 服务运维与启动故障排查专题 - 从 unit、journalctl 到启动慢、重启循环与 cgroup 资源边界

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

要点速览

启动分析工具的 time 子命令可以把慢启动的时间区间，直接拆成内核、initrd 和用户空间三个部分。
blame 适合把耗时异常的候选项快速筛出来，但并行启动的机制会让它的耗时排名，看起来比实际的阻塞影响大很多。
critical-chain 专门用来查指定目标单元的关键时间依赖路径，绝对不能只盯着列表第一行直接下判断。
网络等待、远程挂载和业务服务的依赖关系要挨个核对，不需要网络的本地服务，不该被这几类操作拖慢启动速度。

先确认慢在内核、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 做筛选，排查范围一下就能缩小很多。

Linux 启动从内核、initrd、用户空间到网络等待和多用户目标的调用链追踪图

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

 blame | head -n 15

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

看到的信号	先核对什么	不要立刻做的事
网络等待单元耗时长	是否真的有业务服务必须等网络完全可用才能启动	没理清所有远程挂载依赖前就强行关闭网络等待机制
某个业务服务耗时长	它是否真的位于整个启动链路的关键依赖路径上	只靠耗时排名就认定它是拖慢全机的根因
设备或挂载项耗时长	磁盘识别状态、UUID配置、远端资源连通性和对应的失败日志	直接把等待超时参数调得极短绕过检查
每次重启耗时波动很大	网络连通性、DNS解析状态、远端依赖可用性和日志时间线	把一次偶发的慢启动结果当成固定配置问题处理

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

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

 critical-chain
 critical-chain multi-user.target

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

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

Linux 启动排查中从耗时候选清单到 critical-chain 关键依赖路径的证据对比图

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

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

 status 
journalctl -b -u  --no-pager

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

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

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

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

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

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

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