「パフォーマンスの向上/ブートプロセス」の版間の差分

2017年1月18日 (水) 20:45時点における版

システムのブートパフォーマンスを向上させることは起動待機時間の短縮とシステムファイル・スクリプトが相互にどう作用しているのか知る方法を提供します。この記事では Arch Linux の起動時間を改善する方法を集めています。

ブートプロセスを解析する

systemd-analyze を使う

systemd は systemd-analyze という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機しているユニットが表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。

起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見たい場合、以下のコマンドを実行してください:

$ systemd-analyze

ヒント: UEFI でブートしていて、かつ systemd の Boot Loader Interface を実装しているブートローダ (今のところ systemd-boot と GRUB のみ) を使っている場合、systemd-analyze は EFI ファームウェアとブートローダでかかった時間も追加で表示します。

起動するのにかかった時間でユニットファイルを並べて一覧するには:

$ 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-git^AUR パッケージにはドキュメント化されてない 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 とマウントをするファイルシステムの数を減らせます。

ノート:

上記の設定を使うと /home ファイルシステムが autofs タイプになり、デフォルトで mlocate によって無視されるようになります。システムによっては /home の自動化による高速化は数秒の効果しかない場合もあります。
Btrfs サブボリュームにシステムをインストールしていて (ルートディレクトリ / 自体がサブボリュームの場合)、/home を分割して使っている場合、/home サブボリュームの作成をしないように設定したほうが良いでしょう。home.conf の tmpfile をマスクしてください: ln -s /dev/null /etc/tmpfiles.d/home.conf。

起動中の出力を減らす

システムによっては (特に SSD を使っている場合)、tty のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。サイレントブートを見てください。

RAM にサスペンド

起動時間を短縮する一番よい方法は起動しないことです。サスペンドを使用することを考慮してください。

@@ 2行目: / 2行目: @@
 [[ar:Improve boot performance]]
 [[cs:Improve boot performance]]
-[[en:Improve boot performance]]
+[[en:Improving performance/Boot process]]
 [[es:Improve boot performance]]
 [[it:Improve boot performance]]
 [[ru:Improve boot performance]]
-[[zh-CN:Improve boot performance]]
+[[zh-hans:Improve boot performance]]
 {{Related articles start}}
 {{Related|パフォーマンスの最大化}}
@@ 22行目: / 22行目: @@
 [[systemd]] は {{ic|systemd-analyze}} という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機しているユニットが表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
-起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るには、次を実行するだけです:
+起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見たい場合、以下のコマンドを実行してください:
  $ systemd-analyze
-{{Tip|[[Unified Extensible Firmware Interface|UEFI]] でブートしていて、かつ systemd の [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[Gummiboot]] のみ) を使っている場合、''systemd-analyze'' は EFI ファームウェアとブートローダでかかった時間も追加で表示します。}}
+{{Tip|[[Unified Extensible Firmware Interface|UEFI]] でブートしていて、かつ systemd の [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[systemd-boot]] と [[GRUB]] のみ) を使っている場合、''systemd-analyze'' は EFI ファームウェアとブートローダでかかった時間も追加で表示します。}}
-ユニットファイルを起動するのにかかった時間で並べて一覧するには:
+起動するのにかかった時間でユニットファイルを並べて一覧するには:
  $ systemd-analyze blame
-ブートプロセスのある時点で、指定されたユニットがきちんと動かずに次に進めなくなることがあります。スタートアップの繋がりの中でどのユニットがこのクリティカルな状態になっているか見るには、次を実行してください:
+特定のユニットがきちんと動かないために全体の起動時間が長くなっている場合があります。起動チェインの中でどのユニットが起動を遅くしているのか確認するには、次を実行してください:
  $ systemd-analyze critical-chain
@@ 44行目: / 44行目: @@
 === systemd-bootchart を使う ===
-年10月に Bootchart は [[systemd|systemd]] にマージされ、オリジナルの bootchart と同じように使って起動できるようになりました。カーネルラインに以下を追加してください:
+年10月に Bootchart は [[systemd]] にマージされ、オリジナルの bootchart と同じように使って起動できるようになりました。カーネルラインに以下を追加してください:
  initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
+ある程度データが収集できたらログの記録が停止して保存された情報からグラフが生成されます。システムの起動シーケンスに問題がある場合、使用されているリソース (デフォルトでは I/O, CPU の使用率とカーネルの init スレッド) など、グラフの中に手がかりとなる情報があるはずです。基本的には systemd-analyze の plot 機能よりも詳しい情報を閲覧することができます。
-詳しくは [http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html manpage] を見て下さい。
+Bootchart のグラフはデフォルトでは {{ic|/run/log}} に書き込まれ {{ic|1=MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518}} でジャーナルに保存されます。Journal の {{ic|1=BOOTCHART=}} フィールドには SVG 形式のブートチャートを指定します。
+詳しくは [http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html man ページ] を見てください。
 === bootchart2 を使う ===
@@ 54行目: / 58行目: @@
 ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、[[Arch User Repository|AUR]] の {{AUR|bootchart2-git}} パッケージにはドキュメント化されてない [[systemd]] サービスが付いています。bootchart2 をインストールした後に次を実行してください:
- # systemctl enable bootchart
+ # systemctl enable bootchart2
+{{ic|/var/log/bootchart.png}} を開くことで結果を視覚的に確認できます。もしくは以下のコマンドを実行してみてください:
-bootchart の使い方など詳しい説明は [https://github.com/mmeeks/bootchart bootchart2 documentation] を読んで下さい。
+ $ pybootchartgui -i
-== Readahead ==
+bootchart の使い方など詳しい説明は [https://github.com/mmeeks/bootchart bootchart2 のドキュメント] を読んで下さい。
-[[systemd]] にはバージョン 216 から readahead の実装が付属しており、起動時間を短縮することができます。2つのサービスが存在します: {{ic|systemd-readahead-collect}} は起動時に使用されるファイルの情報を収集して、{{ic|systemd-readahead-replay}} はそれらのファイルをブートプロセスの初期段階でキャッシュに移動します。
+== カスタムカーネルをコンパイルする ==
-systemd の readahead を有効にするには [[AUR]] から {{AUR|systemd-readahead}} パッケージをインストールして次を実行してください:
+カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし最近は64ビットのアーキテクチャが一般的になっており、Linux カーネルはモジュール設計を取っているため、期待していたよりも効果がないかもしれません。詳しくは[[カーネル#コンパイル]]を見てください。
- # systemctl enable systemd-readahead-collect systemd-readahead-replay
+== Initramfs ==
-{{Note|
-* systemd-readahead-collect が情報を収集して systemd-readahead-replay が効果的に動作するようになるまで何回か再起動する必要があります。
-* カーネルのバージョンやハードドライブのタイプによって効果は変わってきます (例えば、SSD を使っている場合、全く効果がなかったり、むしろ起動時間が増えてしまうことすらありえます)。
-}}
+[[#カスタムカーネルをコンパイルする|カスタムカーネルのコンパイル]]と同じように、initramfs もダイエットさせることができます。[[mkinitcpio]] の {{ic|autodetect}} フックを使うのが一番簡単です。詳しくは [[initramfs の最小化]]を見てください。
-== カスタムカーネルをコンパイルする ==
-カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし 64bit アーキテクチャの標準化や Linux カーネルのモジュラー性のため、期待していたよりも効果がないかもしれません。[[カーネル#コンパイル|カーネルのコンパイルについてよく読んで下さい]]。
 == サービスを早めに起動する ==
-systemd の中心的な機能は [[D-Bus]] とソケットのアクティベーションです。そのため、最初にそれらにアクセスした時にサービスが起動するようになっており、大抵はそれで問題ありません。しかしながら、ブート中にいつも起動する ([[UPower]] のような) サービスを知っているのならば、そのサービスを出来る限り初めに起動することで起動時間を短縮できます。これを行うには (サービスファイルが用意されている場合。ほとんどの場合そうですが) 次を実行してください:
+systemd の中心的な機能は [[D-Bus]] とソケットアクティベーションです。ソケットアクティベーションが使われている場合、最初にサービスにアクセスした時にサービスが起動します。大抵はそれで問題ありません。しかしながら、ブート中に必ず起動する ([[UPower]] のような) サービスがあるのであれば、そのサービスを出来る限り早めに起動することで起動時間を短縮できます。以下のようなコマンドを実行してサービスを有効化してください:
  # systemctl enable upower
-このコマンドによって systemd は UPower を出来る限り早く起動するようになり、ソケットや D-Bus の有効化と競わなくなります。
+上記のコマンドによって systemd は UPower を出来る限り早く起動するようになり、ソケットや D-Bus による有効化は使われなくなります。
 ==スタッガード・スピンアップ==
-ハードウェアによっては[[Wikipedia:Spin-up#Staggered spin-up|スタッガード・スピンアップ]] (Staggered spin-up, SSS) が実装されています。これによって OS が ATA インターフェースを連続的に調べるようになり、一つずつドライブをスピンアップすることで最大電気使用量を減らします。スタッガード・スピンアップは起動時間を遅くし、ほとんどのコンシューマ機では、電源が入れられたら瞬時にドライブがスピンアップするので全く利益がありません。SSS が使われているかどうか確認するには:
+一部のハードウェアには[[Wikipedia:Spin-up#Staggered spin-up|スタッガード・スピンアップ]] (Staggered spin-up, SSS) が実装されています。SSS が実装されている HDD の場合、OS は ATA インターフェースを連続的に調べるようになり、段階を追ってドライブをスピンアップすることができるため最大電気使用量が減少します。ただしスタッガード・スピンアップは起動時間を遅くし、ほとんどのコンシューマ機では電源を入れたときに瞬時にドライブがスピンアップするので全く利益がありません。SSS が使われているかどうか確認するには:
  $ dmesg | grep SSS
@@ 95行目: / 94行目: @@
 ==ファイルシステムのマウント==
-[[mkinitcpio]] の {{ic|fsck}} hook のおかげで、時間のかかる root パーティションの再マウントを避けることができます。kernel 行の {{ic|ro}} を {{ic|rw}} に変更して {{ic|/etc/fstab}} からパーティションを削除してください。オプションは kernel 行で {{ic|1=rootflags=mount options...}} を使うことで設定できます。{{ic|/etc/fstab}} からエントリを削除することを覚えておいて下さい、そうしないと {{ic|systemd-remount-fs.service}} が設定を適用し続けます。もしくは、ユニットをマスクすることもできます。
+[[mkinitcpio]] の {{ic|fsck}} フックによって、時間のかかる root パーティションの再マウントを避けることができます。kernel 行の {{ic|ro}} を {{ic|rw}} に変更して {{ic|/etc/fstab}} からパーティションを削除してください。マウントオプションは kernel 行で {{ic|1=rootflags=mount options...}} と指定することで設定できます。{{ic|/etc/fstab}} からエントリは必ず削除してください、そうしないと {{ic|systemd-remount-fs.service}} が [[fstab]] の設定を適用し続けます。もしくは、ユニットをマスクすることでも設定できます。
-btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、[[mkinitcpio|mkinitcpio]] の {{ic|fsck}} hook は削除することができます。{{ic|systemd-fsck-root.service}} をマスクしたり、カーネルコマンドラインから {{ic|fsck.mode&#61;skip}} を使って root ファイルシステムの fsck をしないようにすることも可能です。[[mkinitcpio]] の {{ic|fsck}} hook がないと、systemd は {{ic|systemd-fsck@.service}} で適切なファイルシステムを全て fsck します。
+btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、[[mkinitcpio]] の {{ic|fsck}} フックは削除してかまいません。{{ic|systemd-fsck-root.service}} をマスクしたり、カーネルコマンドラインで {{ic|fsck.mode&#61;skip}} を使うことで root ファイルシステムの fsck をしないようにできます。[[mkinitcpio]] の {{ic|fsck}} フックがなくても、systemd は {{ic|systemd-fsck@.service}} を使って適切なファイルシステムを全て fsck します。
 また、{{ic|/etc/fstab}} から API ファイルシステムを削除することもできます。systemd 自身がそれらをマウントするからです ({{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} でそのリストを見れます)。sysvinit から /tmp エントリを持ち越しているユーザーには聞き慣れないかもしれませんが、上のコマンドによって systemd がそれらを管理していることに気づくはずです。従って、エントリは削除しても問題ありません。
-{{ic|/home}} などの他のファイルシステムはカスタムマウントユニットでマウントできます。{{ic|noauto,x-systemd.automount}} を追加するとパーティションへの全てのアクセスをバッファし、最初にアクセスしたときに fsck とマウントを行うようになり、ブートプロセスで fsck とマウントをするファイルシステムの数を減らせます。
+{{ic|/home}} などの他のファイルシステムはカスタムマウントユニットでマウントできます。マウントオプションに {{ic|noauto,x-systemd.automount}} を追加するとパーティションへの全てのアクセスをバッファし、最初にアクセスしたときに fsck とマウントを行うようになり、ブートプロセスで fsck とマウントをするファイルシステムの数を減らせます。
+{{Note|
-{{Note|これを使うと {{ic|/home}} ファイルシステムが {{ic|autofs}} タイプになり、デフォルトで [[mlocate]] によって無視されるようになります。{{ic|/home}} の自動化による高速化は数秒の効果しかなかったり、システムによっては、やる価値がないかもしれません。}}
+* 上記の設定を使うと {{ic|/home}} ファイルシステムが {{ic|autofs}} タイプになり、デフォルトで [[mlocate]] によって無視されるようになります。システムによっては {{ic|/home}} の自動化による高速化は数秒の効果しかない場合もあります。
+* [[Btrfs]] サブボリュームにシステムをインストールしていて (ルートディレクトリ {{ic|/}} 自体がサブボリュームの場合)、{{ic|/home}} を分割して使っている場合、{{ic|/home}} サブボリュームの作成をしないように設定したほうが良いでしょう。{{ic|home.conf}} の tmpfile をマスクしてください: {{ic|ln -s /dev/null /etc/tmpfiles.d/home.conf}}。
-==Initramfs==
+}}
-上述の通り、カーネルを減量することでロードする必要があるデータの量を減らし、起動時間を減らせます。これはカーネルのすぐ後にロードされ、root ファイルシステムの認識やマウントを行う (mkinitcpio によって作られた) initramfs にも当てはまります。ブートするのに必要なものはストレージバス・ブロックデバイス・ファイルシステムなど実際はほとんどありません。Falconindy (Dave Reisner) が initramfs を減量するための [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html 簡単なチュートリアル] を彼のブログに載せています。
-{{Note|initramfs の中で [[udev]] を必要とするものを使っている場合 (例えば lvm2, mdadm_udev など、もしくは {{ic|/dev/disk/by-label}} を使ってファイルシステムのラベルを指定している場合)、initramfs の減量をしようとするのはやりがいのある仕事にはならないでしょう。}}
 == 起動中の出力を減らす ==
-ブートローダーの kernel 行の {{ic|verbose}} を {{ic|quiet}} に変更してください。システムによっては (特に SSD を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。
+システムによっては (特に [[SSD]] を使っている場合)、[[getty|tty]] のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。[[サイレントブート]]を見てください。
 == RAM にサスペンド ==
-起動時間を短縮する一番よい方法は起動しないことです。[[サスペンドとハイバネート#Suspend_to_RAM|システムを RAM にサスペンド]]することを考慮してください。
+起動時間を短縮する一番よい方法は起動しないことです。[[サスペンドとハイバネート|サスペンド]]を使用することを考慮してください。