「パフォーマンスの向上」の版間の差分
(冒頭を同期) |
(同期) |
||
(3人の利用者による、間の47版が非表示) | |||
4行目: | 4行目: | ||
[[es:Improving performance]] |
[[es:Improving performance]] |
||
[[fr:Improving performance]] |
[[fr:Improving performance]] |
||
+ | [[pl:Improving performance]] |
||
[[pt:Improving performance]] |
[[pt:Improving performance]] |
||
[[ru:Improving performance]] |
[[ru:Improving performance]] |
||
[[zh-hans:Improving performance]] |
[[zh-hans:Improving performance]] |
||
{{Related articles start}} |
{{Related articles start}} |
||
− | {{Related| |
+ | {{Related|パフォーマンスの向上/ブートプロセス}} |
{{Related|Pacman ヒント#パフォーマンス}} |
{{Related|Pacman ヒント#パフォーマンス}} |
||
{{Related|OpenSSH#SSH の高速化}} |
{{Related|OpenSSH#SSH の高速化}} |
||
− | {{Related| |
+ | {{Related|OpenOffice#OpenOffice の高速化}} |
{{Related|ノートパソコン}} |
{{Related|ノートパソコン}} |
||
{{Related|Preload}} |
{{Related|Preload}} |
||
{{Related articles end}} |
{{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]] などの軽量な環境を使いましょう。 |
||
− | * 軽量なアプリケーションを使いましょう。[[アプリケーション一覧]]でコンソールアプリケーションを探したり、依存ライブラリが少ないアプリケーションを探してみてください。 |
||
− | |||
− | ===妥協=== |
||
− | ほとんど全てのチューニングには代償が伴います。軽量なアプリケーションは一般的に機能が少ないですし、調整がシステムを不安定にすることもあります。また、実行と管理に時間が必要になるでしょう。このページではそうした欠点もできるだけ触れますが、最終的に決定を下すのはユーザーです。 |
||
− | |||
− | ===ベンチマーク=== |
||
最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。 |
最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。 |
||
− | ==ストレージデバイス== |
+ | == ストレージデバイス == |
− | ===デバイスレイアウト=== |
||
− | パフォーマンスを一番大きく向上させるもののひとつが、オペレーティングシステムが動くレイアウトを複数のデバイスで作ることです。{{ic|/}} {{ic|/home}} {{ic|/var}} {{ic|/usr}} を異なるディスクに置くと、全てを同じハードドライブに置く、シングルディスクレイアウトに比べて劇的に速くなります。 |
||
− | |||
− | ====スワップファイル==== |
||
− | スワップファイルを分割したディスクに作成するのも、特にマシンがスワップを頻繁に使う場合、多くの利益があります。利用したい環境に十分な量の RAM がない場合によく使われます。多くの機能とアプリケーションを装備した KDE を使うには数 GiB のメモリが必要になりますが、小さなウィンドウマネージャとコンソールアプリケーションなら 512 MiB メモリ以下でも完全に適合します。 |
||
− | |||
− | ====RAID==== |
||
− | (2つ以上の)複数のディスクを使える場合、ソフトウェア [[RAID]] を設定することでスピードを向上させることが可能です。RAID 0 アレイではドライブ障害に対する冗長性はありませんが、アレイにディスクを追加すればそれだけディスクの速度を高速にできます。賢い選択は RAID 5 を使うことです、RAID 5 はスピードとデータ保護の両方を提供します。 |
||
− | |||
− | ====ハードウェアの接続端子==== |
||
− | 内部ハードウェア端子によってストレージデバイスはマザーボードに接続されます。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}} |
||
− | |||
− | {{hc|PCI デバイスツリー|$ lspci -tv}} |
||
=== パーティショニング === |
=== パーティショニング === |
||
85行目: | 50行目: | ||
==== HDD でのレイアウト ==== |
==== HDD でのレイアウト ==== |
||
+ | 従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター(ディスクの外周の近く)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は別のパーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home}}) を分割することでこれを達成できます。 |
||
− | {{Out of date|これはマルチプラッタハードディスクドライブでも成り立つのか?}} |
||
+ | {{Note|このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブを[https://blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/#shortstroke ショートストローク]したり、合計容量の数%しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。}} |
||
− | 伝統的な回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター(ディスクの外周の近く)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さくして、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は分割パーティションに置くべきです。通常、システム ({{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 以上ではデフォルトです)。 |
||
+ | ==== マウントオプション ==== |
||
− | 特定のファイルシステムにしかないマウントオプションも存在します。それぞれのファイルシステムのページを見て下さい: |
||
+ | |||
+ | 様々な [[fstab#atime オプション|*atime]] オプションが、{{ic|strictatime}} のパフォーマンスのペナルティを軽減することができます。 |
||
+ | |||
+ | 他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください: |
||
* [[Ext3]] |
* [[Ext3]] |
||
− | * [[Ext4# |
+ | * [[Ext4#パフォーマンスの向上]] |
* [[JFS#最適化]] |
* [[JFS#最適化]] |
||
− | * [[XFS]] |
+ | * [[XFS#パフォーマンス]] |
− | * [[Btrfs#デフラグメンテーション]] |
+ | * [[Btrfs#デフラグメンテーション]]、[[Btrfs#圧縮]]、{{man|5|btrfs}} |
* [[ZFS#チューニング]] |
* [[ZFS#チューニング]] |
||
+ | * [[NTFS#パフォーマンスの向上]] |
||
− | |||
− | ===== Reiserfs ===== |
||
− | |||
− | {{Ic|<nowiki>data=writeback</nowiki>}} マウントオプションはスピードを向上させますが、電源喪失でデータが破損します。{{Ic|notail}} マウントオプションはファイルシステムが使う容量を 5% ほど増やしますが、全体的なスピードが向上します。ジャーナルとデータを分割してドライブに置くことで読み込み時間を減らすこともできます。これをするにはファイルシステムを作成する際に次のようにしてください: |
||
− | |||
− | # 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 この記事] を見て下さい。 |
||
===カーネルパラメータの調整=== |
===カーネルパラメータの調整=== |
||
+ | |||
ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。 |
ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。 |
||
=== I/O スケジューラの設定 === |
=== I/O スケジューラの設定 === |
||
+ | |||
==== 背景情報 ==== |
==== 背景情報 ==== |
||
+ | |||
入出力 ''(I/O)'' スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です: |
入出力 ''(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 を超えるため、大抵の場合は必要な仕事量を上回ります。 |
* SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。 |
||
131行目: | 90行目: | ||
==== スケジューリングアルゴリズム ==== |
==== スケジューリングアルゴリズム ==== |
||
− | スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えて |
+ | スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えてできるだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが [[w:ja:エレベータアルゴリズム|elevator]] スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。 |
− | エレベータ |
+ | エレベータアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータスケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。[[w:Anticipatory_scheduling|anticipatory]] IO スケジューラはこの問題を解決します。このスケジューラは、他のリクエストを処理する前に、近くで別の読み取り操作が発生することを予測して、数ミリ秒待機します。 |
− | 上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。 |
+ | 上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターアルゴリズムと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。 |
− | [[w:CFQ|Completely Fair Queuing |
+ | [[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 |
+ | [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] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。 |
[https://lwn.net/Articles/720675/ Kyber] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。 リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。 |
||
==== カーネルの I/O スケジューラ ==== |
==== カーネルの I/O スケジューラ ==== |
||
+ | |||
初期のアルゴリズムには既にメインラインから外されているものもあります。公式 Linux カーネルがサポートしている I/O スケジューラは以下の2つのカテゴリに分けることができます: |
初期のアルゴリズムには既にメインラインから外されているものもあります。公式 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'' |
**''Kyber'' |
||
**''BFQ'' |
**''BFQ'' |
||
+ | |||
− | :{{Note|1=シングルキュースケジューラは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f382fb0bcef4c37dc049e9f6963e3baf204d815c Linux5.0 以降カーネルから削除されました]}} |
||
+ | *'''シングルキュースケジューラ'''はレガシーなスケジューラです: |
||
+ | **[[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 スケジューラの変更 ==== |
==== I/O スケジューラの変更 ==== |
||
+ | |||
− | {{Note| |
||
− | + | {{Note|スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。 また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 [[ベンチマーク]] は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。}} |
|
+ | |||
− | }} |
||
− | 特定のデバイスで利用 |
+ | 特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中): |
+ | |||
{{hc|$ cat /sys/block/'''''sda'''''/queue/scheduler| |
{{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 |
||
− | mq-deadline kyber [bfq] none}} |
||
− | + | 全デバイスで利用可能なスケジューラを表示するには: |
|
+ | |||
+ | {{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 |
# echo '''''bfq''''' > /sys/block/'''''sda'''''/queue/scheduler |
||
+ | I/O スケジューラの変更プロセスは、ディスクが回転式か否かに応じて自動化することができ、起動毎に永続化させることができます。例えば、以下の [[udev]] ルールは、回転ドライブに対しては ''bfq'' を、[[SSD]]/eMMC ドライブに対しては ''bfq'' を、[[NVMe]] に対しては ''none'' を設定します: |
||
− | [[SSD]] や [[NVMe]] の場合多数の IOPS を処理できるため、''none'' や ''mq-deadline'' などのシンプルなアルゴリズムが最適です。逆に HDD には ''BFQ'' が適しています。以下のように [[udev]] ルールを使うことで、ディスクが HDD か SSD かどうかで I/O スケジューラを自動的に変更して永続的に設定することが可能です: |
||
− | {{hc|/etc/udev/rules.d/60-ioschedulers.rules| |
+ | {{hc|/etc/udev/rules.d/60-ioschedulers.rules|<nowiki> |
+ | # HDD |
||
− | # set scheduler for NVMe |
||
− | ACTION=="add |
+ | ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" |
− | # set scheduler for SSD and eMMC |
||
− | ACTION=="add{{!}}change", KERNEL=="sd[a-z]{{!}}mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline" |
||
− | # set scheduler for rotating disks |
||
− | ACTION=="add{{!}}change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" |
||
− | }} |
||
+ | # 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 スケジューラの調整 ==== |
==== IO スケジューラの調整 ==== |
||
− | カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用い |
+ | カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。 |
+ | 設定項目と説明は [https://docs.kernel.org/block/index.html カーネルドキュメント] で確認できます。 |
||
特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています): |
特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています): |
||
+ | |||
{{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched| |
{{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched| |
||
fifo_batch front_merges read_expire write_expire writes_starved}} |
fifo_batch front_merges read_expire write_expire writes_starved}} |
||
199行目: | 170行目: | ||
{{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}} |
{{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}} |
||
− | === 電源管理 |
+ | === 電源管理設定とライトキャッシュ === |
+ | |||
− | 伝統的な回転ディスク (HDD) を使用する場合は[[Hdparm#電源管理の設定|省電力機能を無効化]]することで性能の改善が見込めます。 |
||
+ | 従来の回転ディスク (HDD) を使用する場合は、省電力機能を完全に無効にするか下げるかし、書き込みキャッシュが有効になっているかどうかを確認すると良いかもしれません。 |
||
+ | |||
+ | [[Hdparm#電源管理の設定]] と [[Hdparm#ライトキャッシュ]] を参照してください。 |
||
+ | |||
+ | 後で、起動時にこれらを適用する [[Hdparm#udev ルールによる永続的な設定|udev ルール]] を作成することができます。 |
||
+ | |||
+ | {{Tip|[[GNOME]] では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。}} |
||
+ | |||
+ | {{Note|一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。}} |
||
=== ディスクの読み書きを減らす === |
=== ディスクの読み書きを減らす === |
||
206行目: | 186行目: | ||
遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。 |
遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。 |
||
− | {{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、毎日 10GB のデータ書き込みを行うと、8年間で寿命が尽きるとされます。この数字はもっと容量が大きい SSD を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは |
+ | {{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、'''毎日 10GB のデータ書き込みを行うと'''、'''8年間で寿命が尽きる'''とされます。この数字はもっと[https://kcall.co.uk/ssd/ 容量が大きい SSD] を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは[https://web.archive.org/web/20161124030749/http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead この耐久実験]も参照してください。}} |
==== ディスクの書き込みを表示する ==== |
==== ディスクの書き込みを表示する ==== |
||
214行目: | 194行目: | ||
==== ファイルを tmpfs に再配置する ==== |
==== ファイルを tmpfs に再配置する ==== |
||
− | ブラウザプロファイルなどのファイルを |
+ | ブラウザプロファイルなどのファイルを [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます: |
− | * ブラウザプロファイル |
+ | * ブラウザプロファイルを同期させる方法については [[Profile-sync-daemon]] を参照してください。特定のブラウザには注意が必要な場合があります。例えば [[Firefox Ramdisk]] を参照してください。 |
− | * |
+ | * 任意の指定されたフォルダを同期させる方法については [[Anything-sync-daemon]] を参照してください。 |
+ | * tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については [[Makepkg#ビルド時間を短縮する]] を参照してください。 |
||
− | ==== |
+ | ==== ファイルシステム ==== |
+ | 対応する[[ファイルシステム]]ページを参照して、パフォーマンス改善に関する指示があるか見てください。[[#ファイルシステムの選択とチューニング]] に挙げられているファイルシステムのリストも参照してください。 |
||
− | パッケージのビルド時にコンパイル時間を短縮する方法は [[Makepkg#コンパイル時間を短縮する]]を参照。 |
||
− | ==== |
+ | ==== スワップ領域 ==== |
+ | [[スワップ#パフォーマンス]] を見てください。 |
||
− | [[ファイルシステム]]によってはパフォーマンスを改善する方法が存在することがあります。例: [[Ext4#ヒントとテクニック]]。 |
||
− | ==== |
+ | ==== ライトバックの間隔とバッファサイズ ==== |
− | [[ |
+ | 詳細は [[Sysctl#仮想メモリ]] を見てください。 |
+ | |||
+ | ==== コアダンプを無効化する ==== |
||
+ | |||
+ | [[コアダンプ#自動的なコアダンプの無効化]] を見てください。 |
||
=== ionice によるストレージ I/O スケジューリング === |
=== ionice によるストレージ I/O スケジューリング === |
||
− | バックアップなどの |
+ | バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ CFQ を使用することで実現できます。 |
− | バックグラウンドプロセスの I/O 優先度 |
+ | 以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます: |
# ionice -c 3 command |
# ionice -c 3 command |
||
− | 詳 |
+ | 詳細は [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html a short introduction to ionice] や {{man|1|ionice}} を参照してください。 |
+ | |||
+ | === トリム === |
||
+ | |||
+ | 最適なパフォーマンスを得るには、SSD を定期的にトリムしてランダム書き込みの速度を最適化するべきです。詳細は [[ソリッドステートドライブ#TRIM]] を参照してください。 |
||
− | ==CPU== |
+ | == CPU == |
=== オーバークロック === |
=== オーバークロック === |
||
− | + | [[Wikipedia:ja:オーバークロック|オーバークロック]]は、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。 |
|
− | Intel 製のチップの多くは |
+ | Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、[[dmesg]] は極端なメッセージを表示します (これは、{{ic|acpi_cpufreq}} カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、{{Pkg|i7z}} パッケージの ''i7z'' を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、[[ストレステスト]]が推奨されます。 |
=== 周波数スケーリング === |
=== 周波数スケーリング === |
||
253行目: | 242行目: | ||
[[CPU 周波数スケーリング]]を見てください。 |
[[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}}}} |
||
− | デスクトップコンピュータ用に設計されたスケジューラとして [http://users.tpg.com.au/ckolivas/kernel/ Con Kolivas] によって開発された MuQSS が存在します。MuQSS ではデスクトップの即応性・操作性に重点が置かれています。 MuQSS はスタンドアロンのパッチとして使用したり、'''-ck''' パッチセットから利用することが可能です。パッチセットについては [[Linux-ck]] や [[Linux-pf]] を参照してください。 |
||
+ | * {{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}}}} |
||
+ | |||
+ | === リアルタイムカーネル === |
||
+ | |||
+ | (TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、[[リアルタイムカーネル]]を使うと利益を得られる場合があります。 |
||
=== プロセスの優先順位を設定 === |
=== プロセスの優先順位を設定 === |
||
+ | |||
+ | {{man|1|nice}} と {{man|1|renice}} も参照してください。 |
||
==== Ananicy ==== |
==== Ananicy ==== |
||
+ | |||
− | [https://github.com/Nefelim4ag/Ananicy Ananicy] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{AUR|ananicy-git}} や {{AUR|ananicy-cpp}} パッケージで利用可能です。nice レベルとは、CPU 資源を配分するときに実行可能ファイルの優先度を表すものです。 |
||
+ | [https://github.com/Nefelim4ag/Ananicy Ananicy] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{AUR|ananicy-git}} や {{AUR|ananicy-cpp}} パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。 |
||
+ | |||
+ | {{Warning|1=[[Gamemode]] と [https://github.com/Nefelim4ag/Ananicy Ananicy] はどちらもプロセスの nice レベルを調整しようとします。これらのツールを組み合わせて使用することは推奨されていません。[https://github.com/CachyOS/ananicy-rules/blob/master/README.md#gamemode--ananicy-cpp--bad-idea]}} |
||
==== cgroups ==== |
==== cgroups ==== |
||
+ | |||
[[cgroups]] を見てください。 |
[[cgroups]] を見てください。 |
||
==== Cpulimit ==== |
==== Cpulimit ==== |
||
− | [https://github.com/opsengine/cpulimit Cpulimit] は特定のプロセスの CPU 使用率を制限するプログラムです。{{ |
+ | [https://github.com/opsengine/cpulimit Cpulimit] は特定のプロセスの CPU 使用率を制限するプログラムです。{{AUR|cpulimit}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例: |
$ cpulimit -l 50 -p 5081 |
$ cpulimit -l 50 -p 5081 |
||
277行目: | 280行目: | ||
{{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。 |
{{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。 |
||
− | === CPU の脆弱性の緩和をオフにする === |
+ | === 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 こちら] のページを参照。}} |
{{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 こちら] のページを参照。}} |
||
287行目: | 290行目: | ||
このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。 |
このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。 |
||
− | {{Note|1=第10世代およびそれ以降の Intel CPU、または AMD Ryzen |
+ | {{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 におけるテスト] を参照。}} |
− | ==グラフィック== |
+ | == グラフィック == |
− | ===Xorg |
+ | === Xorg の設定 === |
− | グラフィックパフォーマンスは主に {{ic|/etc/X11/xorg.conf}} の設定に依存しています。[[NVIDIA]], [[ATI]], [[Intel Graphics|Intel]] のカードを使うためのチュートリアルを見ましょう。不適当な設定は Xorg の動作を止めます、警告が参考になるでしょう。 |
||
+ | グラフィックパフォーマンスは {{man|5|xorg.conf}} の設定に依存している場合があります。[[NVIDIA]]、[[AMDGPU]]、[[Intel]] の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。 |
||
− | ===Driconf=== |
||
− | {{AUR|driconf}} はオープンソースドライバのダイレクトレンダリング設定を変えるための小さなユーティリティです。[[公式リポジトリ]]からインストールできます。HyperZ を有効にすることで劇的にパフォーマンスを向上させることができるかもしれません。 |
||
− | === |
+ | === Mesa の設定 === |
− | グラフィックカードをオーバークロックすることは CPU のそれよりも一般的に好都合です、なぜなら、オンザフライで GPU のクロックを調節できる分かりやすいソフトウェアパッケージがあるからです。ATI ユーザーは、{{AUR|amdoverdrivectrl}} を使って下さい。Nvidia ユーザーは {{AUR|nvclock}} が必要です。Intel チップセットのユーザーは {{AUR|gmabooster}} パッケージで [http://www.gmabooster.com/ GMABooster] をインストールできます。 |
||
+ | Mesa ドライバのパフォーマンスは [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ drirc] で設定できます。GUI の設定ツールもあります: |
||
− | 変更を永続的にするには、X 起動後に適当なコマンドを実行させてください、例えば、{{ic|~/.xinitrc}} にコマンドを追加するなど。ただし、必要な時だけにオーバークロック設定を適用させるほうがより安全ではあります。 |
||
+ | * {{App|adriconf (Advanced DRI Configurator)|オプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツール。|https://gitlab.freedesktop.org/mesa/adriconf/|{{Pkg|adriconf}}}} |
||
− | == RAM、スワップ、OOM 処理 == |
||
+ | * {{App|DRIconf|Direct Rendering Infrastructure の設定アプレット。OpenGL ドライバのパフォーマンスや視覚クオリティ設定をドライバ毎、スクリーン毎、プリケーション毎レベルでカスタマイズできます。|https://dri.freedesktop.org/wiki/DriConf/|{{AUR|driconf}}}} |
||
+ | === ハードウェアビデオアクセラレーション === |
||
− | === クロック周波数とタイミング === |
||
+ | [[ハードウェアビデオアクセラレーション]]により、ビデオカードに動画のデコード/エンコードをさせることができます。 |
||
− | RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。 |
||
− | === |
+ | === オーバークロック === |
+ | CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: {{AUR|rovclock}} (ATI カード)、{{Pkg|rocm-smi-lib}} (最近の AMD カード)、{{AUR|nvclock}} (古い NVIDIA カード - Geforce 9 まで)、{{Pkg|nvidia-utils}} (最近の NVIDIA カード)。 |
||
− | [[スワップ#Swappiness]] を参照してください。 |
||
+ | [[AMDGPU#オーバークロック]] や [[NVIDIA/ヒントとテクニック#オーバークロックを有効化する]] を参照してください。 |
||
− | === Root on RAM オーバーレイ === |
||
+ | === PCI resizable BAR を有効化する === |
||
− | 書き込みが遅いメディア (USB や HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。 |
||
+ | {{Note| |
||
− | === Zram または zswap === |
||
+ | * 一部のシステムでは、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 zram] カーネルモジュール (旧名 '''compcache''') は RAM に圧縮ブロックデバイスを作成します。スワップデバイスとして Zram を使うと、RAM 上に保持できる情報が増やせますが、CPU の使用量は増加します。ただし、ハードドライブにスワップするよりかは大いに高速です。システムがスワップをよく使う場合、レスポンスを向上させることができるかもしれません。[[zswap]] を使うことでも同じような利益を享受することができます。 |
||
+ | BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません: |
||
− | 例: lz4 で圧縮する zram デバイスを 32GiB で設定して優先度を通常より高く設定 (現在のセッションのみで有効): |
||
+ | {{hc|1=# dmesg {{!}} grep BAR=|2= |
||
− | # modprobe zram |
||
+ | [drm] Detected VRAM RAM=8176M, BAR=256M}} |
||
− | # echo lz4 > /sys/block/zram0/comp_algorithm |
||
− | # echo 32G > /sys/block/zram0/disksize |
||
− | # mkswap --label zram0 /dev/zram0 |
||
− | # swapon --priority 100 /dev/zram0 |
||
+ | 有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには: |
||
− | 無効化するには、再起動するか以下を実行: |
||
+ | {{hc|1=# dmesg {{!}} grep BAR=|2= |
||
− | # swapoff /dev/zram0 |
||
+ | [drm] Detected VRAM RAM=8176M, BAR=8192M}} |
||
− | # rmmod zram |
||
+ | == RAM、スワップ、OOM 処理 == |
||
− | すべてのステップ、オプション、潜在的な問題の詳細な説明は、 [https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html zramモジュールの公式ドキュメント] で提供されています。 |
||
+ | === クロック周波数とタイミング === |
||
− | {{pkg|zram-generator}} パッケージは、{{ic|systemd-zram-setup@.service}} ユニットを提供し、ユーザーがテンプレートやそのインスタンスを [https://wiki.archlinux.jp/index.php/Systemd#.E3.83.A6.E3.83.8B.E3.83.83.E3.83.88.E3.82.92.E4.BD.BF.E3.81.86 有効化/起動] することなく、zram デバイスを自動的に初期化します。使用方法については、次のリソースを参照してください。 |
||
+ | RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。 |
||
− | * {{man|8|zram-generator}} |
||
− | * {{man|5|zram-generator.conf}} |
||
− | * https://github.com/systemd/zram-generator#readme |
||
+ | === RAM オーバーレイ上に root を置く === |
||
− | "このジェネレータは起動時に systemd によって起動されます" ので、適切な設定ファイルを作成してリブートするだけで簡単に使用できます。設定例については、[https://raw.githubusercontent.com/systemd/zram-generator/main/zram-generator.conf.example/usr/share/doc/zram-generator/zram-generator.conf 例] を参照してください。また、[https://wiki.archlinux.jp/index.php/Systemd#.E3.83.A6.E3.83.8B.E3.83.83.E3.83.88.E3.82.92.E4.BD.BF.E3.81.86 status] を {{ic|systemd-zram-setup@zram''N''.service}} インスタンスでチェックすることで、設定済みの {{ic|/dev/zram''N''}} デバイスの [[スワップ#スワップ領域|スワップステータスのチェック]] を行うこともできます。 |
||
+ | {{Out of date|liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。}} |
||
− | パッケージ {{AUR|zramswap}} には、より高い優先順位とシステムのRAMサイズの20%のデフォルトサイズでスワップを設定するための自動スクリプトが用意されています。これをブートのたびに自動的に行うには、 [https://wiki.archlinux.jp/index.php/Systemd#.E3.83.A6.E3.83.8B.E3.83.83.E3.83.88.E3.82.92.E4.BD.BF.E3.81.86 有効化] {{ic|zramswap.service}} をクリックします。 |
||
+ | 書き込みが遅いメディア (USB や 回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。 |
||
− | また、{{AUR|zramd}} パッケージでは、デフォルトで zstd 圧縮を使用して zram を自動的に設定することができ、その設定は{{ic|/etc/default/zramd}} で変更できます。起動時に起動するには、{{ic|zramd.service}} ユニットを有効にします。 |
||
+ | === Zram または zswap === |
||
− | ==== udevルールを使って zram にスワップする ==== |
||
+ | [[zswap]] や [[zram]] を使うことで、同様の利点を (同様のコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります。zswap は、圧縮 RAM キャッシュとして機能し、高コストなユーザ空間の設定を要求しません (そして、許可もしません)。[[zram]] は、RAM 内に圧縮ブロックデバイスを作成するために使用できるカーネルモジュールです。[[zswap]] はスワップデバイスと組み合わさって機能するのに対し、[[zram]] は補助スワップデバイスを必要としません。 |
||
− | 次の例では、起動時に単一の udev 規則を使用して zram にスワップを自動的に設定する方法を説明します。これを動作させるために余分なパッケージは必要ありません。 |
||
+ | ===グラフィックカードの RAM を使う=== |
||
− | まず、モジュールを有効にします。 |
||
+ | 稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。[[ビデオメモリにスワップ]] を参照してください。 |
||
− | {{hc|/etc/modules-load.d/zram.conf| |
||
− | zram |
||
− | }} |
||
− | |||
− | 必要な /dev/zram ノードの数を設定します。 |
||
− | |||
− | {{hc|/etc/modprobe.d/zram.conf|2= |
||
− | options zram num_devices=2 |
||
− | }} |
||
− | |||
− | 例に示すように、udev 規則を作成します。 |
||
− | |||
− | {{hc|/etc/udev/rules.d/99-zram.rules|2= |
||
− | KERNEL=="zram0", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram0", TAG+="systemd" |
||
− | KERNEL=="zram1", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram1", TAG+="systemd" |
||
− | }} |
||
− | |||
− | fstab に /dev/zram を追加します。 |
||
− | |||
− | {{hc|/etc/fstab| |
||
− | /dev/zram0 none swap defaults 0 0 |
||
− | /dev/zram1 none swap defaults 0 0 |
||
− | }} |
||
− | |||
− | ===グラフィックカードの RAM を使う=== |
||
− | 搭載している RAM が僅かでビデオ RAM の余りがないような場合でなければ、ビデオ RAM をスワップとして使うことができます。[[ビデオメモリにスワップ]]を見て下さい。 |
||
=== メモリ不足の状況におけるシステムのレスポンスを改善する === |
=== メモリ不足の状況におけるシステムのレスポンスを改善する === |
||
384行目: | 358行目: | ||
従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の OOM killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。 |
従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の OOM killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。 |
||
− | [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]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます: |
+ | [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]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます: |
* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。 |
* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。 |
||
399行目: | 373行目: | ||
* {{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|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}}}} |
* {{App|uresourced|アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。|https://gitlab.freedesktop.org/benzea/uresourced|{{AUR|uresourced}}}} |
||
− | |||
− | ==起動時間== |
||
− | [[ブートパフォーマンスの向上]]にチュートリアルとヒントがあります。 |
||
− | |||
− | ===Suspend to RAM=== |
||
− | 起動時間を短縮する最適解は全く起動しないことです。[[サスペンドとハイバネート#Suspend to RAM|Suspend to RAM]] を使えないか考えてみて下さい。 |
||
− | |||
− | ===カスタムカーネル=== |
||
− | カスタムカーネルをコンパイルすることで起動時間やメモリ使用量を減らすことができるかもしれません、ただし、逆に増えてしまったり、問題が生じることもありえます。基本的に試す価値はありませんが、面白みを感じたり良い勉強の経験になるかもしれません。どうすればいいのか知りたいのなら、[[カーネル|ここから]]始めて下さい。 |
||
== ネットワーク == |
== ネットワーク == |
||
414行目: | 379行目: | ||
* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照 |
* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照 |
||
* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照 |
* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照 |
||
− | * Samba: [[Samba# |
+ | * Samba: [[Samba#スループットを向上させる]] を参照 |
+ | |||
+ | == ウォッチドッグ == |
||
− | == Watchdog == |
||
[[wikipedia:ja:ウォッチドッグタイマー]]より: |
[[wikipedia:ja:ウォッチドッグタイマー]]より: |
||
+ | |||
:ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。 |
:ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。 |
||
システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。 |
システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。 |
||
− | ソフトウェアとハードウェア |
+ | (ソフトウェアとハードウェア両方の) ウォッチドッグタイマーを無効化するには、ブートパラメータに {{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 の無効化|消費電力も抑えられます]]。 |
ロードされるモジュールが減ることで起動やシャットダウンが高速化されます。さらに、ウォッチドッグを無効にするとパフォーマンスが向上し、[[電源管理#NMI watchdog の無効化|消費電力も抑えられます]]。 |
||
− | 詳しくは [https://bbs.archlinux.org/viewtopic.php?id=163768] |
+ | 詳しくは [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/ |
+ | * [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] |
* [https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat Linux Performance Measurements using vmstat] |
||
+ | |||
+ | {{TranslationStatus|Improving performance|2024-07-19|812082}} |
2024年7月19日 (金) 21:34時点における最新版
関連記事
この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは ゲーム#パフォーマンスを向上させる も参照してください。
目次
基本
システムを知る
システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。
- (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください:
$ free -h
- 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには
hdparm
コマンドを使うことができます:# hdparm -t /dev/sdX
- 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要なデーモンやプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。htop や
pstree
などのシステム監視ツールで CPU 負担をモニタすることができます:$ htop
- ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、ウィンドウマネージャなどの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。
glxinfo
コマンドを使うことで確認できます (mesa-utils パッケージに含まれています)。次のコマンドを実行するとdirect rendering: Yes
と表示される必要があります:$ glxinfo | grep "direct rendering"
- デスクトップ環境を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、カスタムの環境を作成しましょう。
- 最適化されたカーネルを使用することでパフォーマンスを向上できます。一般に linux-zen が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。
ベンチマーク
最適化の効果を判断できないことがたびたびあります。そういった場合はベンチマークツールで計測することができます。
ストレージデバイス
パーティショニング
パーティションが適切にアライメントされていることを確認してください。
複数のドライブ
複数のドライブを持っているのであれば、ソフトウェア RAID を組んでパフォーマンスを劇的に向上させることができます。
スワップを別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。
HDD でのレイアウト
従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター(ディスクの外周の近く)は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ(画像・動画など)は別のパーティションに置くべきです。通常、システム (/
) から home ディレクトリ (/home
) を分割することでこれを達成できます。
ファイルシステムの選択とチューニング
ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。ファイルシステムの記事に人気のあるファイルシステムの簡単な説明がされています。カテゴリ:ファイルシステムから関連記事も見ることができます。
マウントオプション
様々な *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
- シングルキュースケジューラはレガシーなスケジューラです:
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 ルール を作成することができます。
ディスクの読み書きを減らす
遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。
ディスクの書き込みを表示する
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-ckAUR
- BMQ — BMQ "BitMap Queue" スケジューラは、既存の PDS 開発経験を元に作成され、Google の Zircon (Fuchsia OS イニシアチブ内のカーネル) に使用されているスケジューラからインスパイアされました。CachyOS からのパッチセットにより利用可能。
- Project C — BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。
- TT — Task Type (TT) スケジューラの目標は、動作に基づいてタスクの種類を検出し、その種類に基づいてスケジューリングを制御することです。
- BORE — BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。
リアルタイムカーネル
(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、リアルタイムカーネルを使うと利益を得られる場合があります。
プロセスの優先順位を設定
nice(1) と renice(1) も参照してください。
Ananicy
Ananicy は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、ananicy-gitAUR や ananicy-cppAUR パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。
cgroups
cgroups を見てください。
Cpulimit
Cpulimit は特定のプロセスの CPU 使用率を制限するプログラムです。cpulimitAUR をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:
$ cpulimit -l 50 -p 5081
irqbalance
irqbalance はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。irqbalance.service
で操作することが可能です。
CPU の脆弱性の緩和策をオフにする
CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下のカーネルパラメータですべての緩和策が無効になります:
mitigations=off
このパラメータによって切り替えられるすべてのスイッチについての説明は、kernel.org で見られます。spectre-meltdown-checkerAUR や lscpu(1) (util-linux に同梱) を使うことで、脆弱性チェックを行うことができます。
グラフィック
Xorg の設定
グラフィックパフォーマンスは xorg.conf(5) の設定に依存している場合があります。NVIDIA、AMDGPU、Intel の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。
Mesa の設定
Mesa ドライバのパフォーマンスは drirc で設定できます。GUI の設定ツールもあります:
- adriconf (Advanced DRI Configurator) — オプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツール。
- DRIconf — Direct Rendering Infrastructure の設定アプレット。OpenGL ドライバのパフォーマンスや視覚クオリティ設定をドライバ毎、スクリーン毎、プリケーション毎レベルでカスタマイズできます。
ハードウェアビデオアクセラレーション
ハードウェアビデオアクセラレーションにより、ビデオカードに動画のデコード/エンコードをさせることができます。
オーバークロック
CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: rovclockAUR (ATI カード)、rocm-smi-lib (最近の AMD カード)、nvclockAUR (古い NVIDIA カード - Geforce 9 まで)、nvidia-utils (最近の NVIDIA カード)。
AMDGPU#オーバークロック や NVIDIA/ヒントとテクニック#オーバークロックを有効化する を参照してください。
PCI resizable BAR を有効化する
PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい基底アドレスレジスタ (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は AMD Smart Access Memory と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。
BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=256M
有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=8192M
RAM、スワップ、OOM 処理
クロック周波数とタイミング
RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。#オーバークロックを参照。
RAM オーバーレイ上に root を置く
書き込みが遅いメディア (USB や 回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。liverootAUR を見て下さい。
Zram または zswap
zswap や zram を使うことで、同様の利点を (同様のコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります。zswap は、圧縮 RAM キャッシュとして機能し、高コストなユーザ空間の設定を要求しません (そして、許可もしません)。zram は、RAM 内に圧縮ブロックデバイスを作成するために使用できるカーネルモジュールです。zswap はスワップデバイスと組み合わさって機能するのに対し、zram は補助スワップデバイスを必要としません。
グラフィックカードの RAM を使う
稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。ビデオメモリにスワップ を参照してください。
メモリ不足の状況におけるシステムのレスポンスを改善する
従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の OOM killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。
カーネルとFedora のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや vm.overcommit_*
sysctl パラメータの調整よりも実行可能で効果的なオプションを使うことができます:
- Magic SysRq キー (
Alt+SysRq+f
) で手動でカーネルの OOM killer をトリガーする。 - ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。
カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:
- systemd-oomd — systemd によって
systemd-oomd.service
として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。
- earlyoom — C で書かれた、シンプルなユーザ空間の OOM killer 実装です。
- oomd — PSI ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。
- nohang — Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。
- low-memory-monitor — GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。
- uresourced — アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。
ネットワーク
- カーネルネットワーキング: Sysctl#パフォーマンスを向上させる を参照
- NIC: ネットワーク設定#MTU とキューの長さの設定 を参照
- DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。ドメイン名前解決#DNS サーバ を参照
- Samba: Samba#スループットを向上させる を参照
ウォッチドッグ
- ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。
システムがミッションクリティカルな役割 (サーバーなど) を担う場合や電源のリセットができない場合 (組み込みデバイスなど)、上記のようなウォッチドッグ機能が必要となります。ユースケースによってはウォッチドッグ機能はシステム運用に不可欠な存在です。一方で、普通のユーザー (デスクトップやノートパソコンユーザー) にとっては不要な機能であり無効化しても問題ありません。
(ソフトウェアとハードウェア両方の) ウォッチドッグタイマーを無効化するには、ブートパラメータに 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] を参照してください。