优化 systemd 启动慢需定位阻塞点、减少依赖等待、避免同步 I/O 或网络等待，并调整启动策略；通过 critical-chain、journalctl 查依赖与日志，精简服务依赖，禁用或异步化高耗时服务（如 NetworkManager-wait-online、lvm2-monitor、docker），启用并行设备发现和精简 initramfs 等加速特性。
服务启动慢，systemd-analyze blame 显示前几名耗时长，说明这些单元在初始化阶段存在明显瓶颈。优化核心是定位阻塞点、减少依赖等待、避免同步 I/O 或网络等待，并合理调整启动策略。
查清真实耗时原因，别只看排序
blame 列出的是“从启动到进入 active 状态”的总耗时，但不等于该服务自身执行慢——可能是它等待的依赖没就绪，或是它自己卡在某个同步操作上（比如 DNS 解析、磁盘挂载、证书生成）。建议：
- 对排前三的服务逐个运行
systemd-analyze critical-chain，看它的依赖链中哪一环拖得最久 - 用
journalctl -u查日志，重点关注 startup 阶段的 warning 或 timeout 提示--since "1 hour ago" - 检查是否启用了
WantedBy=multi-user.target却实际只在图形环境才需要（如某些 GUI 工具服务），造成无谓等待
常见高耗时服务的典型优化方式
以下几类服务在 blame 中高频出现，处理思路较明确：
-
NetworkManager-wait-online.service：默认要求所有网络接口“上线”才继续，但 DHCP 或无线连接可能卡住。可禁用等待：
sudo systemctl disable NetworkManager-wait-online.service，或改用异步启动（在/etc/systemd/system/NetworkManager.service.d/wait.conf中加[Service] ExecStartPost=/bin/sh -c 'sleep 1'并设After=network.target） -
lvm2-monitor.service / dev-mapper-*.device：LVM 扫描或加密卷解锁慢，常因磁盘响应差或密钥获取延迟。确认是否真需开机自动激活所有 LV；可禁用非必要 LV 的 autoactivation，或使用
lvchange --autoactivation y按需启用 -
docker.service / containerd.service：镜像扫描、graph driver 初始化、或 overlayfs 检查可能耗时。升级到较新版本（v24+ 对启动有明显优化），并检查
/var/lib/docker所在分区是否 I/O 延迟高；也可考虑设置StartLimitIntervalSec=0避免失败重试拉长感知时间
精简依赖与启动顺序
很多服务声明了过度宽泛的 After= 或 Wants=，导致 systemd 被迫串行等待。可安全调整：
- 用
systemctl show查当前依赖关系| grep -E "(After|Before|Wants|WantedBy)" - 若某服务实际不依赖网络（如本地缓存服务），移除
After=network-online.target，改用After=network.target或直接去掉 - 对非关键服务（如日志归档、监控探针），添加
WantedBy=multi-user.target改为WantedBy=timers.target或延迟启动（配合ExecStartPre=/bin/sleep 5）
启用并验证 systemd 启动加速特性
现代 systemd 提供多个内置优化项，开启后对整体启动时间有可观改善：
- 启用并行设备发现：
sudo systemctl enable systemd-udev-settle.service（旧版）或确保udev规则已优化；新版推荐检查/etc/default/grub中是否含rd.udev.log_priority=3减少日志开销 - 关闭不必要的 initramfs 功能：如果不用 LUKS 或 RAID，可在
/etc/mkinitcpio.conf（Arch）或/etc/dracut.conf.d/（RHEL）中移除encrypt、lvm等模块，缩短 initramfs 加载和解压时间 - 启用
systemd.analyze log-level=warning启动参数（加到 GRUB_CMDLINE_LINUX），让内核和 systemd 在启动期少打 debug 日志，尤其对慢速存储有效
