### [VPS开机很慢怎么定位？用systemd-analyze区分内核、服务和依赖链](https://www.jiyueip.com/article/13831)

**Published:** 2026-08-01T02:59:49

**Author:** 斑斓

**Excerpt:** VPS开机很慢，不要按systemd-analyze blame排名直接禁用服务。本文把云平台启动、内核、用户…

VPS开机很慢，先定义“慢在什么位置”：控制台迟迟没有内核输出、系统已经启动但SSH不可用，还是SSH能登录而网站和容器仍未就绪。三种现象对应云平台、操作系统和业务服务的不同时间段，不能只看一个总启动秒数。

`systemd-analyze`可以拆分内核、initrd和用户空间耗时，并列出服务启动时间与关键依赖链。但`blame`只统计单元处于激活阶段的时间，排名靠前不等于它阻塞了整个启动过程，更不能据此直接禁用系统服务。

## 先建立一条可重复的开机时间线

每次测试至少记录四个时间点：在云平台执行启动或重启、控制台出现内核日志、SSH端口可连接、核心业务健康检查通过。如果第一段就很长，应先查看平台事件、宿主机维护和控制台状态；如果SSH之后业务才慢，再检查应用、容器和数据库。

| 时间段 | 常见表现 | 优先证据 |
| --- | --- | --- |
| 云平台到内核启动 | 控制台长期无输出 | 平台事件、实例状态、救援控制台 |
| 内核与initrd | 磁盘、文件系统或设备等待 | 启动控制台、内核日志、systemd-analyze time |
| systemd用户空间 | 网络、挂载或服务依赖等待 | blame、critical-chain、journalctl |
| 业务就绪 | SSH可用但网站或容器未恢复 | 服务日志、健康检查、依赖状态 |

## 第一轮只采集，不急着改配置

```
systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain
systemctl --failed
journalctl -b -p warning --no-pager
```

`time`给出内核、initrd和用户空间的总体耗时；`blame`按单元激活时长排序；`critical-chain`显示通向目标单元的时间关键依赖链；`systemctl --failed`和本次启动日志则补充失败、超时与重试信息。

如果需要完整时间图，可以生成SVG文件后在本地查看：

```
systemd-analyze plot > bootup.svg
```

图表和排名都只反映最近一次启动。云主机首次开机、软件更新后的首次重启和缓存已热的后续启动可能不同，因此应保留测试条件，不把一次结果写成长期规律。

## blame排名靠前，为什么未必是罪魁祸首

某个服务启动用了20秒，但如果它与其他任务并行运行，整机启动可能并没有因此多等20秒。真正需要关注的是：它是否出现在`critical-chain`中、后续关键目标是否必须等待它、日志中是否存在明确超时。

常见误判包括：

-   `network-online.target`等待网络就绪，但真正拖延的是底层网络服务或不可达网关；
-   云初始化服务在等待元数据、DNS或软件源，而不是服务本身计算慢；
-   远程挂载、失效磁盘UUID或不存在的设备让启动作业等待超时；
-   应用服务快速启动后内部仍在迁移数据库，systemd已经视为active；
-   失败服务反复重启，单次耗时不长，却持续占用资源并延后业务就绪。

## 沿关键链查看单元状态和本次启动日志

从`critical-chain`中选择真正影响目标的单元，再读取状态和本次启动日志。示例中的`example.service`必须替换为实际单元名：

```
systemctl status example.service --no-pager
journalctl -b -u example.service --no-pager
systemctl show example.service -p After -p Wants -p Requires
```

状态里若出现`start operation timed out`、设备不存在、挂载失败、名称解析失败或重复重启，应先修复直接原因。不要通过无限增加超时掩盖错误，也不要远程禁用SSH、网络、文件系统或云初始化相关单元。

systemd依赖的`After`只描述顺序，`Wants`和`Requires`描述拉起关系，三者不能互相替代。相关概念可继续查看[systemd服务依赖失败的三层排查方法](https://www.jiyueip.com/article/13352)。

## 几类高频等待点怎样确认

### 网络就绪等待

检查实际网络管理器、默认路由、DNS和云平台注入的网卡配置。不要为了缩短启动时间直接屏蔽`network-online.target`，因为远程挂载、数据库和业务服务可能确实依赖可用网络。

### 磁盘、fsck与挂载等待

核对`/etc/fstab`中的UUID、设备是否存在、文件系统状态和远程挂载目标。所有修改都应在云控制台或救援模式可用的前提下进行，并先保存原文件。

### 服务重启风暴

如果日志中反复出现启动失败与自动重试，先停止故障扩散，再查配置、权限、端口和依赖。可参考[systemd start-limit-hit与重启风暴排查](https://www.jiyueip.com/article/13284)。

### 云初始化和软件源

首次启动可能等待元数据、SSH密钥、DNS或软件包索引。应读取对应服务日志，确认任务是仍在执行、已失败还是等待外部网络，不要直接删除状态文件强制重跑。

## 修改后怎样证明启动真的变快

1.  **保存基线：**保留修改前的`time`、`critical-chain`和关键日志。
2.  **一次只改一项：**避免同时改网络、挂载和服务依赖后无法判断贡献。
3.  **保留控制台：**涉及启动链的修改必须准备带外登录和回滚文件。
4.  **重复验证：**在相近条件下记录多次启动，区分首次初始化与稳定状态。
5.  **检查业务：**SSH更早可用不等于数据库、容器和网站已经正常。

验收标准应同时包含系统启动、远程登录和业务健康，而不是只追求`systemd-analyze time`中的一个较小数字。

## 选择VPS时也要考虑恢复入口

启动链修改错误可能让远程SSH完全不可用，因此VPS是否提供网页控制台、救援模式、快照和网络规则管理，比单次开机数字更重要。极跃圈收录的[雨云云服务详情页](https://www.jiyueip.com/link/5617)记录的邀请码为`admin01`；实际控制台、快照、产品配置、优惠和使用限制以当前结算页面与服务条款为准。

生产服务器变更前应安排维护窗口和回滚方案。不要为了几秒启动时间关闭安全、存储或网络保障机制。

**Tags:** Linux服务器, Ubuntu服务器, VPS, VPS监控, 云服务器, 网络故障排查

**Categories:** 行业洞察

---