パフォーマンスの向上
この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは ゲーム#パフォーマンスを向上させる も参照してください。
目次
基本
システムを知る
システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。
- (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください:
$ free -h
- 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには
hdparmコマンドを使うことができます:# hdparm -t /dev/sdX
- 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要なデーモンやプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。htop や
pstreeなどのシステム監視ツールで CPU 負担をモニタすることができます:$ htop
- ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、ウィンドウマネージャなどの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。
glxinfoコマンドを使うことで確認できます (mesa-utils パッケージに含まれています)。次のコマンドを実行するとdirect rendering: Yesと表示される必要があります:$ glxinfo | grep "direct rendering"
- デスクトップ環境を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、カスタムの環境を作成しましょう。
- 最適化されたカーネルを使用することでパフォーマンスを向上できます。一般に linux-zen が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。
ベンチマーク
最適化の効果を判断できないことがたびたびあります。そういった場合はベンチマークツールで計測することができます。
ストレージデバイス
複数のハードウェアパス
内部ハードウェアパスは、ストレージデバイスがマザーボードを介してどのように接続されているかを表します。NIC、PCIe、Firewire、Raid カード、USB など、マザーボードを介する接続方法は複数あります。ストレージデバイスを複数の接続点に分けることで、ボトルネックを回避できます。なぜなら、マザーボードに入る「エントリーパス」は「パイプ」のようなもので、そのパイプを一度に通ることのできる量には制限があるからです。通常、マザーボードには複数の「パイプ」が存在するため、これは回避できます。
これの具体例としては、マシン前面に2つの USB ポート、背面に4つの USB ポートがあり、4つのディスクを接続したい場合です。通常、3つのディスクを背面に接続し、残り1つを前面に接続するよりも、2つを前面に接続し、別の2つを背面に接続する方が高速です。これは、ほとんどの場合、前面と背面のポートは内部的に別の Root USB Hub に接続されていて、片方ではなく両方を使用することで同時に送信できるデータが増えるからです。
次のコマンドは、マシンの様々なパスを特性するのに役立ちます。
USB デバイスツリー
$ lsusb -t
PCI デバイスツリー
$ lspci -tv
パーティショニング
パーティションが適切にアライメントされていることを確認してください。
複数のドライブ
複数のドライブを持っているのであれば、ソフトウェア RAID を組んでパフォーマンスを劇的に向上させることができます。
スワップを別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。
HDD でのレイアウト
従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム (/) から home ディレクトリ (/home) を分割することでこれを達成できます。
ファイルシステムの選択とチューニング
ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。ファイルシステムの記事に人気のあるファイルシステムの簡単な説明がされています。カテゴリ:ファイルシステムから関連記事も見ることができます。
マウントオプション
noatime オプションは、ファイルシステムのパフォーマンスを向上させることが知られています。
他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:
- Ext3
- Ext4#パフォーマンスの向上
- JFS#最適化
- XFS#パフォーマンス
- Btrfs#デフラグメンテーション、Btrfs#圧縮、btrfs(5)
- ZFS#チューニング
- NTFS#パフォーマンスの向上
カーネルパラメータの調整
ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは sysctl#仮想メモリ を見て下さい。
I/O スケジューラの設定
背景情報
入出力 (I/O) スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:
- HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます (IOPS)。
- SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。
プロセスを大量に実行してストレージの様々な場所の I/O リクエストを発生させているとき (つまりランダムアクセスをしている状態)、数千の IOPS が生成されますが、普通の HDD では 200 IOPS までしか対応できません。ストレージにアクセスできるまで待機するリクエストの待ち行列が作られることになります。I/O スケジューラはこの待ち行列を最適化します。
スケジューリングアルゴリズム
スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えて出来るだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが elevator スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。
エレベーターアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータースケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。この問題を解決するために anticipatory IO スケジューラが追加されました。同期リクエストの場合、このアルゴリズムでは他のリクエストに移るまで数ミリ秒間待機します。
上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて deadline スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。
Completely Fair Queuing (CFQ) は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに cgroups のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという anticipatory スケジューラの機能を改良して取り入れています。より高度な CFQ スケジューラが導入されたことで anticipatory と elevator スケジューラは Linux カーネルから外されることになりました。
Budget Fair Queuing (BFQ) は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。
Kyber はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。
カーネルの I/O スケジューラ
初期のアルゴリズムには既にメインラインから外されているものもあります。公式 Linux カーネルがサポートしている I/O スケジューラは以下の2つのカテゴリに分けることができます:
- シングルキュースケジューラはデフォルトで使えるスケジューラです:
- NOOP は最も単純なスケジューラです。全ての I/O リクエストをシンプルな FIFO キューに入れてリクエストをまとめます。NOOP アルゴリズムでは、セクタ番号によってリクエストの順番を変えることがありません。したがって、デバイスレベルで順位付けを行っている場合や SSD など順位付けが意味をなさない場合は NOOP を使用します。
- Deadline
- CFQ
- マルチキュースケジューラは #I/O スケジューラの変更で説明しているように起動時にモードを有効にして使うことができます。Multi-Queue Block I/O Queuing Mechanism (blk-mq) は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。blk-mq では以下のスケジューラが使えます:
- None, キューイングアルゴリズムは適用されません。
- mq-deadline は deadline スケジューラをマルチスレッドに対応させたスケジューラです。
- Kyber
- BFQ
I/O スケジューラの変更
特定のデバイスで利用できるスケジューラと、現在使われているスケジューラを確認するには:
$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
あるいは全てのデバイスでスケジューラを確認するには:
$ cat /sys/block/sd*/queue/scheduler
mq-deadline kyber [bfq] none [mq-deadline] kyber bfq none mq-deadline kyber [bfq] none
sda デバイスで I/O スケジューラを bfq に変更するには、以下のコマンドを使用します:
# echo bfq > /sys/block/sda/queue/scheduler
SSD や NVMe の場合多数の IOPS を処理できるため、none や mq-deadline などのシンプルなアルゴリズムが最適です。逆に HDD には BFQ が適しています。以下のように udev ルールを使うことで、ディスクが HDD か SSD かどうかで I/O スケジューラを自動的に変更して永続的に設定することが可能です:
/etc/udev/rules.d/60-ioschedulers.rules
# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
ルールを保存したら、マシンを再起動するか、ルールをリロードしてください。
IO スケジューラの調整
カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。設定項目と説明は カーネルドキュメントファイル で確認できます。
特定のデバイスで設定可能なパラメータを確認するには (以下の例では sdb は deadline を使用しています):
$ ls /sys/block/sdb/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved
レイテンシを犠牲に deadline のスループットを高めるには以下のコマンドで fifo_batch を増やします:
# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch
電源管理設定とライトキャッシュ
従来の回転式ディスク (HDD) を使用する場合、省電力機能を完全に無効化するか下げ、書き込みキャッシュが有効化されていることを確認すると良いかもしれません。
Hdparm#電源管理の設定 と Hdparm#ライトキャッシュ を参照してください。
後で、起動時にこれらを適用する udev ルールを作成することができます。
ディスクの読み書きを減らす
遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。
ディスクの書き込みを表示する
iotop パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは iotop(8) を見てください。
ファイルを tmpfs に再配置する
ブラウザプロファイルなどのファイルを tmpfs ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:
- ブラウザプロファイルを同期させる方法については Profile-sync-daemon を参照してください。特定のブラウザには注意が必要な場合があります。例えば Firefox Ramdisk を参照してください。
- 任意の指定されたフォルダを同期させる方法については Anything-sync-daemon を参照してください。
- tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については Makepkg#コンパイル時間を短縮する を参照してください。
ファイルシステム
対応するファイルシステムページを参照して、パフォーマンス改善に関する指示があるか見てください。例: Ext4#パフォーマンスの向上、XFS#パフォーマンス。
スワップ領域
スワップ#パフォーマンス を見てください。
ライトバックの間隔とバッファサイズ
詳細は Sysctl#仮想メモリ を見てください。
ionice によるストレージ I/O スケジューリング
バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ CFQ を使用することで実現できます。
以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:
# ionice -c 3 command
詳細は ionice の短いイントロダクション や ionice(1) を参照してください。
CPU
オーバークロック
オーバークロックは、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。
Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、dmesg は極端なメッセージを表示します (これは、acpi_cpufreq カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、i7z パッケージの i7z を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、ストレステストが推奨されます。
周波数スケーリング
CPU 周波数スケーリングを見てください。
レスポンスのためにデフォルトのスケジューラ (CFS) を調整する
メインライン Linux カーネルのデフォルトの CPU スケジューラは CFS です。
上流のデフォルト設定は、高いスループットを出すように調整されており、それにより CPU 高負荷時にデスクトップアプリケーションが応答しなくなってしまいます。
cfs-zen-tweaksAUR パッケージには、linux-zen カーネルと同じ設定を使用するように CFS を設定するスクリプトが含まれています。スタートアップ時にこのスクリプトを実行するには、set-cfs-tweaks.service を起動/有効化してください。
代替の CPU スケジューラ
- MuQSS — Multiple Queue Skiplist Scheduler。Con Kolivas によって開発されている
-ckパッチセットにより利用可能。
- 非公式ユーザーリポジトリ/Repo-ck || linux-ckAUR
- PDS — デスクトップのレスポンスに焦点を当てている、優先度 (Priority) とデッドライン (Deadline) をベースとした Skiplist 複数キュースケジューラ。
- BMQ — BMQ "BitMap Queue" スケジューラは、既存の PDS 開発経験を元に作成され、Google の Zircon (Fuchsia OS イニシアチブ内のカーネル) に使用されているスケジューラからインスパイアされました。CachyOS からのパッチセットにより利用可能。
- Project C — BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。
- CacULE — CacULE CPU スケジューラは、interactivity score メカニズムに基づく CFS パッチセットです。Interactivity score は ULE スケジューラ (FreeBSD スケジューラ) にインスパイアされました。このパッチの目標は、システムのレスポンス/レイテンシを強化することです。
- TT — Task Type (TT) スケジューラの目標は、動作に基づいてタスクの種類を検出し、その種類に基づいてスケジューリングを制御することです。
- BORE — BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。
リアルタイムカーネル
(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、リアルタイムカーネルを使うと利益を得られる場合があります。
プロセスの優先順位を設定
nice(1) と renice(1) も参照してください。
Ananicy
Ananicy は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、ananicy-gitAUR や ananicy-cppAUR パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときの実行可能ファイルの優先度を表すものです。
cgroups
cgroups を見てください。
Cpulimit
Cpulimit は特定のプロセスの CPU 使用率を制限するプログラムです。cpulimit をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:
$ cpulimit -l 50 -p 5081
irqbalance
irqbalance はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。irqbalance.service で操作することが可能です。
CPU の脆弱性の緩和をオフにする
CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下のカーネルパラメータですべての緩和策が無効になります:
mitigations=off
このパラメータによって切り替えられるすべてのスイッチについての説明は、kernel.org で見られます。spectre-meltdown-checkerAUR や lscpu(1) (util-linux に同梱) を使うことで、脆弱性チェックを行うことができます。
グラフィック
Xorg の設定
グラフィックパフォーマンスは xorg.conf(5) の設定に依存している場合があります。NVIDIA、ATI、AMDGPU、Intel の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。
Mesa の設定
Mesa ドライバのパフォーマンスは drirc で設定できます。GUI の設定ツールもあります:
- adriconf (Advanced DRI Configurator) — オプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツール。
- DRIconf — Direct Rendering Infrastructure の設定アプレット。OpenGL ドライバのパフォーマンスや視覚クオリティ設定をドライバ毎、スクリーン毎、プリケーション毎レベルでカスタマイズできます。
ハードウェアビデオアクセラレーション
ハードウェアビデオアクセラレーションにより、ビデオカードに動画のデコード/エンコードをさせることができます。
オーバークロック
CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: rovclockAUR (ATI カード)、rocm-smi-lib (最近の AMD カード)、nvclockAUR (古い NVIDIA カード - Geforce 9 まで)、nvidia-utils (最近の NVIDIA カード)。
AMDGPU#オーバークロック や NVIDIA/ヒントとテクニック#オーバークロックを有効化する を参照してください。
PCI Resizable BAR を有効化する
PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい基底アドレスレジスタ (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は AMD Smart Access Memory と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。
BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=256M
有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=8192M
RAM、スワップ、OOM 処理
クロック周波数とタイミング
RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。#オーバークロックを参照。
RAM オーバーレイ上に root を置く
書き込みが遅いメディア (USB や 回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。liverootAUR を見て下さい。
Zram または zswap
zswap や zram を使うことで、同様の利点を (同様のコストで) 得られます。これら2つは一般に意図が似ていますが、操作が異なります。zswap は、圧縮 RAM キャッシュとして機能し、高コストなユーザ空間の設定を要求しません (そして、許可もしません)。zram は、RAM 内に圧縮ブロックデバイスを作成するために使用できるカーネルモジュールです。zswap はスワップデバイスと組み合わさって機能するのに対し、zram は補助スワップデバイスを必要としません。
グラフィックカードの RAM を使う
稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。ビデオメモリにスワップ を参照してください。
メモリ不足の状況におけるシステムのレスポンスを改善する
従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の OOM killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。
カーネルとFedora のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや vm.overcommit_* sysctl パラメータの調整よりも実行可能で効果的なオプションを使うことができます:
- Magic SysRq キー (
Alt+SysRq+f) で手動でカーネルの OOM killer をトリガーする。 - ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。
カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:
- systemd-oomd — systemd によって
systemd-oomd.serviceとして提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。
- earlyoom — C で書かれた、シンプルなユーザ空間の OOM killer 実装です。
- oomd — PSI ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。
- nohang — Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。
- low-memory-monitor — GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。
- uresourced — アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。
ネットワーク
- カーネルネットワーキング: Sysctl#パフォーマンスを向上させる を参照
- NIC: ネットワーク設定#MTU とキューの長さの設定 を参照
- DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。ドメイン名前解決#DNS サーバ を参照
- Samba: Samba#Improve throughput を参照
Watchdog
- ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。
システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。
(ソフトウェアとハードウェア両方の) ウォッチドッグタイマーを無効化するには、ブートパラメータに nowatchdog を追加してください。
AMD Ryzen CPU を使用している場合、journal で sp5100-tco も確認してください。これは AMD 700 チップセットシリーズ内部のハードウェア watchdog です。これを無効化するには、以下を作成してください:
/etc/modprobe.d/disable-sp5100-watchdog.conf
blacklist sp5100_tco
あるいは、modprobe.blacklist=sp5100_tco カーネルパラメータを使用してください。
cat /proc/sys/kernel/watchdog か wdctl で新しい設定が機能していることを確認してください。
ロードされるモジュールが減ることで起動やシャットダウンが高速化されます。さらに、ウォッチドッグを無効にするとパフォーマンスが向上し、消費電力も抑えられます。
詳しくは [1]、[2]、[3]、[4] を参照してください。