温馨提示×

ubuntu进程启动慢怎么解决

小樊
45
2025-12-08 05:18:39
栏目: 智能运维

Ubuntu 进程启动慢的定位与优化

一、快速定位瓶颈

  • 使用 systemd 提供的分析工具查看整体与关键路径耗时:
    • 整体时间:systemd-analyze time
    • 各单元耗时:systemd-analyze blame
    • 关键链:systemd-analyze critical-chain
    • 生成图形报告:systemd-analyze plot > ~/boot.svg(用浏览器打开查看)
  • 查看本次启动的高优先级错误:journalctl -b -p 3
  • 若怀疑磁盘或文件系统问题,检查磁盘健康:sudo smartctl -a /dev/sda
  • 若主要是图形登录后“卡住很久才可用”,优先关注 plymouth-quit-wait.serviceNetworkManager-wait-online.serviceapt-daily.service 等服务的耗时。

二、常见高耗时项与对应处理

症状或命令输出中的高耗时项 可能原因 建议操作
plymouth-quit-wait.service 长时间等待 等待图形会话结束、开机动画未退出 仅屏蔽等待:sudo systemctl mask plymouth-quit-wait.service(需要恢复时用 unmask
NetworkManager-wait-online.service 长时间等待 等待所有网络“上线”才继续 非服务器场景可禁用:sudo systemctl disable NetworkManager-wait-online.service
apt-daily.service 在开机阶段运行 系统维护任务与启动并行,占用 I/O 延迟到开机后:sudo systemctl edit apt-daily.timer,写入:[Timer] OnBootSec=15min; OnUnitActiveSec=1d; RandomizedDelaySec=30min
systemd-journal-flush.service 耗时 日志写入量大、同步频繁 编辑 /etc/systemd/journald.confSystemMaxFileSize=1GSystemMaxFiles=5,然后重启或 sudo systemctl restart systemd-journald
dev-loop*.device 多个循环设备耗时 大量 Snap 包挂载导致 精简不必要的 Snap 包,或暂时移除重度使用的 Snap 后再测
snapd.service 耗时 Snap 守护进程初始化慢 同上,减少/替换 Snap,或按需延后启动
fwupd.service 耗时 固件更新检查 非必要可禁用:sudo systemctl disable --now fwupd.service
docker.servicecontainerd.service 耗时 容器服务随开机启动 若非必需:sudo systemctl disable --now docker.service
bluetooth.servicecups.serviceModemManager.service 耗时 未使用的硬件相关服务 不需要则禁用:sudo systemctl disable --now bluetooth.service cups.service ModemManager.service
systemd-fsck-root.servicefsck 阶段慢 文件系统检查频繁或磁盘慢 非 SSD 或空间紧张时可减少检查频率(编辑 /etc/fstab 的 pass 字段),或使用 fsck.mode=skip(谨慎,仅用于已知良好磁盘)
accounts-daemon.service 耗时 用户会话预加载 轻量需求可禁用:sudo systemctl disable --now accounts-daemon.service
networkd-dispatcher.service 耗时 使用 NetworkManager 时多余 使用 NM 时可禁用:sudo systemctl disable --now networkd-dispatcher.service
dev-sdaX.device 等待设备 磁盘/分区响应慢或不存在 检查磁盘健康与分区表,确认 /etc/fstab 中设备是否存在、UUID 是否正确
man-db.servicelogrotate.service 耗时 例行维护任务 可延后执行或按需执行,避免与开机竞争 I/O
以上条目均来自实际案例与常用优化手段,执行前请结合 systemd-analyze blame 的结果,逐项验证后再改动。

三、配置与系统层面的优化

  • GRUB 启动优化
    • 缩短菜单等待:sudo nano /etc/default/grub,设置 GRUB_TIMEOUT=2,然后 sudo update-grub
    • 减少内核日志输出:GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3"(必要时再加 noresumefsck.mode=skip,谨慎使用)
  • 文件系统与磁盘
    • 使用 noatimerelatime 减少写入:/etc/fstab 挂载选项添加 noatime,discard
    • 启用 SSD TRIM:sudo systemctl enable fstrim.timer
  • 日志与临时文件
    • 限制日志占用:sudo journalctl --vacuum-size 100M
  • 启动项管理
    • 图形界面启动项:gnome-session-properties(移除不必要自启)
    • 旧内核清理:sudo apt autoremove --purge
  • 显示管理器与桌面环境
    • 更轻量的显示管理器:sudo apt install lightdm && sudo dpkg-reconfigure lightdm
    • 资源紧张可考虑 Xfce/LXQt 等轻量桌面
  • 预加载常用程序(可选)
    • sudo apt install preload,让系统学习常用应用以加速后续启动

四、验证与回退

  • 每次调整后重启,并用 systemd-analyze timesystemd-analyze blamesystemd-analyze critical-chain 复核效果;必要时用 systemd-analyze plot 生成对比图。
  • 谨慎操作提示
    • mask 会彻底阻止服务启动,改动前记录命令,便于 unmask 恢复
    • fsck.mode=skipdisable 关键服务可能影响数据安全或网络可用性,务必在非生产环境验证并保留回退方案
    • 若发现 swap 分区或 UUID 异常(如扩容后),核对并修正 /etc/fstab,否则会导致启动挂起或极慢。

0