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

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(同期)
 
(5人の利用者による、間の25版が非表示)
1行目: 1行目:
 
[[Category:ブートプロセス]]
 
[[Category:ブートプロセス]]
[[ar:Improve Boot Performance]]
+
[[en:Improving performance/Boot process]]
  +
[[es:Improving performance (Español)/Boot process]]
[[cs:Improve Boot Performance]]
 
  +
[[fr:Improving performance (Français)/Boot process]]
[[en:Improve Boot Performance]]
 
  +
[[pt:Improving performance (Português)/Boot process]]
[[es:Improve Boot Performance]]
 
  +
[[ru:Improving performance (Русский)/Boot process]]
[[it:Improve Boot Performance]]
 
[[ru:Improve Boot Performance]]
 
[[zh-CN:Improve Boot Performance]]
 
 
{{Related articles start}}
 
{{Related articles start}}
{{Related2|Maximizing Performance|パフォーマンスの最大化}}
+
{{Related|パフォーマンスの向上}}
{{Related2|Silent boot|サイレントブート}}
+
{{Related|サイレントブート}}
{{Related2|Daemons|デーモン}}
+
{{Related|デーモン}}
{{Related2|e4rat|e4rat}}
+
{{Related|e4rat}}
 
{{Related|Kexec}}
 
{{Related|Kexec}}
 
{{Related articles end}}
 
{{Related articles end}}
  +
システムのブートパフォーマンスを向上させることは起動待機時間の短縮とシステムファイル・スクリプトが相互にどう作用しているのか知る方法を提供します。この記事では Arch Linux の起動時間を改善する方法を集めています。
 
  +
システムのブートパフォーマンスを向上させることで、起動待機時間を短縮し、特定のシステムファイルとスクリプトが相互にどう作用しているのかをより良く知ることができます。この記事では Arch Linux システムのブートパフォーマンスを向上させる方法を集めています。
   
 
== ブートプロセスを解析する ==
 
== ブートプロセスを解析する ==
20行目: 19行目:
 
=== systemd-analyze を使う ===
 
=== systemd-analyze を使う ===
   
[[systemd|systemd]] は {{ic|systemd-analyze}} という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のプロットにはそれぞれの依存を待機していユニット表示されます。どのファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
+
[[systemd]] は {{ic|systemd-analyze}} という名前のツールを提供しており、これを使えばブートプロセスにかかっている時間の詳細を表示することができます。また、svg のグラフを出力してユニットの依存関係把握すことできます。どのユニットファイルが起動時間を遅くしているのか一目でわかり、それに応じてシステムを最適化することが可能です。
   
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るにはを実行するけです:
+
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見たい場合以下のコマンドを実行してくさい:
   
 
$ systemd-analyze
 
$ 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|[[UEFI]] でブートしていて、かつ systemd の [https://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[systemd-boot]] と [[GRUB]]) を使っている場合、''systemd-analyze'' は EFI ファームウェアとブートローダでかかった時間も追加で表示します。}}
   
ユニットファイルを起動するのにかかった時間で並べて一覧するには:
+
起動するのにかかった時間でユニットファイルを並べて一覧するには:
   
 
$ systemd-analyze blame
 
$ systemd-analyze blame
   
ブートプロセスある時点で、指定されたユニットがきちんと動か次に進めなくなることがあります。スタートアップの繋がりの中でどのユニットがこのクリティカルな状態になっているかるには、次を実行してください:
+
特定のユニットがきちんと動かないため全体の起動時間が長くなってい場合があります。起動チェインの中でどのユニットが起動を遅くしている確認するには、次を実行してください:
   
 
$ systemd-analyze critical-chain
 
$ systemd-analyze critical-chain
40行目: 39行目:
 
$ systemd-analyze plot > plot.svg
 
$ systemd-analyze plot > plot.svg
   
詳細は {{ic|man systemd-analyze}} を見て下さい。
+
詳細は {{man|1|systemd-analyze}} を見て下さい。
   
=== systemd-bootchart を使う ===
+
=== bootchart2 を使う ===
   
  +
[[Bootchart#Bootchart2|Bootchart2]] を使うことでも、ブートシーケンスを視覚化することができます。
2012年10月に Bootchart は [[systemd|systemd]] にマージされ、オリジナルの bootchart と同じように使って起動できるようになりました。カーネルラインに以下を追加してください:
 
   
  +
== 起動時に busybox の代わりに systemd を使用する ==
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
 
   
  +
デフォルトでは、[[Mkinitcpio]] の設定は initramfs の構築に {{ic|base}} と {{ic|udev}} フックを使用します。これらを {{ic|systemd}} に置き換えることで、より高速なブートタイムを実現することができます。
詳しくは [http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html manpage] を見て下さい。
 
   
  +
詳しくは [[mkinitcpio#通常のフック]] を見て下さい。{{ic|fsck}} フックを置き換える場合は [[Fsck#ブート時のチェック]] も見て下さい。
=== bootchart2 を使う ===
 
   
  +
== カスタムカーネルをコンパイルする ==
ブートシーケンスを視覚化するバージョンの bootchart を使うこともできます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、[[Arch User Repository|AUR]] の {{AUR|bootchart2-git}} パッケージにはドキュメント化されてない [[systemd|systemd]] サービスが付いています。bootchart2 をインストールした後に次を実行してください:
 
   
  +
カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし最近は64ビットのアーキテクチャが一般的になっており、Linux カーネルはモジュール設計を取っているため、期待していたよりも効果がないかもしれません。詳しくは[[カーネル#コンパイル]]を見てください。
# systemctl enable bootchart
 
   
  +
== Initramfs ==
bootchart の使い方など詳しい説明は [https://github.com/mmeeks/bootchart bootchart2 documentation] を読んで下さい。
 
   
  +
[[#カスタムカーネルをコンパイルする|カスタムカーネルのコンパイル]]と同じように、initramfs もダイエットさせることができます。[[mkinitcpio]] の {{ic|autodetect}} フックを使うのが一番簡単です。詳しくは [[initramfs の最小化]]を見てください。
== カスタムカーネルをコンパイルする ==
 
   
  +
ハードウェア (プロセッサとストレージの速度) にもよりますが、デフォルトの {{Pkg|zstd}} 圧縮オプションの代わりに {{Pkg|lz4}} を使うと、起動時の解凍速度が速くなり、ディスクから読み込む initramfs のサイズが若干大きくなりますが、通常相殺されるため速くなることがあります。[[mkinitcpio#COMPRESSION]] を見て下さい。
カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし 64bit アーキテクチャの標準化や Linux カーネルのモジュラー性のため、期待していたよりも効果がないかもしれません。[[Kernels#コンパイル|カーネルのコンパイルについてよく読んで下さい]]。
 
   
== サービスを早めに起動する ==
+
== サービスの適切な起動方法を選択する ==
   
systemd の中心的な機能 [[D-Bus|D-Bus]] とソケットのアクティベーションす。ため、最初にそれらにアクセスサービスが起動するようになっており大抵それ問題ありません。しかしら、ブート中いつも起動する ([[UPower]] のような) サービスを知っているのならば、そのサービスを出来る限り初めに起動することで起動時間を短縮できます。これを行うは (サービスファイルが用意されてい場合。ほとんどの場合そうですが) 次を実行してください:
+
systemd の中心的な機能のひとつに [[D-Bus]] とソケットのアクティベーションがあります。機能はほとんどの場合サービスが最初にアクセスされときだけ起動され、一般的良いことので好まれるはずです(例えば起動時に {{ic|cups.service}} を有効にすること通常デスクトップは有用ではありません、なぜなら {{ic|cups.socket}} だけ有効にすると実際印刷するときだけサービスを起動することにからです。)
   
  +
しかし、あるサービス ({{Pkg|upower}} など) が起動時に常に開始されることがわかっている場合、できるだけ早く開始することで全体の起動時間を短縮できる可能性があります。これは(サービスファイルがそのように設定されている場合、ほとんどの場合)、{{ic|upower.service}} を [[有効化]] することで実現できます。
# systemctl enable upower
 
   
のコマンドによって systemd は UPower を出来る限り早く起動するようになり、ソケットや D-Bus の有効化競わなくなります。
+
により、systemd はソケットや D-Bus のアクティベーションで競合することなく、できるだけ早く UPower を起動します。
   
 
==スタッガード・スピンアップ==
 
==スタッガード・スピンアップ==
   
ハードウェアによっては[[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
 
$ dmesg | grep SSS
78行目: 77行目:
 
使われていない場合は、起動時に何も出力されないはずです。
 
使われていない場合は、起動時に何も出力されないはずです。
   
無効にするには、[[Kernel parameters|kernel 行]]に {{ic|1=libahci.ignore_sss=1}} を追加してください。
+
無効にするには、[[カーネルパラメータ]]に {{ic|1=libahci.ignore_sss=1}} を追加してください。
   
==ファイルシステムのマウント==
+
== ファイルシステムのマウント ==
   
[[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}} フックによって、カーネルラインの {{ic|ro}} を {{ic|rw}} に変更することで、時間のかかる root パーティションの再マウントを避けることができます。マウオプションはカーネルラインで {{ic|1=rootflags='''rw''',''他のマウントオプション''}} と指定することで設定できます。{{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=skip}} を使って root ファイルシステムの fsck をしないようにすることも可能です。[[mkinitcpio|mkinitcpio]] の {{ic|fsck}} hook がないと、systemd は {{ic|systemd-fsck@.service}} 適切なファイルシステムを全て fsck します。
+
[[btrfs]] を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、[[mkinitcpio]] の {{ic|fsck}} フックは削除してかいません。{{ic|systemd-fsck-root.service}} をマスクしたり、カーネルコマンドライン {{ic|1=fsck.mode=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|/etc/fstab}} から API ファイルシステムを削除することもできます。systemd 自身がそれらをマウントするからです ({{ic|pacman -Ql systemd {{!}} grep '\.mount$'}} でそのリストを見れます)。sysvinit から {{ic|/tmp}} エントリを持ち越しているユーザーには聞き慣れないかもしれませんが、上のコマンドによって systemd がそれらを管理していることに気づくはずです。従って、エントリは削除しても問題ありません。
   
{{ic|/home}} などの他のファイルシステムはカスタムマウントユニットでマウントできます。{{ic|noauto,x-systemd.automount}} を追加するとパーティションへの全てのアクセスをバッファし、最初にアクセスしたときに fsck とマウントを行うようになり、ブートプロセスで fsck とマウントをするファイルシステムの数を減らせます。
+
{{ic|/home}} や [[EFI システムパーティション]] などの他のファイルシステムはカスタムマウントユニットでマウントできます。マウントオプションに {{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==
 
   
  +
システムによっては (特に [[SSD]] を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。[[サイレントブート]]の記事を見てください。
上述の通り、カーネルを減量することでロードする必要があるデータの量を減らし、起動時間を減らせます。これはカーネルのすぐ後にロードされ、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 の減量をしようとするのはやりがいのある仕事にはならないでしょう。}}
 
   
  +
== ブートローダーの変更 ==
== 起動中の出力を減らす ==
 
   
  +
[[ブートローダー]]を (例: [[systemd-boot]] などのよりシンプルなブートローダーに) 変更することで、起動時間を秒単位で減らせるかもしれません。
ブートローダーの kernel 行の {{ic|verbose}} を {{ic|quiet}} に変更してください。システムによっては (特に SSD を使っている場合)、TTY のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。
 
  +
  +
あなたのセットアップで可能なのであれば、[[EFISTUB]] だけを使えば更に起動時間を短縮できます。
   
 
== RAM にサスペンド ==
 
== RAM にサスペンド ==
   
起動時間を短縮する一番よい方法は起動しないことです。[[Suspend and Hibernate#Suspend_to_RAM|シテムを RAM にサスペンド]]することを考慮してください。
+
起動時間を短縮する一番よい方法は起動しないことです。[[ペンドとハイバネート|サスペンド]]を使用することを検討してください。
  +
  +
{{TranslationStatus|Improving performance/Boot process|2023-05-30|779863}}

2023年5月30日 (火) 06:15時点における最新版

関連記事

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

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

systemd-analyze を使う

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

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

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

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

$ systemd-analyze blame

特定のユニットがきちんと動かないために全体の起動時間が長くなっている場合があります。起動チェインの中でどのユニットが起動を遅くしているのか確認するには、次を実行してください:

$ systemd-analyze critical-chain

Bootchart のように、ブートプロセスを視覚的に表す SVG ファイルを生成することもできます:

$ systemd-analyze plot > plot.svg

詳細は systemd-analyze(1) を見て下さい。

bootchart2 を使う

Bootchart2 を使うことでも、ブートシーケンスを視覚化することができます。

起動時に busybox の代わりに systemd を使用する

デフォルトでは、Mkinitcpio の設定は initramfs の構築に baseudev フックを使用します。これらを systemd に置き換えることで、より高速なブートタイムを実現することができます。

詳しくは mkinitcpio#通常のフック を見て下さい。fsck フックを置き換える場合は Fsck#ブート時のチェック も見て下さい。

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

カスタムカーネルをコンパイルすれば起動時間やメモリの使用量を減らすことができます。ただし最近は64ビットのアーキテクチャが一般的になっており、Linux カーネルはモジュール設計を取っているため、期待していたよりも効果がないかもしれません。詳しくはカーネル#コンパイルを見てください。

Initramfs

カスタムカーネルのコンパイルと同じように、initramfs もダイエットさせることができます。mkinitcpioautodetect フックを使うのが一番簡単です。詳しくは 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 を追加してください。

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

mkinitcpiofsck フックによって、カーネルラインの rorw に変更することで、時間のかかる root パーティションの再マウントを避けることができます。マウントオプションはカーネルラインで rootflags=rw,他のマウントオプション と指定することで設定できます。/etc/fstab からルートパーティションのエントリは必ず削除してください、そうしないと systemd-remount-fs.servicefstab の設定を適用し続けます。もしくは、ユニットをマスクしてもよいです。

btrfs を root ファイルシステムで使っている場合、他のファイルシステムのように起動毎に毎回 fsck をする必要はありません。この場合、mkinitcpiofsck フックは削除してかまいません。systemd-fsck-root.service をマスクしたり、カーネルコマンドラインで fsck.mode=skip を使うことで root ファイルシステムの fsck をしないようにできます。mkinitcpiofsck フックがなくても、systemd は systemd-fsck@.service を使って適切なファイルシステムを全て fsck します。

また、/etc/fstab から API ファイルシステムを削除することもできます。systemd 自身がそれらをマウントするからです (pacman -Ql systemd | grep '\.mount$' でそのリストを見れます)。sysvinit から /tmp エントリを持ち越しているユーザーには聞き慣れないかもしれませんが、上のコマンドによって systemd がそれらを管理していることに気づくはずです。従って、エントリは削除しても問題ありません。

/homeEFI システムパーティション などの他のファイルシステムはカスタムマウントユニットでマウントできます。マウントオプションに 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 のパフォーマンスが遅いことがボトルネックになっている場合があり、出力を減らすことで起動が速くなることがあります。サイレントブートの記事を見てください。

ブートローダーの変更

ブートローダーを (例: systemd-boot などのよりシンプルなブートローダーに) 変更することで、起動時間を秒単位で減らせるかもしれません。

あなたのセットアップで可能なのであれば、EFISTUB だけを使えば更に起動時間を短縮できます。

RAM にサスペンド

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

翻訳ステータス: このページは en:Improving performance/Boot process の翻訳バージョンです。最後の翻訳日は 2023-05-30 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。