- 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 これらにより、スワップ使用量、ページキャッシュの管理方法、仮想メモリの動作を制御できます。swappiness を下げる（例えば 10 にする）と、システムによるスワップの過剰な使用を防ぎ、ディスク I/O レイテンシの急増を軽減できます。
大規模なデータベースや大量の共有メモリを使用するアプリケーションを扱う場合は、調整が重要です。 kernel.shmmax、kernel.shmall および、開かれるファイルの最大数 fs.file-max と fs.nr_open制限のサイズが適切でない場合は、負荷がかかった状態で診断するのが難しいボトルネックやエラーが発生する可能性があります。
最良のアプローチは、小さな変更を実施し、監視ツールでその影響を測定し、その後 /etc/sysctl.conf または /etc/sysctl.d/ に保存します。コンテナ化された環境では、多くのカーネル パラメータがホストに対してグローバルであることに留意してください。これらを不注意に変更するとすべてのサービスに影響する可能性があるため、sysctl を cgroup および名前空間と組み合わせることはほぼ必須です。
カスタムカーネルのコンパイルと保守
カスタムカーネルをコンパイルすることは、次のような場合に非常に強力なツールです。 レイテンシを削減し、不要なオーバーヘッドを除去し、希少なハードウェアをサポートするディストリビューションには非常に多用途なカーネルが付属していますが、特定のシナリオでは特定のカーネルが大きな違いを生みます。
従来のワークフローでは、 kernel.orgやxanmodのようなパッチを当てたツリーや リキリックス次のようなツールを使う make menuconfig オプションを選択します。.config ファイルをビルドスクリプトと共に独自の Git リポジトリに保存すると、ビルドを再現し、バージョン間の一貫性を維持できます。
Debianやその派生版を使っている場合は、「Debianスタイルカーネル、ヘッダー、および関連ライブラリの.debパッケージを取得します。これにより、パッケージをインストールし、独自のリポジトリでバージョンを管理するだけで、カスタムカーネルを複数のマシンに展開できます。
現実世界では、次のような場合、手動でコンパイルする方が合理的です。 古い、または非常に制限されたハードウェア典型的な例としては 古いネットブック Atom CPU と 1 GB の RAM を搭載していますが、不要なドライバーやサーバー オプションが満載の最新の汎用カーネルでは、許容できないほどの遅延と余分な CPU 消費が発生します。
一般的な戦略としては、現在のカーネル構成から開始することです（たとえば、 /boot 設定）から切り取りや調整ができます。プリエンプションモデルを「プリエンプティブカーネル（低遅延デスクトップ）「インタラクティブなデスクトップの応答を優先したり、特定の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、メンテナンス用に予約されたコア内に存在するようになります。
このアプローチはパラメータ アイソルパスこれにより、コアを通常のユーザー空間タスクから分離できます。低レイテンシのシナリオでは、いくつかのコアを重要なアプリケーション専用に予約し、システムの残りの部分（デーモン、割り込みなど）は他のコアで処理するのが一般的です。
動的ティックレスモードが動作していることを確認するには、次のような簡単なテストを実行します。 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 高速オープン 接続確立の遅延を削減します。
AWS ENA インターフェースでは、割り込み調整が重要な役割を果たします。デフォルトでは、ドライバーはパケットをグループ化して IRQ の数を減らします。 rx-usecsとtx-usecs遅延を最小限に抑えたい場合は、この調整を無効にすることができます。 ethtool -Crx-usecs と tx-usecs をゼロに設定すると、レイテンシは低下しますが、割り込みオーバーヘッドが増加するため、負荷に応じてバランスを見つける必要があります。
また、 irqbalance は複数のコアに IRQ を分散しますまたは、これを無効にして、割り込みとネットワーク キュー (RSS/RPS) アフィニティを特定のコアに手動で設定します。これは、超低レイテンシ環境や、DPDK を使用してカーネル スタックの大部分をスキップする場合に非常に一般的なことです。
考慮すべきもう一つのパラメータは CPU Cステートディープスリープ状態は消費電力を削減しますが、コアが「ウェイクアップ」する際に遅延が発生します。応答レイテンシを削減するには、これらのディープスリープ状態を制限し、消費電力の増加と他のコアのTurbo Boostの余裕の減少を許容することができます。環境ごとに、消費電力とマイクロ秒の短縮の間に最適な値があります。
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 ワーカー、キープアライブ、キャッシュ、圧縮の微調整が必要です。 PostgreSQLまたはMySQL 低く安定したレイテンシを実現するには、バッファ サイズ、チェックポイント、接続プール、同期書き込みパラメータを確認する必要があります。
JVMも役割を果たします。例えば、次のようなガベージコレクターを選択します。 G1GCまたはZGC ヒープサイズを調整することで、外部から見るとレイテンシとして見える一時停止を減らすことができます。仮想化環境やコンテナ環境では、適切な分散が不可欠です。 vCPU、vRAM、I/O クォータ これにより、後でディスク上の無限のキューや CPU の飽和として現れるサイレント競合を回避できます。
カーネルとシステムの監視とベンチマーク
効果を測定しなければ、こうした調整はすべて無駄になります。重要なのは組み合わせることです。 再現可能なパフォーマンステストによる継続的な監視カーネルまたは sysctl へのすべての変更を客観的なデータで評価できるようになります。
システムの全体的な状態を確認するには、次のような古典的なツールを使用できます。 htop、vmstat、iotop o sarさらに詳細な情報が必要な場合は、次のようなカーネルツールが役立ちます。 perf と ftraceこれにより、スケジューラ、割り込み、内部呼び出しの動作をかなり正確に追跡できるようになります。
実稼働環境では、次のようなメトリクスシステムを導入することをお勧めします。 Prometheus、collectd、またはsysstatとエクスポーター CPU カウンター、I/O、ディスクとネットワークのレイテンシ、プロセス キューなどを公開します。Grafana または同様のツールで視覚化されたこのデータは、エンド ユーザーが問題に気付く前に回帰や異常を検出するのに役立ちます。
ベンチマークの目的は、実際のワークロードを再現し、各変更の「前と後」を比較することです。 シスベンチ （CPUおよびデータベース用） FIO （ディスクの場合）または iperf3 （ネットワークの場合）繰り返し可能なシナリオの構築が可能になります。ドキュメント化は不可欠です。 カーネルバージョン、sysctl設定、ハードウェア、テストパラメータ 時間の経過とともに比較が意味を成すようになるためです。
実際には、Linuxカーネルの最適化は反復的なプロセスです。一連の調整をテストし、結果を測定し、実際にメリットをもたらすものを残し、それ以外は破棄します。適切な変更ガバナンスがあれば、新しいカーネルバージョン（スケジューラ、グラフィックス、電力、ネットワーク機能の強化を含む最新シリーズなど）の改善を、オンプレミスサーバー、クラウド、あるいは要求の厳しいワークステーションなど、あらゆるアプリケーションに測定可能なメリットとして反映させることができます。
カーネルアーキテクチャの知識、sysctlによる微調整、制御されたコンパイル、リアルタイムパッチの選択的な使用、そして優れたメトリクスシステムの組み合わせにより、管理者や運用チームは以下を達成できます。 応答速度の向上、レイテンシの低減、全体的な安定性の向上 ちょっとしたきっかけでハードウェアを変更したり、システムのセキュリティを危険にさらしたりする必要はありません。
