☰

为什么启动需要这么长时间？

tag-icon • tag-icon fedora boot systemd io
为什么启动需要这么长时间？ 
# systemd-analyze blame
       40.256s firewalld.service
       38.154s initial-setup-graphical.service
       26.161s dev-mapper-VolGroup\x2dlv_root.device
       24.262s abrtd.service
       24.118s systemd-udev-settle.service
       20.907s systemd-journal-flush.service
       17.716s accounts-daemon.service
       16.398s libvirtd.service
       11.097s systemd-udevd.service
       10.533s systemd-journald.service
       10.389s systemd-sysctl.service
       10.266s dnf-makecache.service
        4.412s polkit.service
        4.404s jexec.service
        3.767s lvm2-monitor.service
        3.439s chronyd.service
        3.300s systemd-logind.service
        3.157s livesys.service
        3.155s akmods-shutdown.service
        3.144s akmods.service
        3.143s gssproxy.service
        2.889s rpcbind.service

除此之外，每个 IO 都需要永远完成？我如何追踪这个？

答案1

使用引导图确认 IO 是启动过程中的限制因素。 我预计该图基本上始终显示 100% IO，只有短暂的突发情况才充分利用 CPU。

GNOME 磁盘中提供了快速性能测试。您应该期望“旋转铁锈”显示的速度略高于 100MB/s，每次搜索 10 毫秒。

我认为对于传统机械存储来说，计时规模是合理的。 Firewalld 的特性看起来很熟悉。我的基于磁盘的系统需要60岁以上90 秒（！）。 systemd-analyze blame不过看起来没那么糟糕。

上游（和 Fedora）开发人员倾向于购买优质的非机械存储。启动程序时的性能是众所周知的好处:-)。

systemd-readahead没有得到维护并最终被删除。该服务按顺序预读取启动所需的文件，以避免按需（和不按顺序）读取页面。也就是说，它减少了缓慢的机械操作的数量。

我很好奇 Ubuntu 的故事是什么。 Ubuntu 采用 systemd 后，我想他们有足够的资源来注意到一个大的回归。

我刚刚注意到livesys.service 如果您从 CD 或 DVD 启动，您可能会遇到糟糕的启动性能。对于基本的 USB 驱动器……更好，但不幸的是顺序读取速度不如内部存储。

答案2

您可能已经在“IO 需要永远完成”中提供了自己的答案。您的启动卷硬件的性能可能有问题。如果您的 I/O 非常慢，那么您可能无法采取任何措施来在软件方面产生显着的变化。

相关内容