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

2024年3月28日 (木) 09:39時点における最新版

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

基本

システムを知る

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

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

ベンチマーク

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

ストレージデバイス

複数のハードウェアパス

内部ハードウェアパスは、ストレージデバイスがマザーボードを介してどのように接続されているかを表します。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) を分割することでこれを達成できます。

ノート: このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブをショートストロークしたり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、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 スケジューラは以下の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#ビルド時間を短縮するを参照してください。

ファイルシステム

対応するファイルシステムページを参照して、パフォーマンス改善に関する指示があるか見てください。例: 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

詳細は 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

PDS — デスクトップのレスポンスに焦点を当てている、優先度 (Priority) とデッドライン (Deadline) をベースとした Skiplist 複数キュースケジューラ。

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

BMQ — BMQ "BitMap Queue" スケジューラは、既存の PDS 開発経験を元に作成され、Google の Zircon (Fuchsia OS イニシアチブ内のカーネル) に使用されているスケジューラからインスパイアされました。CachyOS からのパッチセットにより利用可能。

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

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

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

TT — Task Type (TT) スケジューラの目標は、動作に基づいてタスクの種類を検出し、その種類に基づいてスケジューリングを制御することです。

https://github.com/hamadmarri/TT-CPU-Scheduler || linux-tt^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 は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、ananicy-git^AUR や ananicy-cpp^AUR パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときの実行可能ファイルの優先度を表すものです。

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 で設定できます。GUI の設定ツールもあります:

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

https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf

DRIconf — Direct Rendering Infrastructure の設定アプレット。OpenGL ドライバのパフォーマンスや視覚クオリティ設定をドライバ毎、スクリーン毎、プリケーション毎レベルでカスタマイズできます。

https://dri.freedesktop.org/wiki/DriConf/ || driconf^AUR

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

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

オーバークロック

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 と呼んでおり、初期は 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 キャッシュとして機能し、高コストなユーザ空間の設定を要求しません (そして、許可もしません)。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 ハードウェアウォッチドッグに対しては機能しない場合があります。[1] そのような場合、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 で新しい設定が機能していることを確認してください。

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

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

参照

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

@@ 1行目: / 1行目: @@
 [[Category:ハードウェア]]
 [[Category:システム管理]]
-[[ar:Maximizing performance]]
 [[en:Improving performance]]
 [[es:Improving performance]]
+[[fr:Improving performance]]
+[[pl:Improving performance]]
+[[pt:Improving performance]]
 [[ru:Improving performance]]
-[[zh-hans:Maximizing performance]]
+[[zh-hans:Improving performance]]
 {{Related articles start}}
+{{Related|パフォーマンスの向上/ブートプロセス}}
-{{Related|ccache}}
-{{Related|pacman のパフォーマンスの向上}}
+{{Related|Pacman ヒント#パフォーマンス}}
-{{Related|SSH#SSH の高速化}}
+{{Related|OpenSSH#SSH の高速化}}
-{{Related|LibreOffice#LibreOffice の高速化}}
 {{Related|OpenOffice#OpenOffice の高速化}}
 {{Related|ノートパソコン}}
-{{Related|スワップ#Swappiness}}
 {{Related|Preload}}
-{{Related|Cpulimit}}
-{{Related|ブートパフォーマンスの向上}}
 {{Related articles end}}
-この記事ではパフォーマンスに関する基本的なシステムの診断法と、リソースの消費を減らしたりシステムを最適化することができる、また、システムのパフォーマンスを向上させると言われている手順の情報を提供しています。
+この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは [[ゲーム#パフォーマンスを向上させる]] も参照してください。
-==基本==
+== 基本 ==
-===システムを知る===
-システムをチューンするには、まず全体のスピードを下げているボトルネックのサブシステムを見つける必要があります。普通システムの仕様を知ることで特定することができますが、目に見える兆候もあります:
+=== システムを知る ===
-* [[LibreOffice]] や [[Firefox]] などの巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の量が十分でないのかもしれません。利用できる RAM の量を知るには、以下のコマンドを使い、"available" カラムをチェックしてください:
- $ free -h
+システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。
-* 起動時間が非常に長い場合、または、アプリケーションを初めて起動するときにロードに長い時間がかかるが起動後は順調に動作する場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには {{ic|hdparm}} コマンドを使います:
- # hdparm -t /dev/sdX
+* (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください: {{bc|$ free -h}}
-{{Note|hdparm で出力されるのはハードドライブの純粋な読み込み速度なので、正しいベンチマークとは言えませんが、（アイドル状態のときにドライブをテストして）平均的なコンピュータでは 40MB/s より高い数値が出るのが普通だと思われます。}}
+* 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには {{ic|hdparm}} コマンドを使うことができます: {{bc|# hdparm -t /dev/sd''X''}} {{Note|{{Pkg|hdparm}} で出力されるのはハードドライブの純粋な読み込み速度なので、有効なベンチマークとは言えませんが、平均的なコンピュータでは (アイドル状態のときに) 40MB/s より高い数値が出るのが妥当です。}}
+* 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要な[[デーモン]]やプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。{{Pkg|htop}} や {{ic|pstree}} などの[[アプリケーション一覧/ユーティリティ#システム監視|システム監視ツール]]で CPU 負担をモニタすることができます: {{bc|$ htop}}
+* ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、[[ウィンドウマネージャ]]などの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。{{ic|glxinfo}} コマンドを使うことで確認できます ({{Pkg|mesa-utils}} パッケージに含まれています)。次のコマンドを実行すると {{ic|direct rendering: Yes}} と表示される必要があります: {{bc|$ glxinfo {{!}} grep "direct rendering"}}
+* [[デスクトップ環境]]を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、[[デスクトップ環境#カスタム環境|カスタムの環境]]を作成しましょう。
+* 最適化された[[カーネル]]を使用することでパフォーマンスを向上できます。一般に {{Pkg|linux-zen}} が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。
+=== ベンチマーク ===
-* RAM が利用できる時でも CPU 負担が一貫して高い場合、不要な[[デーモン]]を無効化するなどして CPU 使用量を減らすことが優先事項でしょう。{{Pkg|htop}} や {{ic|pstree}} などの[[アプリケーション一覧/ユーティリティ#システム監視|システム監視ツール]]で CPU 負担をモニタすることができます:
- $ htop
+最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。
-* ダイレクトレンダリングを使うアプリケーション、つまりビデオプレーヤーやゲームなどグラフィックカードを使うアプリケーションにラグが生じる場合、グラフィックパフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。{{ic|glxinfo}} コマンドを使います ({{ic|glxinfo}} は {{Pkg|mesa-demos}} パッケージに含まれています):
-{{hc|<nowiki>$ glxinfo | grep direct</nowiki>|
-direct rendering: Yes
-}}
+== ストレージデバイス ==
-パフォーマンスを向上させるのに、一番簡単で最も効果的な方法は軽量な環境・アプリケーションを動かすことです:
-* [[デスクトップ環境]]の代わりに[[ウィンドウマネージャ]]を使いましょう。[[dwm]], [[wmii]], [[i3]], [[Awesome]], [[Openbox]], [[Fluxbox]], [[JWM]], [[xmonad]] などがあります。
-* 重量級のデスクトップ環境、[[GNOME]] や [[KDE]] の代わりに、[[LXDE]] や [[Xfce]] などの軽量な環境を使いましょう。
-* 軽量なアプリケーションを使いましょう。[[アプリケーション一覧]]でコンソールアプリケーションを探したり、依存ライブラリが少ないアプリケーションを探してみてください。
+=== 複数のハードウェアパス ===
-===妥協===
-ほとんど全てのチューニングには代償が伴います。軽量なアプリケーションは一般的に機能が少ないですし、調整がシステムを不安定にすることもあります。また、実行と管理に時間が必要になるでしょう。このページではそうした欠点もできるだけ触れますが、最終的に決定を下すのはユーザーです。
+内部ハードウェアパスは、ストレージデバイスがマザーボードを介してどのように接続されているかを表します。NIC、PCIe、Firewire、Raid カード、USB など、マザーボードを介する接続方法は複数あります。ストレージデバイスを複数の接続点に分けることで、ボトルネックを回避できます。なぜなら、マザーボードに入る「エントリーパス」は「パイプ」のようなもので、そのパイプを一度に通ることのできる量には制限があるからです。通常、マザーボードには複数の「パイプ」が存在するため、これは回避できます。
-===ベンチマーク===
-最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。
+これの具体例としては、マシン前面に2つの USB ポート、背面に4つの USB ポートがあり、4つのディスクを接続したい場合です。通常、3つのディスクを背面に接続し、残り1つを前面に接続するよりも、2つを前面に接続し、別の2つを背面に接続する方が高速です。これは、ほとんどの場合、前面と背面のポートは内部的に別の Root USB Hub に接続されていて、片方ではなく両方を使用することで同時に送信できるデータが増えるからです。
-==ストレージデバイス==
-===デバイスレイアウト===
-パフォーマンスを一番大きく向上させるもののひとつが、オペレーティングシステムが動くレイアウトを複数のデバイスで作ることです。{{ic|/}} {{ic|/home}} {{ic|/var}} {{ic|/usr}} を異なるディスクに置くと、全てを同じハードドライブに置く、シングルディスクレイアウトに比べて劇的に速くなります。
+次のコマンドは、マシンの様々なパスを特性するのに役立ちます。
-====スワップファイル====
-スワップファイルを分割したディスクに作成するのも、特にマシンがスワップを頻繁に使う場合、多くの利益があります。利用したい環境に十分な量の RAM がない場合によく使われます。多くの機能とアプリケーションを装備した KDE を使うには数 GiB のメモリが必要になりますが、小さなウィンドウマネージャとコンソールアプリケーションなら 512 MiB メモリ以下でも完全に適合します。
+{{hc|USB デバイスツリー|$ lsusb -t}}
-====RAID====
-（２つ以上の）複数のディスクを使える場合、ソフトウェア [[RAID]] を設定することでスピードを向上させることが可能です。RAID 0 アレイではドライブ障害に対する冗長性はありませんが、アレイにディスクを追加すればそれだけディスクの速度を高速にできます。賢い選択は RAID 5 を使うことです、RAID 5 はスピードとデータ保護の両方を提供します。
+{{hc|PCI デバイスツリー|$ lspci -tv}}
-====ハードウェアの接続端子====
-内部ハードウェア端子によってストレージデバイスはマザーボードに接続されます。NIC を通る TCP/IP のように、マザーボードに接続する方法は複数あり、PCIe/PCI を使って直接つなぐ、Firewire、Raid カード、USB、などがあります。ストレージデバイスをこれらの複数の接続端子を使うようにすることで、マザーボードを最大限に使うことできます。例えば、6つのハードドライブを接続するのに全部 USB を使うのは、3つずつ USB と Firewire を使いわけるのよりも、ずっとずっと遅くなります。なぜならば、マザーボードに接続する各々の端子はパイプのようになっており、そのパイプを一度に通過できる量はセットで制限されているからです。吉報は、マザーボードには一般的に複数のパイプがあるということです。
+=== パーティショニング ===
-その他の例
-# pci/PCIe/ata を使って直接マザーボードに接続
-# 外部容器を使ってディスクを USB/Firewire を通して収納する
-# tcp/ip で接続してデバイスをネットワークストレージデバイスに変える
+パーティションが[[パーティショニング#パーティションアライメント|適切にアライメントされている]]ことを確認してください。
-また、あなたがマシンのフロントに2つの USB 端子、バックに4つの USB 端子、そして4つのディスクを持っている場合、おそらく一番速くなる構成は、フロント2/バック2もしくはフロント1/バック3です。フロントの端子はバックとは異なり、分割されたルートハブのようになっているため、2倍のデータを送ることができるのです。以下のコマンドを使うことでマシンにある様々な接続経路を確認できます。
+==== 複数のドライブ ====
-{{hc|USB デバイスツリー|$ lsusb -tv}}
+複数のドライブを持っているのであれば、ソフトウェア [[RAID]] を組んでパフォーマンスを劇的に向上させることができます。
-{{hc|PCI デバイスツリー|$ lspci -tv}}
+[[スワップ]]を別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。
-===パーティション===
-パーティションレイアウトもシステムのパフォーマンスに影響を与えることがあります。ドライブの最初のセクター（ディスクの周辺部）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さくして、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は分割パーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home/''user''}}) を分割することでこれを達成できます。
+==== HDD でのレイアウト ====
-===ファイルシステムの選択とチューニング===
-ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:カテゴリ:ファイルシステム|ここ]]から関連記事も見ることができます。
+従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home}}) を分割することでこれを達成できます。
-====マウントオプション====
-マウントオプションを使えばフォーマットする必要なく簡単にスピードを改善できます。マウントコマンドを使うときにマウントオプションを設定できます:
- $ mount -o option1,option2 /dev/partition /mnt/partition
-永続的に設定するには、{{ic|/etc/fstab}} を編集して対象の行を次のようにしてください:
- /dev/partition /mnt/partition partitiontype option1,option2 0 0
-{{Ic|noatime,nodiratime}} マウントオプションはほとんど全てのファイルシステムでパフォーマンスを向上させることができるとして知られています。前者は後者の上位版です ({{Ic|nodiratime}} はディレクトリにだけ適用されます -- {{Ic|noatime}} はファイルとディレクトリ両方に適用されます)。レアケースで、例えば、あなたが ''mutt'' を使っている場合など、小さな問題が起こることがあります。代わりに {{Ic|relatime}} オプションを使うこともできます (カーネル 2.6.30 以上ではデフォルトです)。
+{{Note|このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブを[https://blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/#shortstroke ショートストローク]したり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。}}
-特定のファイルシステムにしかないマウントオプションも存在します。それぞれのファイルシステムのページを見て下さい:
+=== ファイルシステムの選択とチューニング ===
-* [[Ext3]]
-* [[Ext4#ヒントとテクニック‎]]
-* [[JFS#最適化]]
-* [[XFS]]
-* [[Btrfs#デフラグメンテーション]] と [[Btrfs#圧縮]]
-* [[ZFS#チューニング]]
+ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:カテゴリ:ファイルシステム]]から関連記事も見ることができます。
-===== Reiserfs =====
+==== マウントオプション ====
-{{Ic|<nowiki>data=writeback</nowiki>}} マウントオプションはスピードを向上させますが、電源喪失でデータが破損します。{{Ic|notail}} マウントオプションはファイルシステムが使う容量を 5% ほど増やしますが、全体的なスピードが向上します。ジャーナルとデータを分割してドライブに置くことで読み込み時間を減らすこともできます。これをするにはファイルシステムを作成する際に次のようにしてください:
+様々な [[fstab#atime オプション|*atime]] オプションが、{{ic|strictatime}} のパフォーマンスのペナルティを軽減することができます。
- # mkreiserfs –j /dev/sd'''a1''' /dev/sd'''b1'''
+他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:
-{{ic|/dev/sd''a1''}} をジャーナルとして使うパーティションに、{{ic|/dev/sd''b1''}} をデータ用のパーティションに置き換えてください。reiserfs について詳しくは [http://www.funtoo.org/Funtoo_Filesystem_Guide,_Part_2 この記事] を見て下さい。
+* [[Ext3]]
+* [[Ext4#パフォーマンスの向上]]
+* [[JFS#最適化]]
+* [[XFS#パフォーマンス]]
+* [[Btrfs#デフラグメンテーション]]、[[Btrfs#圧縮]]、{{man|5|btrfs}}
+* [[ZFS#チューニング]]
+* [[NTFS#パフォーマンスの向上]]
 ===カーネルパラメータの調整===
 ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。
 === I/O スケジューラの設定 ===
 ==== 背景情報 ====
 入出力 ''(I/O)'' スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:
-* HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます ''(IOPS)''。
+* HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスクコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます ''(IOPS)''。
 * SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。
@@ 123行目: / 104行目: @@
 スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えて出来るだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが [[w:ja:エレベータアルゴリズム|elevator]] スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。
-エレベーターアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータースケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。この問題を解決するために [[w:Anticipatory_scheduling|anticipatory]] IO スケジューラが追加されました。同期リクエストの場合、このアルゴリズムでは他のリクエストに移るまで数ミリ秒間待機します。
+エレベータアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータスケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。[[w:Anticipatory_scheduling|anticipatory]] IO スケジューラはこの問題を解決します。このスケジューラは、他のリクエストを処理する前に、近くで別の読み取り操作が発生することを予測して、数ミリ秒待機します。
-上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。
+上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターアルゴリズムと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。
-[[w:CFQ|Completely Fair Queuing ''(CFQ)'']] は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに [[cgroups]] のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという ''anticipatory'' スケジューラの機能を改良して取り入れています。より高度な CFQ スケジューラが導入されたことで ''anticipatory'' と ''elevator'' スケジューラは Linux カーネルから外されることになりました。
+[[w:CFQ|Completely Fair Queuing (CFQ)]] は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに [[cgroups]] のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという ''anticipatory'' スケジューラの機能を改良して取り入れています。''anticipatory'' と ''elevator'' スケジューラは Linux カーネルから外され、下記のより高度な代替スケジューラに置き換えられました。
-[https://algo.ing.unimo.it/people/paolo/disk_sched/ Budget Fair Queuing ''(BFQ)''] は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。
+[https://algo.ing.unimo.it/people/paolo/disk_sched/ Budget Fair Queuing (BFQ)] は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。これにより、ハードドライブにおいて[https://www.phoronix.com/review/linux-50hdd-io/2 アプリケーションの起動を劇的に加速化]させられる場合があります。
 [https://lwn.net/Articles/720675/ Kyber] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。
 ==== カーネルの I/O スケジューラ ====
 初期のアルゴリズムには既にメインラインから外されているものもあります。公式 Linux カーネルがサポートしている I/O スケジューラは以下の2つのカテゴリに分けることができます:
+*'''マルチキュースケジューラ'''はカーネルでデフォルトで利用できます。[https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) Multi-Queue Block I/O Queuing Mechanism (blk-mq)] は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:
-*'''シングルキュースケジューラ'''はデフォルトで使えるスケジューラです:
+**''None''、キューイングアルゴリズムは適用されません。
-**[[w:NOOP_scheduler|NOOP]] は最も単純なスケジューラです。全ての I/O リクエストをシンプルな FIFO キューに入れてリクエストをまとめます。NOOP アルゴリズムでは、セクタ番号によってリクエストの順番を変えることがありません。したがって、デバイスレベルで順位付けを行っている場合や SSD など順位付けが意味をなさない場合は NOOP を使用します。
+**''mq-deadline'' は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
-**''Deadline''
-**''CFQ''
-*'''マルチキュースケジューラ'''は [[#I/O スケジューラの変更]]で説明しているように起動時にモードを有効にして使うことができます。[https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) Multi-Queue Block I/O Queuing Mechanism ''(blk-mq)''] は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。blk-mq では以下のスケジューラが使えます:
-**''None'', キューイングアルゴリズムは適用されません。
-**''mq-deadline'' は deadline スケジューラをマルチスレッドに対応させたスケジューラです。
 **''Kyber''
 **''BFQ''
-:{{Warning|マルチキュースケジューラフレームワークとそのアルゴリズムは開発途上であり、問題がまだ残っている可能性があります [https://groups.google.com/forum/#!forum/bfq-iosched]。}}
+*'''シングルキュースケジューラ'''はレガシーなスケジューラです:
-{{Note|どのスケジューラが一番良いのかはデバイスとワークロードの性質によります。また、スループットだけではパフォーマンスを計測できません。デッドラインや公平性という概念を導入するとスループットが悪くなりますがシステムの反応性は改善します。}}
+**[[w:Noop scheduler|NOOP]] は最も単純なスケジューラです。全ての I/O リクエストをシンプルな FIFO キューに入れてリクエストをまとめます。NOOP アルゴリズムでは、セクタ番号によってリクエストの順番を変えることがありません。したがって、デバイスレベルで順位付けを行っている場合や SSD など順位付けが意味をなさない場合は NOOP を使用します。
+**[[w:Deadline scheduler|Deadline]]
+**[[w:CFQ|CFQ]]
+:{{Note|1=シングルキュースケジューラは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f382fb0bcef4c37dc049e9f6963e3baf204d815c Linux 5.0 以降カーネルから削除されました]}}
 ==== I/O スケジューラの変更 ====
-{{Note|最新の ''BFQ'' や ''Kyber'' スケジューラを使うには起動時にブロックマルチキュー ''(blk-mq)'' モードを有効にする必要があります。[[カーネルパラメータ]]に {{ic|1=scsi_mod.use_blk_mq=1}} を追加することで有効化できます。ブロックマルチキューモードではシングルキュースケジューラは使えなくなります。}}
+{{Note|スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。 また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 [[ベンチマーク]] は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。}}
-特定のデバイスで利用できるスケジューラと、現在使われているスケジューラを確認するには:
+特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中):
 {{hc|$ cat /sys/block/'''''sda'''''/queue/scheduler|
-mq-deadline kyber [bfq] none}}
-あるいは全てのデバイスでスケジューラを確認するには:
-{{hc|$ 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'' に変更するには、以下のコマンドを使用します:
+全デバイスで利用可能なスケジューラを表示するには:
+{{hc|$ 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'' を設定します:
-SSD は多数の IOPS を処理できるため、''noop'' や ''deadline'' などのシンプルなアルゴリズムが最適です。逆に HDD には ''BFQ'' が適しています。以下のように [[udev]] ルールを使うことで、ディスクが HDD か SSD かどうかで I/O スケジューラを自動的に変更して永続的に設定することが可能です:
-{{hc|/etc/udev/rules.d/60-ioschedulers.rules|2=
+{{hc|/etc/udev/rules.d/60-ioschedulers.rules|<nowiki>
+# HDD
-# set scheduler for non-rotating disks
-ACTION=="add{{!}}change", KERNEL=="sd[a-z]{{!}}mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
+ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
-# set scheduler for rotating disks
-ACTION=="add{{!}}change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
-}}
+# SSD
-ルールを保存したら、マシンを再起動するか、ルールを[[Udev#新しいルールをロードする|リロード]]してください。
+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"
+</nowiki>}}
+再起動するか、強制的に[[udev#新しいルールをロードする|新しいルールをロード]]してください。
 ==== IO スケジューラの調整 ====
-カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。設定項目と説明は [https://www.kernel.org/doc/Documentation/block/ カーネルドキュメントファイル] で確認できます。
+カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。
+設定項目と説明は [https://docs.kernel.org/block/index.html カーネルドキュメント] で確認できます。
 特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています):
 {{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched|
 fifo_batch  front_merges  read_expire  write_expire  writes_starved}}
@@ 186行目: / 182行目: @@
 {{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}}
-=== 電源管理の設定 ===
+=== 電源管理設定とライトキャッシュ ===
-伝統的な回転ディスク (HDD) を使用する場合は[[Hdparm#電源管理の設定|省電力機能を無効化]]することで性能の改善が見込めます。
+従来の回転ディスク (HDD) を使用する場合は、省電力機能を完全に無効にするか下げるかし、書き込みキャッシュが有効になっているかどうかを確認すると良いかもしれません。
+[[Hdparm#電源管理の設定]] と [[Hdparm#ライトキャッシュ]] を参照してください。
+後で、起動時にこれらを適用する [[Hdparm#udev ルールによる永続的な設定|udev ルール]] を作成することができます。
+{{Tip|[[GNOME]] では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。}}
+{{Note|一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。}}
 === ディスクの読み書きを減らす ===
@@ 193行目: / 198行目: @@
 遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。
-{{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、毎日 10GB のデータ書き込みを行うと、8年間で寿命が尽きるとされます。この数字はもっと容量が大きい SSD を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは [https://techreport.com/review/25889/the-ssd-endurance-experiment-500tb-update] を比較してください。}}
+{{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、'''毎日 10GB のデータ書き込みを行うと'''、'''8年間で寿命が尽きる'''とされます。この数字はもっと容量が大きい SSD を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは [https://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead/ この耐久実験] も参照してください。}}
 ==== ディスクの書き込みを表示する ====
@@ 201行目: / 206行目: @@
 ==== ファイルを tmpfs に再配置する ====
-ブラウザプロファイルなどのファイルを {{ic|/tmp}} や {{ic|/dev/shm}} などの [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:
+ブラウザプロファイルなどのファイルを [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:
-* ブラウザプロファイルの同期については [[Profile-sync-daemon]] を参照してください。Firefox を使っている場合は [[Firefox Ramdisk]] も参照。
+* ブラウザプロファイルを同期させる方法については [[Profile-sync-daemon]] を参照してください。特定のブラウザには注意が必要な場合があります。例えば [[Firefox Ramdisk]] を参照してください。
-* 特定のフォルダを同期する方法は [[Anything-sync-daemon]] を参照してください。
+* 任意の指定されたフォルダを同期させる方法については [[Anything-sync-daemon]] を参照してください。
+* tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については [[Makepkg#ビルド時間を短縮する]] を参照してください。
-==== tmpfs でコンパイルする ====
+==== ファイルシステム ====
+対応する[[ファイルシステム]]ページを参照して、パフォーマンス改善に関する指示があるか見てください。例: [[Ext4#パフォーマンスの向上]]、[[XFS#パフォーマンス]]。
-パッケージのビルド時にコンパイル時間を短縮する方法は [[Makepkg#コンパイル時間を短縮する]]を参照。
-==== ファイルシステムの最適化 ====
+==== スワップ領域 ====
+[[スワップ#パフォーマンス]] を見てください。
-[[ファイルシステム]]によってはパフォーマンスを改善する方法が存在することがあります。例: [[Ext4#ヒントとテクニック]]。
-==== スワップ領域 ====
+==== ライトバックの間隔とバッファサイズ ====
-[[スワップ#パフォーマンスチューニング]]を見てください。
+詳細は [[Sysctl#仮想メモリ]] を見てください。
+==== コアダンプを無効化する ====
+[[コアダンプ#自動的なコアダンプの無効化]] を見てください。
 === ionice によるストレージ I/O スケジューリング ===
-バックアップなどの作業ではストレージ I/O の遅延はさほど関係がなく I/O 帯域幅を最大限使う意味がありません。そのような作業はバックグラウンドタスクと分類することができます。一方でデスクトップでは UI のレスポンスを早くするために高速な I/O を必要とします。バックグラウンドタスクとしてのストレージ帯域幅を減らすことで、他のストレージ I/O を必要とするタスクが帯域幅を活用することが可能です。Linux の I/O スケジューラである CFQ では、プロセスによって優先度を別々に設定できます。
+バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ CFQ を使用することで実現できます。
-バックグラウンドプロセスの I/O 優先度を "Idle" レベルまで減らしてからプロセスを起動するには:
+以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:
  # ionice -c 3 command
-詳しくは {{man|1|ionice}} や [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html] を見てください。
+詳細は [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html a short introduction to ionice] や {{man|1|ionice}} を参照してください。
-==CPU==
+=== トリム ===
+最適なパフォーマンスを得るには、SSD を定期的にトリムしてランダム読み込みの速度を最適化するべきです。詳細は [[ソリッドステートドライブ#TRIM]] を参照してください。
+== CPU ==
 === オーバークロック ===
-直接 CPU の速度をあげる唯一の方法がオーバークロックです。煩雑でリスクを伴う作業が必要なので、上級者以外には推奨されません。オーバークロックは大抵の場合 BIOS から設定します。パソコンを買うときに、Intel マザーボードがオーバークロックを出来ないようにしていないか確認しておきましょう。
+[[Wikipedia:ja:オーバークロック|オーバークロック]]は、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。
-Intel 製のチップの多くは、BIOS や UEFI インターフェースを通して正式にオーバークロックされた場合でも、acpi_cpufreq などのユーティリティに正しいクロック周波数を伝えません。この結果、{{ic|acpi_cpufreq}} をアンロードしてブラックリスト化しない限り dmesg は極端なメッセージを表示します。{{Pkg|i7z}} がオーバークロックしたチップのクロック速度を Linux で正しく読むことができる唯一のツールです。
+Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、[[dmesg]] は極端なメッセージを表示します (これは、{{ic|acpi_cpufreq}} カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、{{Pkg|i7z}} パッケージの ''i7z'' を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、[[ストレステスト]]が推奨されます。
 === 周波数スケーリング ===
@@ 240行目: / 254行目: @@
 [[CPU 周波数スケーリング]]を見てください。
-=== CPU スケジューラを変更 ===
+=== CPU スケジューラ ===
+メインライン Linux カーネルのデフォルトの CPU スケジューラは [https://lwn.net/Articles/925371/ EEVDF] です。
+* {{App|[[Wikipedia:Brain_Fuck_Scheduler#MuQSS|MuQSS]]|Multiple Queue Skiplist Scheduler。[[Wikipedia:Con_Kolivas|Con Kolivas]] によって開発されている {{ic|-ck}} パッチセットにより利用可能。|[[非公式ユーザーリポジトリ/Repo-ck]]|{{AUR|linux-ck}}}}
+* {{App|[https://cchalpha.blogspot.com/search/label/PDS PDS]|デスクトップのレスポンスに焦点を当てている、優先度 (Priority) とデッドライン (Deadline) をベースとした Skiplist 複数キュースケジューラ。|https://cchalpha.blogspot.com/|{{AUR|linux-pds}}}}
+* {{App|[https://cchalpha.blogspot.com/search/label/BMQ BMQ]|BMQ "BitMap Queue" スケジューラは、既存の PDS 開発経験を元に作成され、Google の Zircon (Fuchsia OS イニシアチブ内のカーネル) に使用されているスケジューラからインスパイアされました。CachyOS からのパッチセットにより利用可能。|https://cchalpha.blogspot.com/|{{AUR|linux-cachyos-bmq}}}}
+* {{App|[https://cchalpha.blogspot.com/2020/05/project-c-announcement.html Project C]|BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。|https://cchalpha.blogspot.com/|{{AUR|linux-prjc}}}}
+* {{App|[https://github.com/hamadmarri/TT-CPU-Scheduler TT]|Task Type (TT) スケジューラの目標は、動作に基づいてタスクの種類を検出し、その種類に基づいてスケジューリングを制御することです。|https://github.com/hamadmarri/TT-CPU-Scheduler|{{AUR|linux-tt}}}}
+* {{App|[https://github.com/firelzrd/bore-scheduler BORE]|BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。|https://github.com/firelzrd/bore-scheduler|{{AUR|linux-cachyos-bore}}}}
+=== リアルタイムカーネル ===
-Linux のメインラインカーネルのデフォルト CPU スケジューラは [[w:ja:Completely_Fair_Scheduler|CFS]] です。
+(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、[[リアルタイムカーネル]]を使うと利益を得られる場合があります。
-デスクトップコンピュータ用に設計されたスケジューラとして [http://users.tpg.com.au/ckolivas/kernel/ Con Kolivas] によって開発された MuQSS が存在します。MuQSS ではデスクトップの即応性・操作性に重点が置かれています。 MuQSS はスタンドアロンのパッチとして使用したり、'''-ck''' パッチセットから利用することが可能です。パッチセットについては [[Linux-ck]] や [[Linux-pf]] を参照してください。
 === プロセスの優先順位を設定 ===
+{{man|1|nice}} と {{man|1|renice}} も参照してください。
 ==== Ananicy ====
-[https://github.com/Nefelim4ag/Ananicy Ananicy] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{AUR|ananicy-git}} パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときに実行可能ファイルの優先度を表すものです。
+[https://github.com/Nefelim4ag/Ananicy Ananicy] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{AUR|ananicy-git}} や {{AUR|ananicy-cpp}} パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときの実行可能ファイルの優先度を表すものです。
 ==== cgroups ====
 [[cgroups]] を見てください。
 ==== Cpulimit ====
-[https://github.com/opsengine/cpulimit Cpulimit] は特定のプロセスの CPU 使用率を制限するプログラムです。{{Pkg|cpulimit}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:
+[https://github.com/opsengine/cpulimit Cpulimit] は特定のプロセスの CPU 使用率を制限するプログラムです。{{AUR|cpulimit}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:
  $ cpulimit -l 50 -p 5081
@@ 264行目: / 291行目: @@
 {{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。
+=== CPU の脆弱性の緩和策をオフにする ===
-==グラフィック==
+{{Warning|1=以下の設定を使うときは問題の脆弱性について確認してください。詳しくは [https://phoronix.com/scan.php?page=news_item&px=Linux-Improve-CPU-Spec-Switches こちら] や [https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs こちら] のページを参照。}}
-===Xorg.conf 設定===
-グラフィックパフォーマンスは主に {{ic|/etc/X11/xorg.conf}} の設定に依存しています。[[NVIDIA]], [[ATI]], [[Intel Graphics|Intel]] のカードを使うためのチュートリアルを見ましょう。不適当な設定は Xorg の動作を止めます、警告が参考になるでしょう。
+CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下の[[カーネルパラメータ]]ですべての緩和策が無効になります:
-===Driconf===
-{{AUR|driconf}} はオープンソースドライバのダイレクトレンダリング設定を変えるための小さなユーティリティです。[[公式リポジトリ]]からインストールできます。HyperZ を有効にすることで劇的にパフォーマンスを向上させることができるかもしれません。
+ mitigations=off
-===GPU オーバークロック===
-グラフィックカードをオーバークロックすることは CPU のそれよりも一般的に好都合です、なぜなら、オンザフライで GPU のクロックを調節できる分かりやすいソフトウェアパッケージがあるからです。ATI ユーザーは、{{AUR|amdoverdrivectrl}} を使って下さい。Nvidia ユーザーは {{AUR|nvclock}} が必要です。Intel チップセットのユーザーは {{AUR|gmabooster}} パッケージで [http://www.gmabooster.com/ GMABooster] をインストールできます。
+このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。
-変更を永続的にするには、X 起動後に適当なコマンドを実行させてください、例えば、{{ic|~/.xinitrc}} にコマンドを追加するなど。ただし、必要な時だけにオーバークロック設定を適用させるほうがより安全ではあります。
+{{Note|1=第10世代およびそれ以降の Intel CPU、または AMD Ryzen シリーズ 1000 およびそれ以降の CPU を使用している場合、緩和策を無効化することにより得られるパフォーマンスの向上は、最大でも 5% にとどまります。一方、それ以前の世代の CPU では、最大 25% まで向上します。[https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt 2021 初頭における総評]、[https://www.phoronix.com/scan.php?page=article&item=spectre-rocket-lake Rocket Lake におけるテスト]、[https://www.phoronix.com/scan.php?page=article&item=alder-lake-mitigations Alder Lake におけるテスト] を参照。}}
-==RAM とスワップ==
-=== クロック周波数とタイミング ===
+== グラフィック ==
+=== Xorg の設定 ===
-RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。
+グラフィックパフォーマンスは {{man|5|xorg.conf}} の設定に依存している場合があります。[[NVIDIA]]、[[AMDGPU]]、[[Intel]] の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。
-=== Swappiness ===
+=== Mesa の設定 ===
-[[スワップ#Swappiness]] を参照してください。
+Mesa ドライバのパフォーマンスは [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ drirc] で設定できます。GUI の設定ツールもあります:
-=== Root on RAM オーバーレイ ===
+* {{App|adriconf (Advanced DRI Configurator)|オプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツール。|https://gitlab.freedesktop.org/mesa/adriconf/|{{Pkg|adriconf}}}}
-書き込みが遅いメディア (USB や HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。
+* {{App|DRIconf|Direct Rendering Infrastructure の設定アプレット。OpenGL ドライバのパフォーマンスや視覚クオリティ設定をドライバ毎、スクリーン毎、プリケーション毎レベルでカスタマイズできます。|https://dri.freedesktop.org/wiki/DriConf/|{{AUR|driconf}}}}
+=== ハードウェアビデオアクセラレーション ===
-=== Zram または zswap ===
+[[ハードウェアビデオアクセラレーション]]により、ビデオカードに動画のデコード/エンコードをさせることができます。
-[https://www.kernel.org/doc/Documentation/blockdev/zram.txt zram] カーネルモジュール (旧名 '''compcache''') は RAM に圧縮ブロックデバイスを作成します。スワップデバイスとして Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。[[zswap]] を使うことでも同じような利益を享受することができます。
+=== オーバークロック ===
-例: lz4 で圧縮する zram デバイスを 32GiB で設定して優先度を通常より高く設定 (現在のセッションのみで有効):
+CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: {{AUR|rovclock}} (ATI カード)、{{Pkg|rocm-smi-lib}} (最近の AMD カード)、{{AUR|nvclock}} (古い NVIDIA カード - Geforce 9 まで)、{{Pkg|nvidia-utils}} (最近の NVIDIA カード)。
- # modprobe zram
- # echo lz4 > /sys/block/zram0/comp_algorithm
- # echo 32G > /sys/block/zram0/disksize
- # mkswap --label zram0 /dev/zram0
- # swapon --priority 100 /dev/zram0
+[[AMDGPU#オーバークロック]] や [[NVIDIA/ヒントとテクニック#オーバークロックを有効化する]] を参照してください。
-無効化するには、再起動するか以下を実行:
+=== PCI resizable BAR を有効化する ===
- # swapoff /dev/zram0
- # rmmod zram
+{{Note|
-起動時に自動的に zram を初期化したい場合、[[systemd]] サービスを記述してください。
+* 一部のシステムでは、PCI resizable BAR を有効化するとパフォーマンスが大幅に劣化する可能性があります。システムのベンチマークを行って、PCI resizable BAR がパフォーマンスを向上させていることを確認してください。
+* 効果を発揮させるには、[[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] を無効化しなければなりません。
+}}
+PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい[[wikipedia:PCI_configuration_space#Standardized_registers|基底アドレスレジスタ (BAR)]] を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は [https://www.amd.com/ja/technologies/smart-access-memory AMD Smart Access Memory] と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。
-上記の手順の詳しい説明やオプション、問題点などは [https://www.kernel.org/doc/Documentation/blockdev/zram.txt こちら] のモジュールの公式ドキュメントに載っています。
+BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:
-{{Pkg|systemd-swap}} パッケージに含まれている {{ic|systemd-swap.service}} ユニットは自動的に zram デバイスを初期化します。設定は {{ic|/etc/systemd/swap.conf}} で行うことができます。
+{{hc|1=# dmesg {{!}} grep BAR=|2=
-AUR パッケージ {{AUR|zramswap}} はあなたのシステムに最適な設定で (RAM サイズや CPU コア数にあわせて) スワップデバイスをセットする自動スクリプトを提供します。スクリプトは１つの CPU コアに１つの zram デバイスを作成し、全体のスペースが RAM の量と同じになるようにします。また、標準スワップよりも圧縮スワップに高い優先度を持たせることでデータの圧縮に複数の CPU コアを利用してください。起動時に自動でこれを行わせるには、[[systemd#systemctl の基本的な使い方|systemctl]] を使って {{ic|zramswap.service}} を有効にしてください。
+[drm] Detected VRAM RAM=8176M, BAR=256M}}
+有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:
-{{Tip|zram の使用は、スワップが SSD にある場合、読み書き回数を減らすのにも役立ちます。}}
+{{hc|1=# dmesg {{!}} grep BAR=|2=
-===グラフィックカードの RAM を使う===
+[drm] Detected VRAM RAM=8176M, BAR=8192M}}
-搭載している RAM が僅かでビデオ RAM の余りがないような場合でなければ、ビデオ RAM をスワップとして使うことができます。[[ビデオメモリにスワップ]]を見て下さい。
-=== プリロード ===
+== RAM、スワップ、OOM 処理 ==
-プリロードとは、ターゲットファイルを RAM に置くことです。ハードドライブよりも RAM のほうが速く読み込まれるので、プリロードされたアプリケーションはより早く起動するという利益があります。しかしながら、RAM の一部を（アプリケーションを起動していないときでも）そのために取っておくことになります。したがって、プリロードは Firefox や OpenOffice など巨大でよく使うアプリケーションと一緒に使うのがベストです。
+=== クロック周波数とタイミング ===
-==== Go-preload ====
-{{AUR|gopreload-git}} は [https://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 Gentoo フォーラム] で作成された小さなデーモンです。使うには、まず、起動時にプリロードしたいプログラムごとに、次のコマンドを端末で実行してください:
- # gopreload-prepare program
+RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。
-それから、指示通りに、プログラムが完全にロードされたら Enter を押します。これでそのプログラムが必要とするファイルの一覧が {{ic|/usr/share/gopreload/enabled}} に追加されます。起動時に全てのリストをロードするには、systemd のサービスファイルを有効にしてください。
- # systemctl enable gopreload.service
+=== RAM オーバーレイ上に root を置く ===
-プログラムのロードを無効化するには、{{ic|/usr/share/gopreload/enabled}} の適切なリストを削除するか、{{ic|/usr/share/gopreload/disabled}} に移動してください。
+{{Out of date|liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。}}
-====Preload====
-[[Preload]] はもっと自動化されたアプローチを取ります。あなたがするべきことは systemd で Preload を有効にすることだけです。
- # systemctl enable preload
-システムで一番よく使われるファイルを監視して、起動時にプリロードするファイル一覧に組み込みます。
+書き込みが遅いメディア (USB や 回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。
-==起動時間==
-[[ブートパフォーマンスの向上]]にチュートリアルとヒントがあります。
-===Suspend to RAM===
+=== Zram または zswap ===
-起動時間を短縮する最適解は全く起動しないことです。[[サスペンドとハイバネート#Suspend to RAM|Suspend to RAM]] を使えないか考えてみて下さい。
+[[zswap]] や [[zram]] を使うことで、同様の利点を (同様のコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります。zswap は、圧縮 RAM キャッシュとして機能し、高コストなユーザ空間の設定を要求しません (そして、許可もしません)。[[zram]] は、RAM 内に圧縮ブロックデバイスを作成するために使用できるカーネルモジュールです。[[zswap]] はスワップデバイスと組み合わさって機能するのに対し、[[zram]] は補助スワップデバイスを必要としません。
-===カスタムカーネル===
-カスタムカーネルをコンパイルすることで起動時間やメモリ使用量を減らすことができるかもしれません、ただし、逆に増えてしまったり、問題が生じることもありえます。基本的に試す価値はありませんが、面白みを感じたり良い勉強の経験になるかもしれません。どうすればいいのか知りたいのなら、[[カーネル|ここから]]始めて下さい。
+===グラフィックカードの RAM を使う===
-== ネットワーク ==
+稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。[[ビデオメモリにスワップ]] を参照してください。
-=== ネットワークプロトコル ===
-[[Sysctl#パフォーマンスを向上させる]]を見てください。
+=== メモリ不足の状況におけるシステムのレスポンスを改善する ===
-=== NIC ===
-[[ネットワーク設定#MTU とキューの長さの設定]]を見てください。
+従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の OOM killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。
-=== SMB ===
-[[Samba#パフォーマンスを改善する]]を見てください。
+[https://lore.kernel.org/lkml/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/T/ カーネル]と[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Fedora] のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや {{ic|vm.overcommit_*}} [[sysctl]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます:
-=== DNS ===
-接続が作成される度に、TCP/IP スタックは IP アドレスの完全修飾ドメイン名を解決する必要があります。DNS キャッシュサーバーを使って DNS クエリをローカルでキャッシュすることで、ネットワーク要求のレスポンスが改善します。よく使われるツールとして [[pdnsd]], [[dnsmasq]], [[unbound]], [[rescached]] などが存在します。systemd サービスの {{ic|systemd-resolved}} はローカルアプリケーションにネットワーク名前解決を提供し、デフォルトで DNS キャッシュを行います。詳しくは {{man|8|systemd-resolved}} を見てください。
+* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。
+* ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。
+{{Warning|OOM killer をトリガーして実行中のアプリケーションを kill すると、保存されていない作業が失われる場合があります。アプリケーションが最終的に通常通りメモリを開放してくれることを期待して辛抱強く待つか、あるいは応答がないシステムを可能な限り早く通常に戻したいと望むかは、あなた次第です。}}
+カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:
+* {{App|systemd-oomd|[[systemd]] によって {{ic|systemd-oomd.service}} として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。|https://github.com/systemd/systemd, {{man|8|systemd-oomd}}|{{Pkg|systemd}}}}
+* {{App|earlyoom|C で書かれた、シンプルなユーザ空間の OOM killer 実装です。|https://github.com/rfjakob/earlyoom|{{Pkg|earlyoom}}}}
+* {{App|oomd|[https://lwn.net/Articles/759781/ PSI] ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。|https://github.com/facebookincubator/oomd|{{AUR|oomd}}}}
+* {{App|nohang|Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。|https://github.com/hakavlad/nohang|{{AUR|nohang-git}}}}
+* {{App|low-memory-monitor|GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。|https://gitlab.freedesktop.org/hadess/low-memory-monitor/|{{AUR|low-memory-monitor-git}}}}
+* {{App|uresourced|アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。|https://gitlab.freedesktop.org/benzea/uresourced|{{AUR|uresourced}}}}
+== ネットワーク ==
+* カーネルネットワーキング: [[Sysctl#パフォーマンスを向上させる]] を参照
+* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照
+* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照
+* Samba: [[Samba#スループットを向上させる]] を参照
+== ウォッチドッグ ==
-== Watchdog ==
 [[wikipedia:ja:ウォッチドッグタイマー]]より:
 :ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。
 システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。
-ソフトウェアとハードウェアの両方のウォッチドッグタイマーを無効化するには、ブートパラメータに {{ic|nowatchdog}} を追加してください。
+(ソフトウェアとハードウェア両方の) ウォッチドッグタイマーを無効化するには、ブートパラメータに {{ic|nowatchdog}} を追加してください。
+{{ic|nowatchdog}} ブートパラメータは Intel TCO ハードウェアウォッチドッグに対しては機能しない場合があります。[https://bbs.archlinux.org/viewtopic.php?id=221239] そのような場合、{{ic|1=modprobe.blacklist=iTCO_wdt}} [[カーネルパラメータ]]を使って TCO のカーネルモジュールを無効化することができます。
-新しい設定をチェックするには:
- # cat /proc/sys/kernel/watchdog
-または:
- # wdctl
+AMD Ryzen CPU を使用している場合、[[journal]] で {{ic|sp5100-tco}} も確認してください。これは [[Wikipedia:AMD_700_chipset_series|AMD 700 チップセットシリーズ]]内部のハードウェア watchdog です。これを無効化するには、以下を作成してください:
-ウォッチドッグを無効化したら、任意でハードウェアウォッチドッグを使うためのモジュールをロードしないようにすることができます。関連するモジュール (例: {{ic|iTCO_wdt}}) を[[ブラックリスト]]に追加してください。
+{{hc|/etc/modprobe.d/disable-sp5100-watchdog.conf|
-{{Note|1=一部のユーザーから {{ic|nowatchdog}} パラメータでウォッチドッグを無効化できないという報告があります [https://bbs.archlinux.org/viewtopic.php?id=221239]。その場合、上記のモジュールをブラックリストに追加することで (最低でもハードウェアのウォッチドッグは) 無効化できます。}}
+blacklist sp5100_tco
+}}
+あるいは、{{ic|1=modprobe.blacklist=sp5100_tco}} [[カーネルパラメータ]]を使用してください。
+{{ic|cat /proc/sys/kernel/watchdog}} か {{ic|wdctl}} で新しい設定が機能していることを確認してください。
 ロードされるモジュールが減ることで起動やシャットダウンが高速化されます。さらに、ウォッチドッグを無効にするとパフォーマンスが向上し、[[電源管理#NMI watchdog の無効化|消費電力も抑えられます]]。
-詳しくは [https://bbs.archlinux.org/viewtopic.php?id=163768], [https://bbs.archlinux.org/viewtopic.php?id=165834], [http://0pointer.de/blog/projects/watchdog.html], [https://www.kernel.org/doc/Documentation/watchdog/watchdog-parameters.txt] を参照してください。
+詳しくは [https://bbs.archlinux.org/viewtopic.php?id=163768]、[https://bbs.archlinux.org/viewtopic.php?id=165834]、[https://0pointer.de/blog/projects/watchdog.html]、[https://docs.kernel.org/watchdog/watchdog-parameters.html] を参照してください。
 == 参照 ==
-* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/index.html Red Hat Performance Tuning Guide]
+* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/index.html Red Hat Performance Tuning Guide]
 * [https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat Linux Performance Measurements using vmstat]
+{{TranslationStatus|Improving performance|2024-03-16|803302}}

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

2024年3月28日 (木) 09:39時点における最新版

目次

基本

システムを知る

ベンチマーク

ストレージデバイス

複数のハードウェアパス

パーティショニング

複数のドライブ

HDD でのレイアウト

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

マウントオプション

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

I/O スケジューラの設定

背景情報

スケジューリングアルゴリズム

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

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

IO スケジューラの調整

電源管理設定とライトキャッシュ

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

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

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

ファイルシステム

スワップ領域

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

コアダンプを無効化する

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

トリム

CPU

オーバークロック

周波数スケーリング

CPU スケジューラ

リアルタイムカーネル

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

Ananicy

cgroups

Cpulimit

irqbalance

CPU の脆弱性の緩和策をオフにする

グラフィック

Xorg の設定

Mesa の設定

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

オーバークロック

PCI resizable BAR を有効化する

RAM、スワップ、OOM 処理

クロック周波数とタイミング

RAM オーバーレイ上に root を置く

Zram または zswap

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

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

ネットワーク

ウォッチドッグ

参照

案内メニュー

検索