パフォーマンスの向上/ブートプロセス
関連記事
システムのブートパフォーマンスを向上させることは起動待機時間の短縮とシステムファイル・スクリプトが相互にどう作用しているのか知る方法を提供します。この記事では Arch Linux の起動時間を改善する方法を集めています。
目次
ブートプロセスを解析する
systemd-analyze を使う
systemd は systemd-analyze という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機しているユニットが表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見たい場合、以下のコマンドを実行してください:
$ systemd-analyze
起動するのにかかった時間でユニットファイルを並べて一覧するには:
$ systemd-analyze blame
特定のユニットがきちんと動かないために全体の起動時間が長くなっている場合があります。起動チェインの中でどのユニットが起動を遅くしているのか確認するには、次を実行してください:
$ systemd-analyze critical-chain
Bootchart のように、ブートプロセスを視覚的に表す SVG ファイルを生成することもできます:
$ systemd-analyze plot > plot.svg
詳細は man systemd-analyze を見て下さい。
systemd-bootchart を使う
2012年10月に Bootchart は systemd にマージされ、オリジナルの bootchart と同じように使って起動できるようになりました。カーネルラインに以下を追加してください:
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
ある程度データが収集できたらログの記録が停止して保存された情報からグラフが生成されます。システムの起動シーケンスに問題がある場合、使用されているリソース (デフォルトでは I/O, CPU の使用率とカーネルの init スレッド) など、グラフの中に手がかりとなる情報があるはずです。基本的には systemd-analyze の plot 機能よりも詳しい情報を閲覧することができます。
Bootchart のグラフはデフォルトでは /run/log に書き込まれ MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518 でジャーナルに保存されます。Journal の BOOTCHART= フィールドには SVG 形式のブートチャートを指定します。
詳しくは man ページ を見てください。
bootchart2 を使う
ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AUR の bootchart2-gitAUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:
# systemctl enable bootchart2
/var/log/bootchart.png を開くことで結果を視覚的に確認できます。もしくは以下のコマンドを実行してみてください:
$ pybootchartgui -i
bootchart の使い方など詳しい説明は bootchart2 のドキュメント を読んで下さい。
カスタムカーネルをコンパイルする
カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし最近は64ビットのアーキテクチャが一般的になっており、Linux カーネルはモジュール設計を取っているため、期待していたよりも効果がないかもしれません。詳しくはカーネル#コンパイルを見てください。
Initramfs
カスタムカーネルのコンパイルと同じように、initramfs もダイエットさせることができます。mkinitcpio の autodetect フックを使うのが一番簡単です。詳しくは initramfs の最小化を見てください。
サービスを早めに起動する
systemd の中心的な機能は D-Bus とソケットアクティベーションです。ソケットアクティベーションが使われている場合、最初にサービスにアクセスした時にサービスが起動します。大抵はそれで問題ありません。しかしながら、ブート中に必ず起動する (UPower のような) サービスがあるのであれば、そのサービスを出来る限り早めに起動することで起動時間を短縮できます。以下のようなコマンドを実行してサービスを有効化してください:
# systemctl enable upower
上記のコマンドによって systemd は UPower を出来る限り早く起動するようになり、ソケットや D-Bus による有効化は使われなくなります。
スタッガード・スピンアップ
一部のハードウェアにはスタッガード・スピンアップ (Staggered spin-up, SSS) が実装されています。SSS が実装されている HDD の場合、OS は ATA インターフェースを連続的に調べるようになり、段階を追ってドライブをスピンアップすることができるため最大電気使用量が減少します。ただしスタッガード・スピンアップは起動時間を遅くし、ほとんどのコンシューマ機では電源を入れたときに瞬時にドライブがスピンアップするので全く利益がありません。SSS が使われているかどうか確認するには:
$ dmesg | grep SSS
使われていない場合は、起動時に何も出力されないはずです。
無効にするには、kernel 行に libahci.ignore_sss=1 を追加してください。
ファイルシステムのマウント
mkinitcpio の fsck フックによって、時間のかかる root パーティションの再マウントを避けることができます。kernel 行の ro を rw に変更して /etc/fstab からパーティションを削除してください。マウントオプションは kernel 行で rootflags=mount options... と指定することで設定できます。/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 などの他のファイルシステムはカスタムマウントユニットでマウントできます。マウントオプションに noauto,x-systemd.automount を追加するとパーティションへの全てのアクセスをバッファし、最初にアクセスしたときに fsck とマウントを行うようになり、ブートプロセスで fsck とマウントをするファイルシステムの数を減らせます。
起動中の出力を減らす
システムによっては (特に SSD を使っている場合)、tty のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。サイレントブートを見てください。
RAM にサスペンド
起動時間を短縮する一番よい方法は起動しないことです。サスペンドを使用することを考慮してください。