# 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ドライブの場合...より良いですが、残念ながら順次読み取りは内部ストレージほど高速ではありません。