- Linux カーネルをチューニングするには、アーキテクチャ構成、sysctl、およびレイテンシ重視の CPU スケジューリングを組み合わせる必要があります。
- カスタム カーネルと PREEMPT_RT パッチを使用すると、レイテンシを大幅に削減できますが、複雑さとメンテナンスの負担が増します。
- ネットワーク、メモリ、ディスク、およびシステム サービスの最適化は、常に厳密な監視とベンチマークによって測定する必要があります。
- 反復的なメトリックス主導のアプローチにより、カーネルの改善がアプリケーションとユーザーにとっての実際のメリットになります。
Linuxのパフォーマンスについて語る際、ほとんどすべての論点が同じことを指しています。それは、レイテンシ、安定性、リソース使用量を制御する中心的なコンポーネントであるカーネルです。カーネルを微調整することで、サーバー、デスクトップ、クラウド環境、あるいは非常に古いハードウェア上でも、ただ「なんとか動く」システムとスムーズに動作するシステムとの違いを生み出すことができます。
このガイドでは、セキュリティや保守性を損なうことなく、Linuxカーネルを最適化してレイテンシを最小限に抑える方法に焦点を当てます。基本的なアーキテクチャの概念から、sysctlを使った調整、カスタムカーネルのコンパイル、リアルタイムパッチの使用、低レイテンシネットワーク（EC2など）向けのチューニング、そして調整によって実際にパフォーマンスが向上したかどうかを測定するためのモニタリングとベンチマークの手法まで、あらゆる内容を網羅します。
Linuxカーネルアーキテクチャとレイテンシの重要なポイント
Linuxカーネルは、アプリケーションとハードウェア間の仲介層として機能し、メモリ、プロセス、割り込み、ドライバ、ファイルシステムを管理します。ロード可能なモジュールのおかげで、そのモノリシックでありながらモジュール化された設計により、システム全体を再コンパイルすることなく、機能を柔軟に有効化または無効化できます。
レイテンシの原因を理解するには、プロセススケジューラ、メモリ管理、割り込み処理といった複数のサブシステムを理解することが不可欠です。スケジューラの設定が不適切であったり、メモリポリシーが過剰であったり、制御不能な割り込みが多すぎたりすると、高性能なハードウェアであっても応答速度が低下する可能性があります。
CONFIG_PREEMPT、CONFIG_PREEMPT_VOLUNTARY、CONFIG_SMPなどのカーネル構成オプションが重要になります。これらは、カーネルがより緊急性の高いタスクを処理するためにどの程度プリエンプションされるか、またマルチコアシステムをどのように処理するかを決定します。適切なプリエンプションモデルを選択することで、デスクトップ、低遅延サーバー、または産業用システムにおける体感レイテンシが大きく変化します。
最新のサーバーでは、ハードウェアのトポロジーも重要です。コアの配置、ソケット、NUMA、キャッシュ階層などが挙げられます。CPUアフィニティやNUMAポリシーを微調整する（例えば、プロセスとメモリを同じノードに割り当てる）ことで、アクセス時間を短縮し、キャッシュヒット率を向上させることができます。これは、ジッターや予測不可能なレイテンシを最小限に抑える上で非常に重要です。
さらに、CPUスケジューラとI/Oサブシステム（ディスクとネットワーク）間の相互作用によって、アプリケーションが経験するエンドツーエンドのスループットとレイテンシが決まります。変更を加える前に、現在の状態（カーネル構成、sysctl、GRUB、ロードされたモジュール）を文書化しておくことをお勧めします。そうすることで、変更によってパフォーマンスが悪化した場合に迅速にロールバックできます。
sysctl による調整によりレイテンシとパフォーマンスを改善
sysctlインターフェースを使用すると、再コンパイルすることなく、/proc/sys経由でカーネルパラメータをその場で変更できます。コンパイルに時間を取られることなくチューニングを行うための理想的な入り口です。
ネットワーク環境において、net.core.rmem_max、net.core.wmem_max、net.ipv4.tcp_congestion_controlといったパラメータは、スループット、レイテンシ、およびTCP接続の動作に直接影響を与えます。トラフィック量の多いWebサーバーや低レイテンシのクラウドインスタンスでは、バッファと輻輳制御アルゴリズムを適切に調整することが不可欠です。
メモリに関しては、vm.swappiness、vm.dirty_ratio、vm.vfs_cache_pressure、vm.overcommit_memoryなどの値によって、スワップの使用量、ページキャッシュの管理方法、仮想メモリの動作を制御できます。スワップネスを下げる（例えば10にする）と、システムがスワップを頻繁に使用するのを防ぎ、ディスクI/Oによるレイテンシの急増を軽減できます。
大規模なデータベースや大量の共有メモリを使用するアプリケーションを扱う場合は、kernel.shmmax、kernel.shmall 、およびfs.file-maxとfs.nr_openを使用して最大オープンファイル数を調整することが非常に重要です。制限値が不適切だと、負荷がかかった状態で診断が困難なボトルネックやエラーが発生する可能性があります。
変更は小規模に行い、監視ツールでその影響を測定してから、/etc/sysctl.conf または /etc/sysctl.d/ にコミットすることをお勧めします。コンテナ環境では、多くのカーネルパラメータがホスト全体に適用されるため、不用意な変更はすべてのサービスに影響を与える可能性があることを覚えておいてください。そのため、sysctl を cgroups および namespaces と組み合わせることはほぼ必須です。
カスタムカーネルのコンパイルと保守
レイテンシを削減したり、不要なオーバーヘッドを排除したり、特殊なハードウェアをサポートしたりしたい場合、カスタムカーネルのコンパイルは依然として強力なツールです。ディストリビューションにはかなり汎用性の高いカーネルが含まれていますが、特定のシナリオでは、特定のカーネルが決定的な違いを生むことがあります。
従来のワークフローでは、 kernel.orgやxanmodのようなパッチを当てたツリーや リキリックス次のようなツールを使う make menuconfig オプションを選択します。.config ファイルをビルドスクリプトと共に独自の Git リポジトリに保存すると、ビルドを再現し、バージョン間の一貫性を維持できます。
Debianまたはその派生ディストリビューションを使用している場合は、「Debian方式」でコンパイルして、カーネル、ヘッダーファイル、および関連ライブラリの.debパッケージを取得するのが非常に便利です。これにより、パッケージをインストールし、独自のレポジトリでバージョン管理を行うだけで、カスタムカーネルを複数のマシンに簡単に展開できます。
現実世界では、古いハードウェアや非常に限られたハードウェアを使用する場合、手動でコンパイルする方が理にかなっていることがよくあります。典型的な例は、 Atom CPUと1GBのRAMを搭載した古いネットブックです。このようなネットブックでは、不要なドライバやサーバーグレードのオプションが満載された最新の汎用カーネルを使用すると、許容できないほどの遅延やCPU使用率の増加が発生します。
一般的な戦略としては、現在のカーネル構成（例えば、/boot ディレクトリから構成ファイルをコピーするなど）を基にして、それを調整したり変更したりする方法があります。デスクトップの対話型応答を優先するために、プリエンプションモデルを「プリエンプティブカーネル（低遅延デスクトップ） 」に変更したり、 BFQなどの特定の I/O スケジューラをモジュールとして追加して、メカニカル ディスクでの動作を改善したりできます。
コンパイルに膨大な時間を費やすのを避けるには、より高性能なマシンでビルドし、必要に応じてクロスコンパイルを利用するのが賢明です（例えば、ARCHと対応するツールチェーンを調整するだけで、x86_64 PCからAtom用の32ビットカーネルをコンパイルできます）。あとは、.debファイルをターゲットマシンにインストールし、GRUBに適切なエントリを追加するだけです。
難しいのはメンテナンスです。新しいカーネルはカナリア諸島のノードでテストし、ブートマネージャに明確なロールバックパスを用意し、移行中にログとメトリクスを記録して、パフォーマンスやドライバの互換性の低下を検出することをお勧めします。
低遅延システム向けのプリエンプションモデルとPREEMPT_RTパッチ
カーネルのプリエンプションモデルは、実行中のタスクをどの程度中断して優先度の高いタスクに引き継がせるかを決定し、応答遅延に直接影響を与えます。これには、標準の設定オプションとリアルタイムパッチの両方が含まれます。
汎用カーネルには、プリエンプションなし（サーバーのスループットを重視）、任意プリエンプション、デスクトップ向けプリエンプティブカーネルなど、いくつかのオプションがあります。デスクトップ向けプリエンプティブカーネルは、対話型アプリケーションの高速応答時間を優先します。この設定を調整することで、デスクトップシステム、オーディオアプリケーション、あるいは負荷の高い古いマシンでもパフォーマンスを大幅に向上させることができます。
さらに一歩進んだ対策が必要な場合は、PREEMPT および PREEMPT_RT パッチが登場し、カーネルの重要な部分を変更して、プリエンプション不可能なセクションを最小限に抑えます。PREEMPT_RT は、産業オートメーション、プロフェッショナルオーディオ、電気通信、高頻度取引など、最悪の場合のレイテンシ（平均だけでなく）が非常に低く予測可能である必要があるシステムを対象としています。
PREEMPT_RT を導入するかどうかの決定は、トレンドに基づくのではなく、レイテンシとジッターの具体的な測定値に基づいて行うべきです。まず、RT ツリーでメンテナンスを複雑にする前に、スケジューラ設定、CPU アフィニティ、sysctl、そして該当する場合はダイナミック ティックレスなどの構成を十分に調査することをお勧めします。
互換性も考慮する必要があります。一部のドライバやサブシステムはRTに完全には対応しておらず、特定のバージョンや追加のパッチが必要になる場合があります。賢明なアプローチは、定期的に同期されるものの、依然として若干遅れているRTブランチに、メインカーネルの新しいバージョンをいつ、どのように統合するかを明確に概説したメンテナンスプランを作成することです。
CPU スケジューリングの調整、ティックレス操作、コア分離
プリエンプション モデルの選択に加えて、特に RHEL のようなエンタープライズ向けディストリビューションでは、CPU スケジューリングとカーネル タイマーの動作を調整することで、レイテンシを微調整できます。
例えば、Red Hat Enterprise Linux 8 には、アイドル状態の CPU 向けにデフォルトでティックレス カーネルが搭載されています。これは、カーネルがアイドル状態のときに定期的な割り込みを回避することで消費電力を削減します。レイテンシに敏感なワークロードの場合、一連のカーネルで動的なティックレス モードを有効にすることで、1 つの CPU (「ホーム カーネル」) がほとんどのタイミング タスクを処理し、残りの CPU は定期的な割り込みから可能な限り解放されます。
この設定は、適切なパラメータを追加することで行われます。 GRUBのカーネルコマンドライン構成を再生成し、RCUスレッドやスレッドなどの重要なカーネルスレッドのアフィニティを調整する bdi-flush、メンテナンス用に予約されたコア内に存在するようになります。
このアプローチは、 `isolcpus`パラメータと組み合わせることで補完できます。このパラメータを使用すると、コアを通常のユーザー空間タスクから分離できます。低遅延が求められるシナリオでは、重要なアプリケーション専用に複数のコアを確保し、システムの残りの部分（デーモン、割り込みなど）は他のコアで処理するのが一般的です。
動的ティックレスモードが動作していることを確認するには、次のような簡単なテストを実行します。 stress またはCPUを1秒間ビジー状態にして観察するスクリプト タイマーティックカウンター 分離されたコアで 1 秒あたりの割り込み数が数千から 1 に減少します。これは、定期的なタイマーが消えたことを示しています。
レイテンシを重視したメモリとストレージの管理
カーネルがメモリとディスクI/Oを管理する方法は、アプリケーションが体感するレイテンシに大きな影響を与えます。特に、データベースや、多くの小さな操作を頻繁に実行するサービスにおいては顕著です。
メモリ面では、vm.swappiness の値を下げることでスワップの使用を最小限に抑え（スワップはほとんどの場合、RAM よりはるかに低速です）、vm.vfs_cache_pressure はシステムが inode および dentry キャッシュを解放する速度を制御し、vm.nr_hugepagesを使用すると、データベースや JVM などの負荷の高い処理用に静的 HugePages を予約できるため、TLB のオーバーヘッドを削減できます。
保管時には、 ディスクの種類に応じた適切なI/Oスケジューラ これは重要です。最近のSSDでは、通常、次の方法を使用することをお勧めします... none o mq-deadline一方、機械式ディスクやマルチタスクシステムでは、公平性を重視したアルゴリズムの方が優れているかもしれない。 咬合力さらに、次のようなオプションを使用してファイルシステムをマウントすると、 noatime y nodiratime ファイルまたはディレクトリにアクセスするたびに不要な書き込みを回避します。
ファイルシステムに関しては、ext4とXFSが依然として最も一般的な選択肢です。適切に調整されたext4は安全な選択肢であり、XFSは高い同時実行性において優れたスケーラビリティを発揮します。非常に負荷の高いシナリオでは、RAID（データベースにはRAID 10、一時的なスクラッチストレージにはRAID 0）と優れたスケジューラを組み合わせることで、平均レイテンシ、そして何よりも変動性を低減できます。
Linux と EC2 での低レイテンシを実現するネットワークとカーネルの最適化
高性能ネットワークアプリケーションでは、レイテンシはハードウェアや距離だけでなく、TCP/IPスタックやカーネル自体の構成にも左右されます。これは、ENAインターフェースを備えたAmazon EC2のようなクラウドインスタンスで特に顕著です。
まず、パケットが通過するネットワークホップ数などの外部要因を減らすことが重要です。より直接的なトポロジーを使用したり、バックエンドに近い場所にロードバランサーを配置したり、最適化された可用性ゾーンを使用したりすることで、オペレーティングシステムに到達する前の移動時間をミリ秒単位で短縮できます。
カーネル内部でのネットワーク設定には、ファイルディスクリプタの増加（ulimit -n） 、 net.core.rmem_max、net.core.wmem_max、net.ipv4.tcp_rmem、net.ipv4.tcp_wmemを使用した受信バッファと送信バッファのサイズ設定、および接続確立遅延を削減するためのTCP Fast Openなどのオプションの有効化が含まれます。
AWS ENA インターフェースでは、割り込み調整が重要な役割を果たします。デフォルトでは、ドライバーはパケットをグループ化して IRQ の数を減らします。 rx-usecsとtx-usecs遅延を最小限に抑えたい場合は、この調整を無効にすることができます。 ethtool -Crx-usecs と tx-usecs をゼロに設定すると、レイテンシは低下しますが、割り込みオーバーヘッドが増加するため、負荷に応じてバランスを見つける必要があります。
irqbalance を使用して IRQ を複数のコアに分散することもできます。また、irqbalance を無効にして、割り込みとネットワークキュー (RSS/RPS) のアフィニティを特定のコアに手動で設定することもできます。これは、超低遅延環境や、DPDK を使用してカーネルスタックの大部分をスキップする場合によく行われます。
考慮すべきもう一つのパラメータは、CPUのCステートです。ディープスリープ状態は消費電力を削減しますが、コアが「起動」する際に遅延が発生します。応答遅延を減らすには、これらのディープ状態を制限することで、消費電力の増加と他のコアのターボブーストのための余裕の減少を受け入れることができます。各環境には、消費電力と得られるマイクロ秒数の最適なバランスが存在します。
CPU、サービス、アプリケーションの最適化によりレイテンシを削減
カーネル自体に加えて、システム上で稼働しているサービスから各アプリケーションの具体的な設定に至るまで、周囲の環境も全体のレイテンシに大きく影響します。
高性能サーバーでは、 本当に必要な悪魔バックエンドマシン上のBluetooth、印刷、ネットワーク自動検出（CUPS、Avahiなど）などのサービスは、CPU、メモリ、I/Oを消費するだけで、何のメリットもありません。 systemctl list-unit-files --state=enabled 不要なものを無効にすることは、最も安価で効果的な方法の 1 つです。
重要なプロセスに優先順位を付けるには、 renice、chrt、tasksetなどのツールを使用できます。プロセスの優先度を調整（renice）、リアルタイムスケジューリングの割り当て（chrt -f 99）、または特定のコアへの割り当て（taskset）を行うことで、他のタスクとの干渉を減らし、データベース、VoIP、ストリーミング、またはトレーディングサービスにおけるCPUの予測可能性を向上させることができます。
アプリケーションレベルでのチューニングは、カーネルチューニングと同様に重要です。NginxやApacheのようなWebサーバーでは、ワーカー、キープアライブ、キャッシュ、圧縮などの微調整が必要です。PostgreSQLやMySQLのようなデータベースでは、低遅延かつ安定したレイテンシを実現するために、バッファサイズ、チェックポイント、接続プール、同期書き込みパラメータの見直しが必要です。
JVMも重要な役割を果たします。G1GCやZGCといったガベージコレクタを選択し、ヒープサイズを調整することで、外部からはレイテンシとして現れる一時停止を減らすことができます。仮想化環境やコンテナ環境では、vCPU、vRAM、I/Oクォータを適切に割り当てることで、後々ディスクキューの無限ループやCPU過負荷として顕在化するサイレントコンテンションを防ぐことができます。
カーネルとシステムの監視とベンチマーク
こうした調整は、その影響を測定しなければ無意味です。重要なのは、継続的な監視と再現可能なパフォーマンス テストを組み合わせることで、カーネルや sysctl へのあらゆる変更を客観的なデータに基づいて評価できるようにすることです。
システムの全体的な状態を確認するには、次のような古典的なツールを使用できます。 htop、vmstat、iotop o sarさらに詳細な情報が必要な場合は、次のようなカーネルツールが役立ちます。 perf と ftraceこれにより、スケジューラ、割り込み、内部呼び出しの動作をかなり正確に追跡できるようになります。
本番環境では、CPUカウンター、I/O、ディスクおよびネットワークのレイテンシ、プロセスキューなどを公開するエクスポーターを備えたPrometheus、collectd、sysstatなどのメトリクスシステムを導入することをお勧めします。Grafanaなどのツールでこれらのデータを可視化することで、エンドユーザーが問題に気づく前に、回帰や異常を検出するのに役立ちます。
ベンチマークテストでは、実際のワークロードを再現し、各変更の「前と後」を比較することが基本となります。sysbench （CPUおよびデータベース用）、fio（ディスク用）、iperf3 （ネットワーク用）などのツールを使用すると、再現可能なシナリオを構築できます。比較結果が長期的に意味を持つように、カーネルバージョン、sysctlの設定、ハードウェア、テストパラメータを文書化することが不可欠です。
実際には、Linuxカーネルの最適化は反復的なプロセスです。一連の調整をテストし、結果を測定し、実際にメリットをもたらすものを残し、それ以外は破棄します。適切な変更ガバナンスがあれば、新しいカーネルバージョン（スケジューラ、グラフィックス、電力、ネットワーク機能の強化を含む最新シリーズなど）の改善を、オンプレミスサーバー、クラウド、あるいは要求の厳しいワークステーションなど、あらゆるアプリケーションに測定可能なメリットとして反映させることができます。
カーネルアーキテクチャに関する知識、sysctlによる微調整、制御されたコンパイル、リアルタイムパッチの選択的な使用、そして優れたメトリクスシステムを組み合わせることで、管理者や運用チームは、些細な問題でハードウェアを変更したり、システムセキュリティを損なったりすることなく、より高速な応答、より低いレイテンシ、そしてより優れた全体的な安定性を実現できます。
