「パフォーマンスの向上/ブートプロセス」の版間の差分
(TranslationStatus) |
細 (AshMyzk がページ「ブートパフォーマンスの向上」を「パフォーマンスの向上/ブートプロセス」に移動しました: 英語版と同じに) |
(相違点なし)
| |
2023年5月30日 (火) 06:07時点における版
関連記事
システムのブートパフォーマンスを向上させることで、起動待機時間を短縮し、特定のシステムファイルとスクリプトが相互にどう作用しているのかをより良く知ることができます。この記事では Arch Linux システムのブートパフォーマンスを向上させる方法を集めています。
目次
ブートプロセスを解析する
systemd-analyze を使う
systemd は systemd-analyze という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のグラフを出力してユニットの依存関係を把握することができます。どのユニットファイルが起動時間を遅くしているのかが一目でわかり、それに応じてシステムを最適化することが可能です。
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見たい場合、以下のコマンドを実行してください:
$ systemd-analyze
起動するのにかかった時間でユニットファイルを並べて一覧するには:
$ systemd-analyze blame
特定のユニットがきちんと動かないために全体の起動時間が長くなっている場合があります。起動チェインの中でどのユニットが起動を遅くしているのか確認するには、次を実行してください:
$ systemd-analyze critical-chain
Bootchart のように、ブートプロセスを視覚的に表す SVG ファイルを生成することもできます:
$ systemd-analyze plot > plot.svg
詳細は systemd-analyze(1) を見て下さい。
bootchart2 を使う
Bootchart2 を使うことでも、ブートシーケンスを視覚化することができます。
起動時に busybox の代わりに systemd を使用する
デフォルトでは、Mkinitcpio の設定は initramfs の構築に base と udev フックを使用します。これらを systemd に置き換えることで、より高速なブートタイムを実現することができます。
詳しくは mkinitcpio#通常のフック を見て下さい。fsck フックを置き換える場合は Fsck#ブート時のチェック も見て下さい。
カスタムカーネルをコンパイルする
カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし最近は64ビットのアーキテクチャが一般的になっており、Linux カーネルはモジュール設計を取っているため、期待していたよりも効果がないかもしれません。詳しくはカーネル#コンパイルを見てください。
Initramfs
カスタムカーネルのコンパイルと同じように、initramfs もダイエットさせることができます。mkinitcpio の autodetect フックを使うのが一番簡単です。詳しくは initramfs の最小化を見てください。
ハードウェア (プロセッサとストレージの速度) にもよりますが、デフォルトの zstd 圧縮オプションの代わりに lz4 を使うと、起動時の解凍速度が速くなり、ディスクから読み込む initramfs のサイズが若干大きくなりますが、通常相殺されるため速くなることがあります。mkinitcpio#COMPRESSION を見て下さい。
サービスの適切な起動方法を選択する
systemd の中心的な機能のひとつに D-Bus とソケットのアクティベーションがあります。この機能はほとんどの場合、サービスが最初にアクセスされたときにだけ起動され、一般的に良いことなので好まれるはずです（例えば、起動時に cups.service を有効にすることは通常デスクトップでは有用ではありません、なぜなら cups.socket だけ有効にすると、実際に印刷するときだけサービスを起動することになるからです。）
しかし、あるサービス (upower など) が起動時に常に開始されることがわかっている場合、できるだけ早く開始することで全体の起動時間を短縮できる可能性があります。これは(サービスファイルがそのように設定されている場合、ほとんどの場合)、upower.service を 有効化 することで実現できます。
これにより、systemd はソケットや D-Bus のアクティベーションで競合することなく、できるだけ早く UPower を起動します。
スタッガード・スピンアップ
一部のハードウェアにはスタッガード・スピンアップ (Staggered spin-up, SSS) が実装されています。SSS が実装されている HDD の場合、OS は ATA インターフェースを連続的に調べるようになり、段階を追ってドライブをスピンアップすることができるため最大電気使用量が減少します。ただしスタッガード・スピンアップは起動時間を遅くし、ほとんどのコンシューマ機では電源を入れたときに瞬時にドライブがスピンアップするので全く利益がありません。SSS が使われているかどうか確認するには:
$ dmesg | grep SSS
使われていない場合は、起動時に何も出力されないはずです。
無効にするには、カーネルパラメータに libahci.ignore_sss=1 を追加してください。
ファイルシステムのマウント
mkinitcpio の fsck フックによって、カーネルラインの ro を rw に変更することで、時間のかかる root パーティションの再マウントを避けることができます。マウントオプションはカーネルラインで rootflags=rw,他のマウントオプション と指定することで設定できます。/etc/fstab からルートパーティションのエントリは必ず削除してください、そうしないと systemd-remount-fs.service が fstab の設定を適用し続けます。もしくは、ユニットをマスクしてもよいです。
btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、mkinitcpio の fsck フックは削除してかまいません。systemd-fsck-root.service をマスクしたり、カーネルコマンドラインで fsck.mode=skip を使うことで root ファイルシステムの fsck をしないようにできます。mkinitcpio の fsck フックがなくても、systemd は systemd-fsck@.service を使って適切なファイルシステムを全て fsck します。
また、/etc/fstab から API ファイルシステムを削除することもできます。systemd 自身がそれらをマウントするからです (pacman -Ql systemd | grep '\.mount$' でそのリストを見れます)。sysvinit から /tmp エントリを持ち越しているユーザーには聞き慣れないかもしれませんが、上のコマンドによって systemd がそれらを管理していることに気づくはずです。従って、エントリは削除しても問題ありません。
/home や EFI システムパーティション などの他のファイルシステムはカスタムマウントユニットでマウントできます。マウントオプションに noauto,x-systemd.automount を追加するとパーティションへの全てのアクセスをバッファし、最初にアクセスしたときに fsck とマウントを行うようになり、ブートプロセスで fsck とマウントをするファイルシステムの数を減らせます。
起動中の出力を減らす
システムによっては (特に SSD を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。サイレントブートの記事を見てください。
ブートローダーの変更
ブートローダーを (例: systemd-boot などのよりシンプルなブートローダーに) 変更することで、起動時間を秒単位で減らせるかもしれません。
あなたのセットアップで可能なのであれば、EFISTUB だけを使えば更に起動時間を短縮できます。
RAM にサスペンド
起動時間を短縮する一番よい方法は起動しないことです。サスペンドを使用することを考慮してください。