「パフォーマンスの向上/ブートプロセス」の版間の差分
細 (1版 をインポートしました) |
|
(相違点なし)
| |
2015年1月6日 (火) 22:40時点における版
関連記事
システムのブートパフォーマンスを向上させることは起動待機時間の短縮とシステムファイル・スクリプトが相互にどう作用しているのか知る方法を提供します。この記事では 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
詳しくは manpage を見て下さい。
bootchart2 を使う
ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AUR の bootchart2-gitAUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:
# systemctl enable bootchart
bootchart の使い方など詳しい説明は bootchart2 documentation を読んで下さい。
カスタムカーネルをコンパイルする
カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし 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 とマウントをするファイルシステムの数を減らせます。
Initramfs
上述の通り、カーネルを減量することでロードする必要があるデータの量を減らし、起動時間を減らせます。これはカーネルのすぐ後にロードされ、root ファイルシステムの認識やマウントを行う (mkinitcpio によって作られた) initramfs にも当てはまります。ブートするのに必要なものはストレージバス・ブロックデバイス・ファイルシステムなど実際はほとんどありません。Falconindy (Dave Reisner) が initramfs を減量するための 簡単なチュートリアル を彼のブログに載せています。
起動中の出力を減らす
ブートローダーの kernel 行の verbose を quiet に変更してください。システムによっては (特に SSD を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。
RAM にサスペンド
起動時間を短縮する一番よい方法は起動しないことです。システムを RAM にサスペンドすることを考慮してください。