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

2015年7月29日 (水) 14:46時点における版

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

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

systemd-analyze を使う

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

起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るには、次を実行するだけです:

$ systemd-analyze

ヒント: UEFI でブートしていて、かつ systemd の Boot Loader Interface を実装しているブートローダ (今のところ Gummiboot のみ) を使っている場合、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

詳しくは manpage を見て下さい。

bootchart2 を使う

ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AUR の bootchart2-git^AUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:

# systemctl enable bootchart

bootchart の使い方など詳しい説明は bootchart2 documentation を読んで下さい。

Readahead

systemd にはバージョン 216 から readahead の実装が付属しており、起動時間を短縮することができます。2つのサービスが存在します: systemd-readahead-collect は起動時に使用されるファイルの情報を収集して、systemd-readahead-replay はそれらのファイルをブートプロセスの初期段階でキャッシュに移動します。

systemd の readahead を有効にするには AUR から systemd-readahead^AUR パッケージをインストールして次を実行してください:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

ノート:

systemd-readahead-collect が情報を収集して systemd-readahead-replay が効果的に動作するようになるまで何回か再起動する必要があります。
カーネルのバージョンやハードドライブのタイプによって効果は変わってきます (例えば、SSD を使っている場合、全く効果がなかったり、むしろ起動時間が増えてしまうことすらありえます)。

カスタムカーネルをコンパイルする

カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし 64bit アーキテクチャの標準化や Linux カーネルのモジュラー性のため、期待していたよりも効果がないかもしれません。カーネルのコンパイルについてよく読んで下さい。

サービスを早めに起動する

systemd の中心的な機能は D-Bus とソケットのアクティベーションです。そのため、最初にそれらにアクセスした時にサービスが起動するようになっており、大抵はそれで問題ありません。しかしながら、ブート中にいつも起動する (UPower のような) サービスを知っているのならば、そのサービスを出来る限り初めに起動することで起動時間を短縮できます。これを行うには (サービスファイルが用意されている場合。ほとんどの場合そうですが) 次を実行してください:

# systemctl enable upower

このコマンドによって systemd は UPower を出来る限り早く起動するようになり、ソケットや D-Bus の有効化と競わなくなります。

スタッガード・スピンアップ

ハードウェアによってはスタッガード・スピンアップ (Staggered spin-up, SSS) が実装されています。これによって OS が ATA インターフェースを連続的に調べるようになり、一つずつドライブをスピンアップすることで最大電気使用量を減らします。スタッガード・スピンアップは起動時間を遅くし、ほとんどのコンシューマ機では、電源が入れられたら瞬時にドライブがスピンアップするので全く利益がありません。SSS が使われているかどうか確認するには:

$ dmesg | grep SSS

使われていない場合は、起動時に何も出力されないはずです。

無効にするには、kernel 行に libahci.ignore_sss=1 を追加してください。

ファイルシステムのマウント

mkinitcpio の fsck hook のおかげで、時間のかかる root パーティションの再マウントを避けることができます。kernel 行の ro を rw に変更して /etc/fstab からパーティションを削除してください。オプションは kernel 行で rootflags=mount options... を使うことで設定できます。/etc/fstab からエントリを削除することを覚えておいて下さい、そうしないと systemd-remount-fs.service が設定を適用し続けます。もしくは、ユニットをマスクすることもできます。

btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、mkinitcpio の fsck hook は削除することができます。systemd-fsck-root.service をマスクしたり、カーネルコマンドラインから fsck.mode=skip を使って root ファイルシステムの fsck をしないようにすることも可能です。mkinitcpio の fsck hook がないと、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 の自動化による高速化は数秒の効果しかなかったり、システムによっては、やる価値がないかもしれません。

Initramfs

上述の通り、カーネルを減量することでロードする必要があるデータの量を減らし、起動時間を減らせます。これはカーネルのすぐ後にロードされ、root ファイルシステムの認識やマウントを行う (mkinitcpio によって作られた) initramfs にも当てはまります。ブートするのに必要なものはストレージバス・ブロックデバイス・ファイルシステムなど実際はほとんどありません。Falconindy (Dave Reisner) が initramfs を減量するための簡単なチュートリアルを彼のブログに載せています。

ノート: initramfs の中で udev を必要とするものを使っている場合 (例えば lvm2, mdadm_udev など、もしくは /dev/disk/by-label を使ってファイルシステムのラベルを指定している場合)、initramfs の減量をしようとするのはやりがいのある仕事にはならないでしょう。

起動中の出力を減らす

ブートローダーの kernel 行の verbose を quiet に変更してください。システムによっては (特に SSD を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。

RAM にサスペンド

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

@@ 20行目: / 20行目: @@
 === systemd-analyze を使う ===
-[[systemd|systemd]] は {{ic|systemd-analyze}} という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機しているユニットが表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
+[[systemd]] は {{ic|systemd-analyze}} という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機しているユニットが表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
 起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るには、次を実行するだけです:
@@ 26行目: / 26行目: @@
  $ systemd-analyze
-{{Tip|[[Unified Extensible Firmware Interface|UEFI]] でブートしていて、かつ systemd の [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[Gummiboot|Gummiboot]] のみ) を使っている場合、''systemd-analyze'' は EFI ファームウェアとブートローダでかかった時間も追加で表示します。}}
+{{Tip|[[Unified Extensible Firmware Interface|UEFI]] でブートしていて、かつ systemd の [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[Gummiboot]] のみ) を使っている場合、''systemd-analyze'' は EFI ファームウェアとブートローダでかかった時間も追加で表示します。}}
 ユニットファイルを起動するのにかかった時間で並べて一覧するには:
@@ 52行目: / 52行目: @@
 === bootchart2 を使う ===
-ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、[[Arch User Repository|AUR]] の {{AUR|bootchart2-git}} パッケージにはドキュメント化されてない [[systemd|systemd]] サービスが付いています。bootchart2 をインストールした後に次を実行してください:
+ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、[[Arch User Repository|AUR]] の {{AUR|bootchart2-git}} パッケージにはドキュメント化されてない [[systemd]] サービスが付いています。bootchart2 をインストールした後に次を実行してください:
  # systemctl enable bootchart
 bootchart の使い方など詳しい説明は [https://github.com/mmeeks/bootchart bootchart2 documentation] を読んで下さい。
+== Readahead ==
+[[systemd]] にはバージョン 216 から readahead の実装が付属しており、起動時間を短縮することができます。2つのサービスが存在します: {{ic|systemd-readahead-collect}} は起動時に使用されるファイルの情報を収集して、{{ic|systemd-readahead-replay}} はそれらのファイルをブートプロセスの初期段階でキャッシュに移動します。
+systemd の readahead を有効にするには [[AUR]] から {{AUR|systemd-readahead}} パッケージをインストールして次を実行してください:
+ # systemctl enable systemd-readahead-collect systemd-readahead-replay
+{{Note|
+* systemd-readahead-collect が情報を収集して systemd-readahead-replay が効果的に動作するようになるまで何回か再起動する必要があります。
+* カーネルのバージョンやハードドライブのタイプによって効果は変わってきます (例えば、SSD を使っている場合、全く効果がなかったり、むしろ起動時間が増えてしまうことすらありえます)。
+}}
 == カスタムカーネルをコンパイルする ==
@@ 64行目: / 77行目: @@
 == サービスを早めに起動する ==
-systemd の中心的な機能は [[D-Bus|D-Bus]] とソケットのアクティベーションです。そのため、最初にそれらにアクセスした時にサービスが起動するようになっており、大抵はそれで問題ありません。しかしながら、ブート中にいつも起動する ([[UPower]] のような) サービスを知っているのならば、そのサービスを出来る限り初めに起動することで起動時間を短縮できます。これを行うには (サービスファイルが用意されている場合。ほとんどの場合そうですが) 次を実行してください:
+systemd の中心的な機能は [[D-Bus]] とソケットのアクティベーションです。そのため、最初にそれらにアクセスした時にサービスが起動するようになっており、大抵はそれで問題ありません。しかしながら、ブート中にいつも起動する ([[UPower]] のような) サービスを知っているのならば、そのサービスを出来る限り初めに起動することで起動時間を短縮できます。これを行うには (サービスファイルが用意されている場合。ほとんどの場合そうですが) 次を実行してください:
  # systemctl enable upower
@@ 82行目: / 95行目: @@
 ==ファイルシステムのマウント==
-[[mkinitcpio|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}} hook のおかげで、時間のかかる root パーティションの再マウントを避けることができます。kernel 行の {{ic|ro}} を {{ic|rw}} に変更して {{ic|/etc/fstab}} からパーティションを削除してください。オプションは kernel 行で {{ic|1=rootflags=mount options...}} を使うことで設定できます。{{ic|/etc/fstab}} からエントリを削除することを覚えておいて下さい、そうしないと {{ic|systemd-remount-fs.service}} が設定を適用し続けます。もしくは、ユニットをマスクすることもできます。
-btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、[[mkinitcpio|mkinitcpio]] の {{ic|fsck}} hook は削除することができます。{{ic|systemd-fsck-root.service}} をマスクしたり、カーネルコマンドラインから {{ic|fsck.mode&#61;skip}} を使って root ファイルシステムの fsck をしないようにすることも可能です。[[mkinitcpio|mkinitcpio]] の {{ic|fsck}} hook がないと、systemd は {{ic|systemd-fsck@.service}} で適切なファイルシステムを全て fsck します。
+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 します。
 また、{{ic|/etc/fstab}} から API ファイルシステムを削除することもできます。systemd 自身がそれらをマウントするからです ({{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} でそのリストを見れます)。sysvinit から /tmp エントリを持ち越しているユーザーには聞き慣れないかもしれませんが、上のコマンドによって systemd がそれらを管理していることに気づくはずです。従って、エントリは削除しても問題ありません。
@@ 95行目: / 108行目: @@
 上述の通り、カーネルを減量することでロードする必要があるデータの量を減らし、起動時間を減らせます。これはカーネルのすぐ後にロードされ、root ファイルシステムの認識やマウントを行う (mkinitcpio によって作られた) initramfs にも当てはまります。ブートするのに必要なものはストレージバス・ブロックデバイス・ファイルシステムなど実際はほとんどありません。Falconindy (Dave Reisner) が initramfs を減量するための [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html 簡単なチュートリアル] を彼のブログに載せています。
-{{Note|initramfs の中で [[udev|udev]] を必要とするものを使っている場合 (例えば lvm2, mdadm_udev など、もしくは {{ic|/dev/disk/by-label}} を使ってファイルシステムのラベルを指定している場合)、initramfs の減量をしようとするのはやりがいのある仕事にはならないでしょう。}}
+{{Note|initramfs の中で [[udev]] を必要とするものを使っている場合 (例えば lvm2, mdadm_udev など、もしくは {{ic|/dev/disk/by-label}} を使ってファイルシステムのラベルを指定している場合)、initramfs の減量をしようとするのはやりがいのある仕事にはならないでしょう。}}
 == 起動中の出力を減らす ==