web-dev-qa-db-ja.com

なぜ起動に時間がかかるのですか？

# 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は完了するのに永遠のようにかかりますか？これを追跡するにはどうすればよいですか？

fedorabootsystemdio
5
ayhid

bootchart を使用して、IOがブートプロセスの制限要因であることを確認します。Iグラフは基本的に100％IO全体を示し、CPUが完全に使用されている場合は短いバーストのみを示します。

クイックパフォーマンステストはGNOMEDisksで利用できます。 「回転する錆」は100MB /秒より少し良く、シークあたり10msを示すと期待する必要があります。

タイミングの規模は、従来の機械的保管にはもっともらしいと思います。 ファイアウォールの特性はおなじみのようです。私のディスクベースのシステムは 60歳以上 90秒（！）。 systemd-analyze blameしかしそれほど悪くは見えません。

上流（およびFedora）の開発者は、Niceの非機械的ストレージを購入する傾向があります。プログラムを開始する際のパフォーマンスはよく知られている利点です:-)。

systemd-readaheadは維持されず、最終的に削除されました。これは、オンデマンドで（および順序が狂って）ページを読み取らないようにするために、起動に必要なファイルを順番に先読みするサービスでした。つまりそれは遅い、機械的な操作の数を減らしました。

Ubuntuの話がどういうものか知りたいです。 Ubuntuがsystemdを採用した後、大きなリグレッションに気付くのに十分なリソースがあったと思います。

さっき気付いた livesys.serviceCDまたはDVDから起動する場合、ひどい起動パフォーマンスが期待できます。基本的なUSBドライブの場合...それは優れていますが、残念ながら、シーケンシャル読み取りは内部ストレージほど高速ではありません。

4
sourcejedi

あなたはおそらく「IOは完了するのに永遠のようにかかる」であなた自身の答えを提供したでしょう。障害があるのは、ブートボリュームハードウェアのパフォーマンスである可能性があります。 I/Oが非常に遅い場合、ソフトウェア側で劇的な違いを生むためにできることはほとんどありません。

1
Mark Stosberg