パフォーマンスの向上

関連記事

• パフォーマンスの向上/ブートプロセス
• Pacman ヒント#パフォーマンス
• OpenSSH#SSH の高速化
• OpenOffice#OpenOffice の高速化
• ノートパソコン
• Preload

この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは ゲーム#パフォーマンスを向上させる も参照してください。

基本

システムを知る

システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。

• (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください:

  $ free -h

• 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには hdparm コマンドを使うことができます:

  # hdparm -t /dev/sdX

  ノート: hdparm で出力されるのはハードドライブの純粋な読み込み速度なので、有効なベンチマークとは言えませんが、平均的なコンピュータでは (アイドル状態のときに) 40MB/s より高い数値が出るのが妥当です。
• 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要なデーモンやプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。htop や pstree などのシステム監視ツールで CPU 負担をモニタすることができます:

  $ htop

• ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、ウィンドウマネージャなどの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。glxinfo コマンドを使うことで確認できます (mesa-utils パッケージに含まれています)。次のコマンドを実行すると direct rendering: Yes と表示される必要があります:

  $ glxinfo | grep "direct rendering"

• デスクトップ環境を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、カスタムの環境を作成しましょう。
• 最適化されたカーネルを使用することでパフォーマンスを向上できます。一般に linux-zen が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。

ベンチマーク

最適化の効果を判断できないことがたびたびあります。そういった場合はベンチマークツールで計測することができます。

ストレージデバイス

パーティショニング

パーティションが適切にアライメントされていることを確認してください。

複数のドライブ

複数のドライブを持っているのであれば、ソフトウェア RAID を組んでパフォーマンスを劇的に向上させることができます。

スワップを別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。

HDD でのレイアウト

従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム (/) から home ディレクトリ (/home) を分割することでこれを達成できます。

ノート: このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブをショートストロークしたり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。

ファイルシステムの選択とチューニング

ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。ファイルシステムの記事に人気のあるファイルシステムの簡単な説明がされています。カテゴリ:ファイルシステムから関連記事も見ることができます。

マウントオプション

様々な *atime オプションが、strictatime のパフォーマンスのペナルティを軽減することができます。

他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:

• 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 スケジューラの機能を改良して取り入れています。anticipatory と elevator スケジューラは Linux カーネルから外され、下記のより高度な代替スケジューラに置き換えられました。

Budget Fair Queuing (BFQ) は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。これにより、ハードドライブにおいてアプリケーションの起動を劇的に加速化させられる場合があります。

Kyber はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。

カーネルの I/O スケジューラ

初期のアルゴリズムには既にメインラインから外されているものもあります。公式 Linux カーネルがサポートしている I/O スケジューラは以下の2つのカテゴリに分けることができます:

• マルチキュースケジューラはカーネルでデフォルトで利用できます。Multi-Queue Block I/O Queuing Mechanism (blk-mq) は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:
  • None、キューイングアルゴリズムは適用されません。
  • mq-deadline は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
  • Kyber
  • BFQ

• シングルキュースケジューラはレガシーなスケジューラです:
  • NOOP は最も単純なスケジューラです。全ての I/O リクエストをシンプルな FIFO キューに入れてリクエストをまとめます。NOOP アルゴリズムでは、セクタ番号によってリクエストの順番を変えることがありません。したがって、デバイスレベルで順位付けを行っている場合や SSD など順位付けが意味をなさない場合は NOOP を使用します。
  • Deadline
  • CFQ

ノート: シングルキュースケジューラは Linux 5.0 以降カーネルから削除されました

I/O スケジューラの変更

ノート: スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。 また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 ベンチマーク は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。

特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中):

$ cat /sys/block/sda/queue/scheduler

mq-deadline kyber [bfq] none

全デバイスで利用可能なスケジューラを表示するには:

$ grep "" /sys/block/*/queue/scheduler

/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none

デバイス sda のアクティブな I/O スケジューラを bfq に変更するには:

# echo bfq > /sys/block/sda/queue/scheduler

I/O スケジューラの変更プロセスは、ディスクが回転式か否かに応じて自動化することができ、起動毎に永続化させることができます。例えば、以下の udev ルールは、回転ドライブに対しては bfq を、SSD/eMMC ドライブに対しては bfq を、NVMe に対しては none を設定します:

/etc/udev/rules.d/60-ioschedulers.rules

# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

# NVMe SSD
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

再起動するか、強制的に新しいルールをロードしてください。

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 ルール を作成することができます。

ヒント: GNOME では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。

ノート: 一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。

ディスクの読み書きを減らす

遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。

ノート: 書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、毎日 10GB のデータ書き込みを行うと、8年間で寿命が尽きるとされます。この数字はもっと容量が大きい SSD を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときはこの耐久実験も参照してください。

ディスクの書き込みを表示する

iotop パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは iotop(8) を見てください。

ファイルを tmpfs に再配置する

ブラウザプロファイルなどのファイルを tmpfs ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:

• ブラウザプロファイルを同期させる方法については Profile-sync-daemon を参照してください。特定のブラウザには注意が必要な場合があります。例えば Firefox Ramdisk を参照してください。
• 任意の指定されたフォルダを同期させる方法については Anything-sync-daemon を参照してください。
• tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については Makepkg#ビルド時間を短縮する を参照してください。

ファイルシステム

対応するファイルシステムページを参照して、パフォーマンス改善に関する指示があるか見てください。#ファイルシステムの選択とチューニング に挙げられているファイルシステムのリストも参照してください。

スワップ領域

スワップ#パフォーマンス を見てください。

ライトバックの間隔とバッファサイズ

詳細は Sysctl#仮想メモリ を見てください。

コアダンプを無効化する

コアダンプ#自動的なコアダンプの無効化 を見てください。

ionice によるストレージ I/O スケジューリング

バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ CFQ を使用することで実現できます。

以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:

# ionice -c 3 command

詳細は a short introduction to ionice や ionice(1) を参照してください。

トリム

最適なパフォーマンスを得るには、SSD を定期的にトリムしてランダム書き込みの速度を最適化するべきです。詳細は ソリッドステートドライブ#TRIM を参照してください。

CPU

オーバークロック

オーバークロックは、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。

Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、dmesg は極端なメッセージを表示します (これは、acpi_cpufreq カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、i7z パッケージの i7z を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、ストレステストが推奨されます。

周波数スケーリング

CPU 周波数スケーリングを見てください。

CPU スケジューラ

メインライン Linux カーネルのデフォルトの CPU スケジューラは EEVDF です。

• MuQSS — Multiple Queue Skiplist Scheduler。Con Kolivas によって開発されている -ck パッチセットにより利用可能。

非公式ユーザーリポジトリ/Repo-ck || linux-ck^AUR

• Project C — BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。

https://cchalpha.blogspot.com/ || linux-prjc^AUR

• BORE — BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。

https://github.com/firelzrd/bore-scheduler || linux-cachyos-bore^AUR

リアルタイムカーネル

(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、リアルタイムカーネルを使うと利益を得られる場合があります。

プロセスの優先順位を設定

nice(1) と renice(1) も参照してください。

Ananicy

Ananicy CPP は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、ananicy-cpp^AUR や ananicy-cpp-git^AUR パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。

警告: Gamemode と Ananicy CPP はどちらもプロセスの nice レベルを調整しようとします。これらのツールを組み合わせて使用することは推奨されていません。[1]

cgroups

cgroups を見てください。

Cpulimit

Cpulimit は特定のプロセスの CPU 使用率を制限するプログラムです。cpulimit^AUR をインストールすれば、プロセスの 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-checker^AUR や lscpu(1) (util-linux に同梱) を使うことで、脆弱性チェックを行うことができます。

ノート: 第10世代およびそれ以降の Intel CPU、または AMD Ryzen シリーズ 1000 およびそれ以降の CPU を使用している場合、緩和策を無効化することにより得られるパフォーマンスの向上は、最大でも 5% にとどまります。一方、それ以前の世代の CPU では、最大 25% まで向上します。2021 初頭における総評、Rocket Lake におけるテスト、Alder Lake におけるテスト を参照。

グラフィック

Xorg の設定

グラフィックパフォーマンスは xorg.conf(5) の設定に依存している場合があります。NVIDIA、AMDGPU、Intel の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。

Mesa の設定

Mesa ドライバのパフォーマンスは drirc で設定できます。adriconf (Advanced DRI Configurator) はオプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツールです。

ハードウェアビデオアクセラレーション

ハードウェアビデオアクセラレーションにより、ビデオカードに動画のデコード/エンコードをさせることができます。

オーバークロック

CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: rovclock^AUR (ATI カード)、rocm-smi-lib (最近の AMD カード)、nvclock^AUR (古い NVIDIA カード - Geforce 9 まで)、nvidia-utils (最近の NVIDIA カード)。

AMDGPU#オーバークロック や NVIDIA/ヒントとテクニック#オーバークロックを有効化する を参照してください。

PCI resizable BAR を有効化する

ノート:

• 一部のシステムでは、PCI resizable BAR を有効化するとパフォーマンスが大幅に劣化する可能性があります。システムのベンチマークを行って、PCI resizable BAR がパフォーマンスを向上させていることを確認してください。
• 効果を発揮させるには、Compatibility Support Module (CSM) を無効化しなければなりません。

PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい基底アドレスレジスタ (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は AMD Smart Access Memory^{[リンク切れ 2024-07-30]} と呼んでおり、初期は 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 に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。liveroot^AUR を見て下さい。

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 をトリガーして実行中のアプリケーションを kill すると、保存されていない作業が失われる場合があります。アプリケーションが最終的に通常通りメモリを開放してくれることを期待して辛抱強く待つか、あるいは応答がないシステムを可能な限り早く通常に戻したいと望むかは、あなた次第です。

カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:

• systemd-oomd — systemd によって systemd-oomd.service として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。

https://github.com/systemd/systemd, systemd-oomd(8) || systemd

• earlyoom — C で書かれた、シンプルなユーザ空間の OOM killer 実装です。

https://github.com/rfjakob/earlyoom || earlyoom

• oomd — PSI ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。

https://github.com/facebookincubator/oomd || oomd^AUR

• nohang — Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。

https://github.com/hakavlad/nohang || nohang-git^AUR

• low-memory-monitor — GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。

https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-git^AUR

• uresourced — アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。

https://gitlab.freedesktop.org/benzea/uresourced || uresourced^AUR

ネットワーク

• カーネルネットワーキング: Sysctl#パフォーマンスを向上させる を参照
• NIC: ネットワーク設定#MTU とキューの長さの設定 を参照
• DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。ドメイン名前解決#DNS サーバ を参照
• Samba: Samba#スループットを向上させる を参照

ウォッチドッグ

wikipedia:ja:ウォッチドッグタイマーより:

ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。

システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。

(ソフトウェアとハードウェア両方の) ウォッチドッグタイマーを無効化するには、ブートパラメータに nowatchdog を追加してください。

nowatchdog ブートパラメータは Intel TCO ハードウェアウォッチドッグに対しては機能しない場合があります。[2] そのような場合、modprobe.blacklist=iTCO_wdt カーネルパラメータを使って TCO のカーネルモジュールを無効化することができます。

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 で新しい設定が機能していることを確認してください。

ロードされるモジュールが減ることで起動やシャットダウンが高速化されます。さらに、ウォッチドッグを無効にするとパフォーマンスが向上し、消費電力も抑えられます。

詳しくは [3]、[4]、[5]、[6] を参照してください。

参照

• Red Hat Performance Tuning Guide
• Linux Performance Measurements using vmstat

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