☰

始めるにはなぜこれほど長い時間がかかりますか？

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ディスクで高速パフォーマンステストが可能です。 Spinning Rust は、検索ごとに 10 ミリ秒で、100 MB/s が少し以上の速度を示すと予想する必要があります。

私は伝統的な機械的保存においてタイミングスケールが合理的だと思います。 Firewalldの機能はおなじみのようです。私のディスクベースのシステムでは60歳以上90秒（！）。 systemd-analyze blameしかし、それほど悪くはないようです。

アップストリーム（およびFedora）開発者は、優れた非機械的ストレージを購入する傾向があります。プログラムを起動するときのパフォーマンスはよく知られている利点です:-).

systemd-readahead維持されず、最終的に削除されました。サービスは、要求時に（および非順次）ページの読み取りを防ぐために、開始に必要なファイルを順次事前に読み取ります。つまり、スローマシンの動作回数を減らします。

Ubuntuの話が何なのか気になります。 Ubuntuがsystemdを採用すると、大きな退職に気づくのに十分なリソースがあると思います。

私は気づいたばかりです。livesys.service CDまたはDVDから起動すると、起動パフォーマンスが低下する可能性があります。。ネイティブUSBドライブの場合...より良いですが、残念ながら順次読み取りは内部ストレージほど高速ではありません。

おすすめ記事