「パフォーマンスの向上」の版間の差分

削除された内容追加された内容

インライン

2025年8月15日 (金) 17:12時点における最新版

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

基本

システムを知る

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

(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 が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。

ベンチマーク

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

ストレージデバイス

セクタサイズ

NVMe ドライブや Advanced Format ハードディスクが適切な論理セクタサイズを使用していることを確認してください。

パーティショニング

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

複数のドライブ

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

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

SSD を HDD のキャッシュとして使う

ハードディスクから移行することができない場合、ソリッドステートドライブをキャッシュレイヤとして使うことで読み書き速度を向上させ、ランダムアクセスによるパフォーマンスの低下を減らすことができます。方法としては、LVM#キャッシュ、Bcache、Bcachefs#SSD キャッシングがあります。

HDD でのレイアウト

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

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

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

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

マウントオプション

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

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

カーネルパラメータの調整

ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは 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 スケジューラをサポートしています。Multi-Queue Block I/O Queuing Mechanism (blk-mq) は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:

None、キューイングアルゴリズムは適用されません。
mq-deadline は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
Kyber
BFQ

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 スケジューラ BFQ を使用することで実現できます。

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

$ ionice -c 3 command

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

トリム

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

ネットワーク

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

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

SCX — システムをリセットせずに様々な CPU スケジューラを動的にロードできるようにします。

https://github.com/sched-ext/scx || scx-scheds

リアルタイムカーネル

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

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

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

Ananicy

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

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

cgroups

cgroups を見てください。

LimitCPU

LimitCPU は特定のプロセスの CPU 使用率を制限するプログラムです。limitcpu^AUR をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:

$ limitcpu -l 50 -p 5081

irqbalance

irqbalance はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。irqbalance.service で操作することが可能です。

警告一部のケースでは、irqbalance が省電力機能に干渉し、ビデオゲームでのスタッタリングやフレームレート低下を引き起こす可能性があります。[2]

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/ヒントとテクニック#オーバークロックを有効化するを参照してください。

PCIe resizable BAR を有効化する

ノート

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

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 を置く

この記事またはセクションは情報が古くなっています。

理由: liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。 (Discuss)

書き込みが遅いメディア (USB や回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。liveroot^AUR を見て下さい。

zram 内のスワップや zswap

zswap や zram 内のスワップを使うことで、似たような利点を (同じくらいのコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります:

zswap は、圧縮された RAM キャッシュとして動作し、ユーザ空間の設定をあまり必要としません (と同時に許可もしていません)。スワップデバイスと組み合わせて、スワップのキャッシュとして動作します。スワップに入りそうなページは、代わりに zswap に入る可能性があります。

zram は、RAM 内に圧縮されたブロックデバイスを作成できるカーネルモジュールです。この圧縮されたブロックデバイスはスワップデバイスとして使用でき、他のスワップデバイスと組み合わせる必要はありません。多くの設定オプションがあり、例えばコールドページを保持しておくバッキングデバイスを使用するかどうかも指定できます。

両方ともスワップサブシステムを呼び出すため、スワップに影響を与える設定はこれらのシステムにも影響を与えます。例えば、swappiness は、メモリが圧迫している状況で、カーネルがファイルキャッシュをドロップするか、ページをスワップに移動させるかのどちらを優先させるかを指定します。Zswap はページのスワップへの移動動作をインターセプトし、zram もスワップとして動作するため、このオプションはこれら2つのメカニズムがどれくらいの頻度で使用されるかにも影響を与えます。

グラフィックカードの RAM を使う

稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。ビデオメモリにスワップを参照してください。

メモリ不足の状況におけるシステムのレスポンスを改善する

従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の out-of-memory (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

ウォッチドッグ

Wikipedia:Watchdog timer (日本語版) より:

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

よって、ウォッチドッグは例外的な状況でカーネルの回復を最適化するために使用されています。もし、重要なシステムサービス (例: ネットワーク、ファイルシステム、ACPI、systemd) が応答しなくなった場合、ウォッチドッグはそれを検知し、再起動をトリガーします。それにより、システムがロックアップし、応答しなくなったサービスのせいで長い遅延が発生してしまうことを回避できます。#メモリ不足の状況におけるシステムのレスポンスを改善するで説明されているように、この緊急メカニズムとランタイムのシステムリソース管理とを区別することは重要です。

systemd ウォッチドッグ

systemd にはウォッチドッグのリセット機構が内蔵されています。これは、適切なカーネルモジュールがロードされている場合に (以下を参照)、/dev/watchdog として公開されているハードウェアウォッチドッグと対話します。システムが応答しなくなった場合、ハードウェアウォッチドッグがシステムリセットをトリガーします。

systemd でウォッチドッグを設定する

デフォルトでは、RuntimeWatchdogSec は無効化されています。システムのウォッチドッグを有効化するには、以下のような systemd-system.conf(5) ドロップインファイルを作成してください:

/etc/systemd/system.conf.d/watchdog.conf

[Manager]
RuntimeWatchdogSec=10s
RebootWatchdogSec=45s

RuntimeWatchdogSec=10s: systemd が 10 秒より長く応答しなかった場合、システムを再起動します。
RebootWatchdogSec=45s: システムが再起動中にハングした場合、ウォッチドッグは 45 秒後にリセットを強制します。

以下のコマンドで適用します:

# systemctl daemon-reexec

ウォッチドッグがアクティブであることを確認してください:

$ systemctl show | grep Watchdog

RuntimeWatchdogUSec=10s
RebootWatchdogUSec=45s

ハードウェアのウォッチドッグサポートを確認する

多くのシステムで、ハードウェアウォッチドッグのサポートは異なるカーネルモジュール (例: 一部の Intel チップセットでは iTCO_wdt、特定の AMD プラットフォームでは sp5100_tco) によって提供されている場合があります。ハードウェアウォッチドッグのモジュールを確認するには、以下を実行してください:

$ lsmod | grep wdt

関連するウォッチドッグモジュール (例: iTCO_wdt、sp5100_tco) を見つけたら、以下のようなファイルを作成してモジュールがブート時にロードされるようにしてください:

/etc/modules-load.d/watchdog.conf

module_name

# modprobe module_name

module_name の部分は、あなたのハードウェアにおける実際のモジュール名に置き換えてください。

リファレンス

参照

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