システムの状態とパフォーマンスの監視と管理
システムのスループット、レイテンシー、および電力消費の最適化
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
- Jira の Web サイトにログインします。
- 上部のナビゲーションバーで Create をクリックします。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- ダイアログの下部にある Create をクリックします。
第1章 TuneD を使い始める リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、TuneD アプリケーションを使用して、さまざまなユースケースに合わせてシステムのパフォーマンスプロファイルを最適化できます。
1.1. TuneD の目的 リンクのコピーリンクがクリップボードにコピーされました!
TuneD は、システムを監視し、特定のワークロードでパフォーマンスを最適化するサービスです。TuneD の中核となるのは、さまざまなユースケースに合わせてシステムをチューニングする プロファイル です。
TuneD には、以下のようなユースケース用に定義されたプロファイルが多数同梱されています。
- 高スループット
- 低レイテンシー
- 節電
各プロファイル向けに定義されたルールを変更し、特定のデバイスのチューニング方法をカスタマイズできます。別のプロファイルに切り替えたり、TuneD を非アクティブにすると、以前のプロファイルによるシステム設定への変更はすべて、元の状態に戻ります。
また、TuneD を設定してデバイスの使用状況の変化に対応し、設定を調整して、アクティブなデバイスのパフォーマンスを向上させ、非アクティブなデバイスの消費電力を削減することもできます。
1.2. TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
システムを詳細に分析することは、非常に時間のかかる作業です。TuneD では、一般的なユースケースに合わせて定義済みのプロファイルを多数提供しています。プロファイルを作成、変更、および削除することも可能です。
TuneD で提供されるプロファイルは、以下のカテゴリーに分類されます。
- 省電力プロファイル
- パフォーマンス重視プロファイル
performance-boosting プロファイルの場合は、次の側面に焦点が置かれます。
- ストレージおよびネットワークに対して少ないレイテンシー
- ストレージおよびネットワークの高い処理能力
- 仮想マシンのパフォーマンス
- 仮想化ホストのパフォーマンス
プロファイル設定の構文
tuned.conf ファイルは、1 つの [main] セクションとプラグインインスタンスを設定するためのその他のセクションが含まれます。ただし、すべてのセクションはオプションです。
ハッシュ記号 (#) で始まる行はコメントです。
1.3. デフォルトの TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
インストール時に、システムの最適なプロファイルが自動的に選択されます。現時点では、以下のカスタマイズ可能なルールに従ってデフォルトのプロファイルが選択されます。
| 環境 | デフォルトプロファイル | 目的 |
|---|---|---|
| コンピュートノード |
| 最適なスループットパフォーマンス |
| 仮想マシン |
|
ベストパフォーマンスベストパフォーマンスが重要でない場合は、 |
| その他のケース |
| パフォーマンスと電力消費の調和 |
1.4. マージされた TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
試験目的で提供された機能として、複数のプロファイルを一度に選択することができます。TuneD は、読み込み中にマージを試みます。
競合が発生した場合は、最後に指定されたプロファイルの設定が優先されます。
例1.1 仮想ゲストの低消費電力
以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。
tuned-adm profile virtual-guest powersave
# tuned-adm profile virtual-guest powersave
マージは自動的に行われ、使用されるパラメーターの組み合わせが適切であるかどうかはチェックされません。結果として、この機能は一部のパラメーターを逆に調整する可能性があります。これは逆効果になる可能性があります。たとえば、throughput-performance プロファイルで高スループットにディスクを設定し、同時に、spindown-disk プロファイルでディスクスピンダウンを低い値に設定します。
1.5. TuneD プロファイルの場所 リンクのコピーリンクがクリップボードにコピーされました!
TuneD は、次のディレクトリーにプロファイルを保存します。
/usr/lib/tuned/-
ディストリビューション固有のプロファイルは、このディレクトリーに保存されます。各プロファイルには独自のディレクトリーがあります。プロファイルは
tuned.confという名前の主要設定ファイルと、ヘルパースクリプトなどの他の任意のファイルから構成されます。 /etc/tuned/-
プロファイルをカスタマイズする必要がある場合は、プロファイルのカスタマイズに使用されるディレクトリーにプロファイルディレクトリーをコピーします。同じ名前のプロファイルが 2 つある場合、カスタムのプロファイルは、
/etc/tuned/に置かれています。
1.6. RHEL とともに配布される TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
以下は、Red Hat Enterprise Linux に TuneD とともにインストールされるプロファイルのリストです。
利用可能な製品固有またはサードパーティーの TuneD プロファイルが複数存在する可能性があります。このようなプロファイルは通常、個別の RPM パッケージで提供されます。
balancedデフォルトの省電力プロファイル。パフォーマンスと電力消費のバランスを取ることが目的です。可能な限り、自動スケーリングと自動チューニングを使用します。唯一の欠点はレイテンシーが増加することです。今回の TuneD リリースでは、CPU、ディスク、オーディオ、およびビデオプラグインを有効にし、
conservativeCPU ガバナーを有効にします。radeon_powersaveオプションは、dpm-balanced値に対応している場合はその値を使用し、それ以外の場合はautoに設定されます。energy_performance_preference属性をnormalの電力設定に変更します。また、scaling_governorポリシー属性をconservativeまたはpowersaveCPU ガバナーのいずれかに変更します。powersave省電力パフォーマンスを最大化するプロファイル。実際の電力消費を最小化するためにパフォーマンスを調整できます。今回の TuneD リリースでは、SATA ホストアダプターの USB 自動サスペンド、WiFi 省電力、および Aggressive Link Power Management (ALPM) の省電力を有効にします。また、ウェイクアップ率が低いシステムのマルチコア省電力がスケジュールされ、
ondemandガバナーがアクティブ化されます。さらに、AC97 音声省電力と、システムに応じて HDA-Intel 省電力 (10 秒のタイムアウト) が有効になります。KMS が有効なサポート対象の Radeon グラフィックカードがシステムに搭載されている場合、プロファイルは自動省電力に設定されます。ASUS Eee PC では、動的な Super Hybrid Engine が有効になります。energy_performance_preference属性をpowersaveまたはpower電力設定に変更します。また、scaling_governorポリシー属性をondemandまたはpowersaveCPU ガバナーのいずれかに変更します。注記場合によっては、
balancedプロファイルの方が、powersaveプロファイルよりも効率的です。定義された量の作業を行う場合 (たとえば、動画ファイルをトランスコードする必要がある場合) を考えてください。トランスコードがフルパワーで実行される場合に、マシンの電力消費が少なくなることがあります。これは、タスクがすぐに完了し、マシンがアイドル状態になり、非常に効率的な省電力モードに自動的に切り替わることがあるためです。その一方で、調整されたマシンでファイルをトランスコードすると、マシンはトランスコード中に少ない電力を消費しますが、処理に時間がかかり、全体的な消費電力は高くなることがあります。
このため、一般的に
balancedプロファイルが優れたオプションになる場合があります。throughput-performance高スループットに最適化されたサーバープロファイル。これにより、節電メカニズムが無効になり、
sysctlが有効になるため、ディスクおよびネットワーク IO のスループットパフォーマンスが向上します。CPU ガバナーはperformanceに設定されます。energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。accelerator-performance-
accelerator-performanceプロファイルには、throughput-performanceプロファイルと同じチューニングが含まれます。さらに、CPU を低い C 状態にロックし、レイテンシーが 100us 未満になるようにします。これにより、GPU などの特定のアクセラレーターのパフォーマンスが向上します。 latency-performance低レイテンシーに最適化されたサーバープロファイル。省電力メカニズムが無効になり、レイテンシーを向上させる
sysctl設定が有効になります。CPU ガバナーはperformanceに設定され、CPU は低い C 状態にロックされます (PM QoS を使用)。energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。network-latency低レイテンシーネットワークチューニング向けプロファイル。
latency-performanceプロファイルに基づきます。さらに、transparent huge page と NUMA バランシングを無効にし、他のネットワーク関連のsysctlパラメーターをいくつか調整します。latency-performanceプロファイルを継承します。また、energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。hpc-compute-
高パフォーマンスコンピューティング向けに最適化されたプロファイル。
latency-performanceプロファイルに基づきます。 network-throughputスループットネットワークチューニング向けプロファイル。
throughput-performanceプロファイルに基づきます。さらに、カーネルネットワークバッファーを増やします。latency-performanceまたはthroughput-performanceプロファイルのいずれかを継承します。また、energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。virtual-guestthroughput-performanceプロファイルに基づく Red Hat Enterprise 9 仮想マシンおよび VMWare ゲスト向けプロファイル。仮想メモリーのスワップの減少や、ディスクの readahead 値の増加などが行われます。ディスクバリアは無効になりません。throughput-performanceプロファイルを継承します。また、energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。virtual-hostthroughput-performanceプロファイルに基づいて仮想ホスト用に設計されたプロファイル。他のタスクの中でも特に、仮想メモリーのスワップを減らし、ディスクの先読み値を増やし、ダーティーページの書き戻しというより積極的な値を可能にします。throughput-performanceプロファイルを継承します。また、energy_performance_preferenceおよびscaling_governor属性をperformanceプロファイルに変更します。oracle-
throughput-performanceプロファイルに基づいて Oracle データベースの負荷向けに最適化されたプロファイル。さらに、transparent huge page を無効にし、他のパフォーマンス関連のカーネルパラメーターを変更します。このプロファイルは、tuned-profiles-oracleパッケージで利用できます。 desktop-
balancedプロファイルに基づく、デスクトップに最適化されたプロファイル。対話型アプリケーションの応答を向上させるスケジューラーオートグループが有効になります。 optimize-serial-consoleprintk 値を減らすことで、シリアルコンソールへの I/O アクティビティーを調整するプロファイル。これにより、シリアルコンソールの応答性が向上します。このプロファイルは、他のプロファイルのオーバーレイとして使用することが意図されています。以下に例を示します。
tuned-adm profile throughput-performance optimize-serial-console
# tuned-adm profile throughput-performance optimize-serial-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow mssql-
Microsoft SQL Server に提供されるプロファイル。
throughput-performanceプロファイルに基づきます。 intel-sstユーザー定義の Intel Speed Select Technology 設定で最適化されたプロファイル。このプロファイルは、他のプロファイルのオーバーレイとして使用することが意図されています。以下に例を示します。
tuned-adm profile cpu-partitioning intel-sst
# tuned-adm profile cpu-partitioning intel-sstCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7. TuneD cpu-partitioning プロファイル リンクのコピーリンクがクリップボードにコピーされました!
レイテンシーに敏感なワークロード用に Red Hat Enterprise Linux 9 を調整する場合は、cpu-partitioning TuneD プロファイルを使用することが推奨されます。
Red Hat Enterprise Linux 9 以前では、低レイテンシーの Red Hat ドキュメントで、低レイテンシーのチューニングを実現するために必要な低レベルの手順が数多く説明されていました。Red Hat Enterprise Linux 9 では、cpu-partitioning TuneD プロファイルを使用することで、低レイテンシーのチューニングをより効率的に実行できます。このプロファイルは、個々の低レイテンシーアプリケーションの要件に従って簡単にカスタマイズできます。
以下の図は、cpu-partitioning プロファイルの使用方法を示す例になります。この例では、CPU とノードのレイアウトを使用します。
図1.1 cpu-partitioning の図
/etc/tuned/cpu-partitioning-variables.conf ファイルで cpu-partitioning プロファイルを設定するには、以下の設定オプションを使用します。
- 負荷分散機能のある分離された CPU
cpu-partitioning の図では、4 から 23 までの番号が付けられたブロックが、デフォルトの分離された CPU です。カーネルスケジューラーのプロセスの負荷分散は、この CPU で有効になります。これは、カーネルスケジューラーの負荷分散を必要とする複数のスレッドを使用した低レイテンシープロセス用に設計されています。
isolated_cores=cpu-listオプションを使用して、/etc/tuned/cpu-partitioning-variables.confファイルで cpu-partitioning プロファイルを設定できます。このオプションは、カーネルスケジューラーの負荷分散を使用する分離する CPU をリスト表示します。分離された CPU のリストはコンマ区切りで表示するか、
3-5のようにハイフンを使用して範囲を指定できます。このオプションは必須です。このリストにない CPU は、自動的にハウスキーピング CPU と見なされます。- 負荷分散を行わずに分離した CPU
cpu-partitioning の図では、2 と 3 の番号が付けられたブロックは、追加のカーネルスケジューラープロセスの負荷分散を提供しない分離された CPU です。
/etc/tuned/cpu-partitioning-variables.confファイルで cpu-partitioning プロファイルを設定するには、no_balance_cores=cpu-listオプションを使用します。このオプションは、カーネルスケジューラーの負荷分散を使用しない CPU を分離するようにリスト表示します。no_balance_coresオプションの指定は任意ですが、このリストの CPU は、isolated_coresリストに記載されている CPU のサブセットである必要があります。このような CPU を使用するアプリケーションスレッドは、各 CPU に個別にピン留めする必要があります。
- ハウスキーピング CPU
-
cpu-partitioning-variables.confファイル内で分離されていない CPU は、自動的にハウスキーピング CPU と見なされます。ハウスキーピング CPU では、すべてのサービス、デーモン、ユーザープロセス、移動可能なカーネルスレッド、割り込みハンドラー、およびカーネルタイマーの実行が許可されます。
1.8. 低レイテンシーチューニングへの TuneD の cpu-partitioning プロファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、TuneD の cpu-partitioning プロファイルを使用して、低レイテンシーになるようにシステムをチューニングする方法を説明します。これは、cpu-partitioning の図で説明されているように、cpu-partitioning と CPU レイアウトを使用できる低レイテンシーのアプリケーションの例を使用します。
この場合のアプリケーションでは、以下を使用します。
- ネットワークからデータを読み込む 1 つの専用リーダースレッドが、CPU 2 に固定されます。
- このネットワークデータを処理する多数のスレッドは、CPU 4-23 に固定されます。
- 処理されたデータをネットワークに書き込む専用のライタースレッドは、CPU 3 に固定されます。
前提条件
-
dnf install tuned-profiles-cpu-partitioningコマンドを root で使用して、cpu-partitioningTuneD プロファイルをインストールしている。
手順
/etc/tuned/cpu-partitioning-variables.confファイルを次のように編集します。isolation_cores=${f:calc_isolated_cores:1}行をコメントアウトします。isolated_cores=${f:calc_isolated_cores:1}# isolated_cores=${f:calc_isolated_cores:1}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 分離された CPU について次の情報を追加します。
# All isolated CPUs: isolated_cores=2-23 # Isolated CPUs without the kernel’s scheduler load balancing: no_balance_cores=2,3
# All isolated CPUs: isolated_cores=2-23 # Isolated CPUs without the kernel’s scheduler load balancing: no_balance_cores=2,3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cpu-partitioningTuneD プロファイルを設定します。tuned-adm profile cpu-partitioning
# tuned-adm profile cpu-partitioningCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムを再起動します。
再起動後、システムは、cpu-partitioning の図の分離に従って、低レイテンシーにチューニングされます。このアプリケーションでは、タスクセットを使用して、リーダーおよびライターのスレッドを CPU 2 および 3 に固定し、残りのアプリケーションスレッドを CPU 4-23 に固定できます。
検証
分離された CPU が
Cpus_allowed_listフィールドに反映されていないことを確認します。cat /proc/self/status | grep Cpu Cpus_allowed: 003 Cpus_allowed_list: 0-1
# cat /proc/self/status | grep Cpu Cpus_allowed: 003 Cpus_allowed_list: 0-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのプロセスのアフィニティーを確認するには、次のように入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TuneD は、一部のプロセス (主にカーネルプロセス) のアフィニティーを変更できません。この例では、PID 4 および 9 のプロセスは変更されません。
1.9. cpu-partitioning TuneD プロファイルのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
TuneD プロファイルを拡張して、追加のチューニング変更を行うことができます。
たとえば、cpu-partitioning プロファイルは、cstate=1 を使用する CPU を設定します。cpu-partitioning プロファイルを使用しながら、cstate1 から cstate0 に CPU の cstate を変更するために、以下の手順では my_profile という名前の新しい TuneD プロファイルを説明しています。このプロファイルは、cpu-partitioning プロファイルを継承した後、C state-0 を設定します。
手順
/etc/tuned/my_profileディレクトリーを作成します。mkdir /etc/tuned/my_profile
# mkdir /etc/tuned/my_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow このディレクトリーに
tuned.confファイルを作成し、次の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいプロファイルを使用します。
tuned-adm profile my_profile
# tuned-adm profile my_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
この共有例では、再起動は必要ありません。ただし、my_profile プロファイルの変更を有効にするために再起動が必要な場合は、マシンを再起動します。
1.10. RHEL とともに配布されるリアルタイムの TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
リアルタイムプロファイルは、リアルタイムカーネルを実行するシステムを対象としています。特殊なカーネルビルドなしでは、システムはリアルタイムになりません。RHEL では、このプロファイルは追加のリポジトリーから利用できます。
利用できるリアルタイムプロファイルは以下の通りです。
リアルタイムベアメタルのリアルタイムシステムで使用します。
tuned-profiles-realtimeパッケージにより提供されます。これは、RT リポジトリーまたは NFV リポジトリーから入手できます。realtime-virtual-hostリアルタイムに設定された仮想ホストで使用します。
NFV リポジトリーから利用できる
tuned-profiles-nfv-hostパッケージにより提供されます。realtime-virtual-guestリアルタイムに設定された仮想化ゲストで使用します。
NFV リポジトリーから利用できる
tuned-profiles-nfv-guestパッケージにより提供されます。
1.11. TuneD の静的および動的チューニング リンクのコピーリンクがクリップボードにコピーされました!
TuneD が適用するシステムチューニングの 2 つのカテゴリー (static と dynamic) の違いを理解することは、特定の状況や目的にどちらを使用するかを決定する際に重要です。
- 静的なチューニング
-
主に、事前定義された
sysctl設定およびsysfs設定の適用と、ethtoolなどの複数の設定ツールのワンショットアクティベーションから構成されます。 - 動的チューニング
システムのアップタイム中に、さまざまなシステムコンポーネントがどのように使用されているかを監視します。TuneD は、その監視情報に基づいてシステム設定を動的に調整します。
たとえば、ハードドライブは起動時およびログイン時に頻繁に使用されますが、Web ブラウザーや電子メールクライアントなどのアプリケーションをユーザーが主に使用する場合はほとんど使用されません。同様に、CPU とネットワークデバイスは、異なるタイミングで使用されます。TuneD は、このようなコンポーネントのアクティビティーを監視し、その使用の変化に反応します。
デフォルトでは、動的チューニングは無効になっています。これを有効にするには、
/etc/tuned/tuned-main.confファイルを編集して、dynamic_tuningオプションを1に変更します。TuneD は、システムの統計を定期的に分析してから、その統計を使用してシステムのチューニング設定を更新します。これらの更新間の時間間隔を秒単位で設定するには、update_intervalオプションを使用します。現在実装されている動的チューニングアルゴリズムは、パフォーマンスと省電力のバランスを取ろうとし、パフォーマンスプロファイルで無効になります。各プラグインのダイナミックチューニングは、TuneD プロファイルで有効または無効にできます。
例1.2 ワークステーションでの静的および動的のチューニング
一般的なオフィスワークステーションでは、イーサネットネットワークインターフェイスは常に非アクティブの状態です。少数の電子メールのみが出入りするか、一部の Web ページが読み込まれている可能性があります。
このような負荷の場合、ネットワークインターフェイスはデフォルト設定のように常に最高速度で動作する必要はありません。TuneD には、ネットワークデバイスを監視してチューニングを行うプラグインがあり、これによりこの低いアクティビティーを検出して、自動的にそのインターフェイスの速度を下げることができるため、通常は消費電力が少なくなります。
DVD イメージをダウンロードしているとき、または大きな添付ファイル付きのメールが開いているときなど、インターフェイスのアクティビティーが長期間にわたって増加した場合は、TuneD がこれを検出し、アクティビティーレベルが高い間にインターフェイスの速度を最大に設定します。
この原則は、CPU およびディスクの他のプラグインにも使用されます。
1.12. TuneD の no-daemon モード リンクのコピーリンクがクリップボードにコピーされました!
TuneD は、常駐メモリーを必要としない no-daemon モードで実行できます。このモードでは、TuneD が設定を適用して終了します。
デフォルトでは、このモードには、以下のように多くの TuneD 機能がないため、no-daemon モードが無効になっています。
- D-Bus サポート
- ホットプラグサポート
- 設定のロールバックサポート
no-daemon モードを有効にするには、/etc/tuned/tuned-main.conf ファイルに以下の行を含めます。
daemon = 0
daemon = 0
1.13. TuneD のインストールと有効化 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、TuneD アプリケーションをインストールして有効にし、TuneD プロファイルをインストールして、システムにデフォルトの TuneD プロファイルをあらかじめ設定します。
手順
TuneDパッケージをインストールします。dnf install tuned
# dnf install tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneDサービスを有効にして開始します。systemctl enable --now tuned
# systemctl enable --now tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: リアルタイムシステム用の TuneD プロファイルをインストールします。
リアルタイムシステムの TuneD プロファイルの場合は、
rhel-9リポジトリーを有効にします。subscription-manager repos --enable=rhel-9-for-x86_64-nfv-beta-rpms
# subscription-manager repos --enable=rhel-9-for-x86_64-nfv-beta-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow インストールします。
dnf install tuned-profiles-realtime tuned-profiles-nfv
# dnf install tuned-profiles-realtime tuned-profiles-nfvCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD プロファイルがアクティブで、適用されていることを確認します。
tuned-adm active Current active profile: throughput-performance
$ tuned-adm active Current active profile: throughput-performanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TuneD が自動的にプリセットするアクティブなプロファイルは、マシンのタイプとシステム設定によって異なります。
tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.14. 利用可能な TuneD プロファイルのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、使用しているシステムで現在利用可能なTuneDプロファイルのリストを表示します。
手順
システムで使用可能なすべてのTuneDプロファイルをリスト表示するには、次を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在アクティブなプロファイルのみを表示する場合は、次のコマンドを使用します。
tuned-adm active Current active profile: throughput-performance
$ tuned-adm active Current active profile: throughput-performanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.15. TuneD プロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、選択した TuneD プロファイルを有効にします。
前提条件
-
TuneDサービスが実行中である。詳細は、TuneD のインストールと有効化 を参照してください。
手順
オプション: システムに最適なプロファイルを TuneD に推奨させることができます。
tuned-adm recommend throughput-performance
# tuned-adm recommend throughput-performanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルをアクティブ化します。
tuned-adm profile selected-profile
# tuned-adm profile selected-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow または、複数のプロファイルを組み合わせてアクティブ化することもできます。
tuned-adm profile selected-profile1 selected-profile2
# tuned-adm profile selected-profile1 selected-profile2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例1.3 低消費電力向けに最適化された仮想マシン
以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。
tuned-adm profile virtual-guest powersave
# tuned-adm profile virtual-guest powersaveCopy to Clipboard Copied! Toggle word wrap Toggle overflow お使いのシステムで現在アクティブな TuneD プロファイルを表示します。
tuned-adm active Current active profile: selected-profile
# tuned-adm active Current active profile: selected-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムを再起動します。
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TuneD プロファイルがアクティブで、適用されていることを確認します。
tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.16. TuneD D-Bus インターフェイスの使用 リンクのコピーリンクがクリップボードにコピーされました!
TuneD D-Bus インターフェイスを介してランタイム時に TuneD と直接通信し、さまざまな TuneD サービスを制御できます。
D-Bus API にアクセスするには、busctl または dbus-send コマンドを使用できます。
busctl コマンドまたは dbus-send コマンドを使用できますが、busctl コマンドは systemd の一部であるため、ほとんどのホストにすでに存在しています。
1.16.1. TuneD D-Bus インターフェイスを使用した利用可能な TuneD D-Bus API メソッドの表示 リンクのコピーリンクがクリップボードにコピーされました!
TuneD D-Bus インターフェイスを使用すると、TuneD で使用できる D-Bus API メソッドを確認できます。
前提条件
- TuneD サービスが実行されている。詳細は、TuneD のインストールと有効化 を参照してください。
手順
利用可能な TuneD API メソッドを確認するには、次のコマンドを実行します。
busctl introspect com.redhat.tuned /Tuned com.redhat.tuned.control
$ busctl introspect com.redhat.tuned /Tuned com.redhat.tuned.controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 利用可能なさまざまなメソッドの説明は、TuneD のアップストリームリポジトリー に記載されています。
1.16.2. TuneD D-Bus インターフェイスを使用したアクティブな TuneD プロファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
TuneD D-Bus インターフェイスを使用して、アクティブな TuneD プロファイルを必要な TuneD プロファイルに置き換えることができます。
前提条件
- TuneD サービスが実行されている。詳細は、TuneD のインストールと有効化 を参照してください。
手順
アクティブな TuneD プロファイルを変更するには、次のコマンドを実行します。
busctl call com.redhat.tuned /Tuned com.redhat.tuned.control switch_profile s profile (bs) true "OK"
$ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control switch_profile s profile (bs) true "OK"Copy to Clipboard Copied! Toggle word wrap Toggle overflow profile は、必要なプロファイルの名前に置き換えます。
検証
現在アクティブな TuneD プロファイルを表示するには、次のコマンドを実行します。
busctl call com.redhat.tuned /Tuned com.redhat.tuned.control active_profile s "profile"
$ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control active_profile s "profile"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.17. TuneD の無効化 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、TuneD を無効にし、影響を受けるすべてのシステム設定を TuneD が変更する前の元の状態にリセットします。
手順
すべてのチューニングを一時的に無効にするには、次のコマンドを実行します。
tuned-adm off
# tuned-adm offCopy to Clipboard Copied! Toggle word wrap Toggle overflow チューニングは、
TuneDサービスの再起動後に再度適用されます。または、
TuneDサービスを完全に停止して無効にするには、次のようにします。systemctl disable --now tuned
# systemctl disable --now tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第2章 TuneD プロファイルのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
TuneDプロファイルを作成または変更して、ユースケースに合わせてシステムパフォーマンスを最適化できます。
前提条件
- TuneD のインストールと有効化 に詳述されているように、TuneD をインストールおよび有効化します。
2.1. TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
システムを詳細に分析することは、非常に時間のかかる作業です。TuneD では、一般的なユースケースに合わせて定義済みのプロファイルを多数提供しています。プロファイルを作成、変更、および削除することも可能です。
TuneD で提供されるプロファイルは、以下のカテゴリーに分類されます。
- 省電力プロファイル
- パフォーマンス重視プロファイル
performance-boosting プロファイルの場合は、次の側面に焦点が置かれます。
- ストレージおよびネットワークに対して少ないレイテンシー
- ストレージおよびネットワークの高い処理能力
- 仮想マシンのパフォーマンス
- 仮想化ホストのパフォーマンス
プロファイル設定の構文
tuned.conf ファイルは、1 つの [main] セクションとプラグインインスタンスを設定するためのその他のセクションが含まれます。ただし、すべてのセクションはオプションです。
ハッシュ記号 (#) で始まる行はコメントです。
2.2. デフォルトの TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
インストール時に、システムの最適なプロファイルが自動的に選択されます。現時点では、以下のカスタマイズ可能なルールに従ってデフォルトのプロファイルが選択されます。
| 環境 | デフォルトプロファイル | 目的 |
|---|---|---|
| コンピュートノード |
| 最適なスループットパフォーマンス |
| 仮想マシン |
|
ベストパフォーマンスベストパフォーマンスが重要でない場合は、 |
| その他のケース |
| パフォーマンスと電力消費の調和 |
2.3. マージされた TuneD プロファイル リンクのコピーリンクがクリップボードにコピーされました!
試験目的で提供された機能として、複数のプロファイルを一度に選択することができます。TuneD は、読み込み中にマージを試みます。
競合が発生した場合は、最後に指定されたプロファイルの設定が優先されます。
例2.1 仮想ゲストの低消費電力
以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。
tuned-adm profile virtual-guest powersave
# tuned-adm profile virtual-guest powersave
マージは自動的に行われ、使用されるパラメーターの組み合わせが適切であるかどうかはチェックされません。結果として、この機能は一部のパラメーターを逆に調整する可能性があります。これは逆効果になる可能性があります。たとえば、throughput-performance プロファイルで高スループットにディスクを設定し、同時に、spindown-disk プロファイルでディスクスピンダウンを低い値に設定します。
2.4. TuneD プロファイルの場所 リンクのコピーリンクがクリップボードにコピーされました!
TuneD は、次のディレクトリーにプロファイルを保存します。
/usr/lib/tuned/-
ディストリビューション固有のプロファイルは、このディレクトリーに保存されます。各プロファイルには独自のディレクトリーがあります。プロファイルは
tuned.confという名前の主要設定ファイルと、ヘルパースクリプトなどの他の任意のファイルから構成されます。 /etc/tuned/-
プロファイルをカスタマイズする必要がある場合は、プロファイルのカスタマイズに使用されるディレクトリーにプロファイルディレクトリーをコピーします。同じ名前のプロファイルが 2 つある場合、カスタムのプロファイルは、
/etc/tuned/に置かれています。
2.5. TuneD プロファイル間の継承 リンクのコピーリンクがクリップボードにコピーされました!
TuneDプロファイルは、他のプロファイルを基にして、親プロファイルの特定の側面のみを変更できます。
TuneD プロファイルの [main] セクションは、include オプションを認識します。
[main] include=parent
[main]
include=parent
親 プロファイルの設定はすべて、この 子 プロファイルに読み込まれます。以下のセクションでは、子 プロファイルは、親 プロファイルから継承された特定の設定をオーバーライドするか、親 プロファイルに表示されない新しい設定を追加します。
/usr/lib/tuned/ にあらかじめインストールしておいたプロファイルでパラメーターをいくつか調整するだけで、/etc/tuned/ に独自の 子 プロファイルを作成できます。
TuneD のアップグレード後などに、親 プロファイルが更新されると、この変更は 子 プロファイルに反映されます。
例2.2 バランスの取れた省電力プロファイル
以下は、balanced プロファイルを拡張し、すべてのデバイスの Aggressive Link Power Management (ALPM) を最大省電力に設定するカスタムプロファイルの例です。
[main] include=balanced [scsi_host] alpm=min_power
[main]
include=balanced
[scsi_host]
alpm=min_power
2.6. TuneD の静的および動的チューニング リンクのコピーリンクがクリップボードにコピーされました!
TuneD が適用するシステムチューニングの 2 つのカテゴリー (static と dynamic) の違いを理解することは、特定の状況や目的にどちらを使用するかを決定する際に重要です。
- 静的なチューニング
-
主に、事前定義された
sysctl設定およびsysfs設定の適用と、ethtoolなどの複数の設定ツールのワンショットアクティベーションから構成されます。 - 動的チューニング
システムのアップタイム中に、さまざまなシステムコンポーネントがどのように使用されているかを監視します。TuneD は、その監視情報に基づいてシステム設定を動的に調整します。
たとえば、ハードドライブは起動時およびログイン時に頻繁に使用されますが、Web ブラウザーや電子メールクライアントなどのアプリケーションをユーザーが主に使用する場合はほとんど使用されません。同様に、CPU とネットワークデバイスは、異なるタイミングで使用されます。TuneD は、このようなコンポーネントのアクティビティーを監視し、その使用の変化に反応します。
デフォルトでは、動的チューニングは無効になっています。これを有効にするには、
/etc/tuned/tuned-main.confファイルを編集して、dynamic_tuningオプションを1に変更します。TuneD は、システムの統計を定期的に分析してから、その統計を使用してシステムのチューニング設定を更新します。これらの更新間の時間間隔を秒単位で設定するには、update_intervalオプションを使用します。現在実装されている動的チューニングアルゴリズムは、パフォーマンスと省電力のバランスを取ろうとし、パフォーマンスプロファイルで無効になります。各プラグインのダイナミックチューニングは、TuneD プロファイルで有効または無効にできます。
例2.3 ワークステーションでの静的および動的のチューニング
一般的なオフィスワークステーションでは、イーサネットネットワークインターフェイスは常に非アクティブの状態です。少数の電子メールのみが出入りするか、一部の Web ページが読み込まれている可能性があります。
このような負荷の場合、ネットワークインターフェイスはデフォルト設定のように常に最高速度で動作する必要はありません。TuneD には、ネットワークデバイスを監視してチューニングを行うプラグインがあり、これによりこの低いアクティビティーを検出して、自動的にそのインターフェイスの速度を下げることができるため、通常は消費電力が少なくなります。
DVD イメージをダウンロードしているとき、または大きな添付ファイル付きのメールが開いているときなど、インターフェイスのアクティビティーが長期間にわたって増加した場合は、TuneD がこれを検出し、アクティビティーレベルが高い間にインターフェイスの速度を最大に設定します。
この原則は、CPU およびディスクの他のプラグインにも使用されます。
2.7. TuneD プラグイン リンクのコピーリンクがクリップボードにコピーされました!
プラグインは、TuneD がシステムのさまざまなデバイスを監視または最適化するために使用する TuneD プロファイルのモジュールです。
TuneD では、以下の 2 つのタイプのプラグインを使用します。
- プラグインの監視
モニタリングプラグインは、稼働中のシステムから情報を取得するために使用されます。監視プラグインの出力は、動的チューニング向けチューニングプラグインで使用できます。
監視プラグインは、有効ないずれかのチューニングプラグインでメトリックが必要な場合に必ず自動的にインスタンス化されます。2 つのチューニングプラグインで同じデータが必要な場合は、監視プラグインのインスタンスが 1 つだけ作成され、データが共有されます。
- プラグインのチューニング
- 各チューニングプラグインは、個々のサブシステムをチューニングし、TuneD プロファイルから設定されたいくつかのパラメーターを取得します。各サブシステムには、チューニングプラグインの個別インスタンスで処理される複数のデバイス (複数の CPU やネットワークカードなど) を含めることができます。また、個別デバイスの特定の設定もサポートされます。
TuneD プロファイルのプラグインの構文
プラグインインスタンスが記述されるセクションは、以下のように書式化されます。
[NAME] type=TYPE devices=DEVICES
[NAME]
type=TYPE
devices=DEVICES
- NAME
- ログで使用されるプラグインインスタンスの名前です。これは、任意の文字列です。
- TYPE
- チューニングプラグインのタイプです。
- DEVICES
このプラグインインスタンスが処理するデバイスのリストです。
deviceの行には、リスト、ワイルドカード (*)、否定 (!) が含まれます。deviceの行がないと、TYPE のシステムに現在または後で接続されるすべてのデバイスは、プラグインインスタンスにより処理されます。devices=*オプションを使用する場合と同じです。例2.4 ブロックデバイスとプラグインのマッチング
次の例では、
sda、sdbなどsdで始まるすべてのブロックデバイスに一致し、それらに対する境界は無効にしない例になります。[data_disk] type=disk devices=sd* disable_barriers=false
[data_disk] type=disk devices=sd* disable_barriers=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例は、
sda1およびsda2を除くすべてのブロックデバイスと一致します。[data_disk] type=disk devices=!sda1, !sda2 disable_barriers=false
[data_disk] type=disk devices=!sda1, !sda2 disable_barriers=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
プラグインのインスタンスを指定しないと、そのプラグインは有効になりません。
このプラグインがより多くのオプションに対応していると、プラグインセクションでも指定できます。このオプションが指定されておらず、含まれているプラグインでこれまで指定しなかった場合は、デフォルト値が使用されます。
短いプラグイン構文
プラグインインスタンスにカスタム名を付ける必要がなく、設定ファイルにインスタンスの定義が 1 つしかない場合、TuneD は以下の簡単な構文に対応します。
[TYPE] devices=DEVICES
[TYPE]
devices=DEVICES
この場合は、type の行を省略することができます。タイプと同様に、インスタンスは名前で参照されます。上記の例は、以下のように書き換えることができます。
例2.5 短い構文を使用したブロックデバイスのマッチング
[disk] devices=sdb* disable_barriers=false
[disk]
devices=sdb*
disable_barriers=false
プロファイルで競合するプラグインの定義
include オプションを使用して同じセクションを複数回指定した場合は、設定がマージされます。設定をマージできない場合は、競合がある以前の設定よりも、競合がある最後の定義が優先されます。以前に定義されたものが分からない場合は、replace ブール式オプションを使用して、それを true に設定します。これにより、同じ名前の以前の定義がすべて上書きされ、マージは行われません。
また、enabled=false オプションを指定してプラグインを無効にすることもできます。これは、インスタンスが定義されない場合と同じ効果になります。include オプションから以前の定義を再定義し、カスタムプロファイルでプラグインをアクティブにしない場合には、プラグインを無効にすると便利です。
- 注記
TuneD には、チューニングプロファイルの有効化または無効化の一環として、シェルコマンドを実行する機能が含まれます。これにより、TuneD に統合されていない機能で、TuneD プロファイルを拡張できます。
任意のシェルコマンドは、
scriptプラグインを使用して指定できます。
2.8. 利用可能な TuneD プラグイン リンクのコピーリンクがクリップボードにコピーされました!
プラグインの監視
現在、以下の監視プラグインが実装されています。
disk- デバイスおよび測定間隔ごとのディスク負荷 (IO 操作の数) を取得します。
net- ネットワークカードおよび測定間隔ごとのネットワーク負荷 (転送済みパケットの数) を取得します。
load- CPU および測定間隔ごとの CPU 負荷を取得します。
プラグインのチューニング
現在、以下のチューニングプラグインが実装されています。動的チューニングを実装するのは、これらのプラグインの一部のみです。プラグインで対応しているオプションもリスト表示されます。
cpuCPU ガバナーを、
governorオプションで指定された値に設定し、CPU 負荷に応じて、電源管理サービス品質 (PM QoS) CPU ダイレクトメモリーアクセス (DMA) のレイテンシーを動的に変更します。CPU 負荷が
load_thresholdオプションで指定された値よりも小さい場合、レイテンシーはlatency_highオプションで指定した値に設定されます。それ以外では、latency_lowで指定した値に設定されます。レイテンシーを特定の値に強制し、さらに動的に変更しないようにすることもできます。これを行うには、
force_latencyオプションを、必要なレイテンシーの値に設定します。eeepc_sheCPU の負荷に応じて、フロントサイドバス (FSB) の速度を動的に設定します。
この機能は一部のネットブックで利用でき、ASUS Super Hybrid Engine (SHE) としても知られています。
CPU 負荷が
load_threshold_powersaveオプションで指定した値と同じかそれ未満の場合、プラグインは、FSB 速度を、she_powersaveオプションで指定した値に設定します。CPU 負荷がload_threshold_normalオプションで指定した値と同じかそれより上になる場合は、FSB 速度が、she_normalオプションで指定された値に設定されます。この機能のハードウェアサポートを TuneD が検出しない場合、静的チューニングには対応せず、プラグインも透過的に無効になります。
net-
Wake on LAN 機能を、
wake_on_lanオプションで指定した値に設定します。ethtoolユーティリティーと同じ構文を使用します。また、インターフェイスの使用状況に応じてインターフェイス速度が動的に変更します。 sysctlプラグインオプションで指定したさまざまな
sysctl設定を設定します。この構文は、
name=valueです。name は、sysctlユーティリティーが指定した名前と同じです。TuneDで利用可能な別のプラグインで対応していない設定を変更する必要がある場合は、
sysctlプラグインを使用します。他の特定プラグインが、この設定に対応している場合は、そのプラグインを使用することが推奨されます。usbUSB デバイスの autosuspend タイムアウトを、
autosuspendパラメーターで指定した値に設定します。値が
0の場合は、autosuspend が無効になります。vmtransparent_hugepagesオプションの値に合わせて、Transparent Huge Page を有効または無効にします。transparent_hugepagesオプションの有効な値は次のとおりです。- "always"
- "never"
- "madvise"
audio音声コーデックの autosuspend タイムアウトを、
timeoutオプションで指定した値に設定します。現在、
snd_hda_intelコーデックおよびsnd_ac97_codecコーデックに対応しています。値が0の場合は、autosuspend が無効になります。また、ブール値オプションreset_controllerをtrueに設定することにより、コントローラーを強制的にリセットすることもできます。diskelevatorオプションで指定された値にディスクエレベーターを設定します。また、以下も設定します。
-
apmオプションで指定された値への APM -
scheduler_quantumオプションで指定された値へのスケジューラーの量子 -
spindownオプションで指定された値へのディスクスピンダウンタイムアウト -
readaheadパラメーターで指定した値までディスク先読み -
現在のディスクが、
readahead_multiplyオプションで指定した定数を掛けた値に先読みされます。
さらに、このプラグインにより、現在のドライブ使用状況に応じて、ドライブの高度な電力管理設定および spindown タイムアウト設定が動的に変更します。動的チューニングは、ブール値オプション
dynamicにより制御でき、デフォルトで有効になります。-
scsi_hostSCSI ホストのオプションをチューニングします。
Aggressive Link Power Management (ALPM) を、
alpmオプションで指定した値に設定します。mounts-
disable_barriersオプションのブール値に応じて、マウントのバリアを有効または無効にします。 scriptプロファイルの読み込み時またはアンロード時に、外部スクリプトまたはバイナリーを実行します。任意の実行可能ファイルを選択できます。
重要scriptプラグインは、以前のリリースとの互換性を維持するために提供されています。必要な機能をカバーする場合は、他のTuneD プラグインを使用することが推奨されます。TuneD は、以下のいずれかの引数で実行ファイルを呼び出します。
-
プロファイルの読み込み時に
start -
プロファイルのアンロード時に
stop
実行可能ファイルに
stopアクションを適切に実装し、startアクション中に変更したすべての設定を元に戻す必要があります。この手順を行わないと、TuneD プロファイルを変更した後のロールバック手順が機能しません。bash スクリプトは、Bash ライブラリー
/usr/lib/tuned/functionsをインポートし、そこで定義されている関数を使用できます。これらの関数は、TuneD がネイティブに提供していない機能にのみ使用してください。関数名が_wifi_set_power_levelなどのアンダースコアで始まる場合は、将来変更される可能性があるため、関数をプライベートにし、スクリプトでは使用しないでください。プラグイン構造の
scriptパラメーターを使用して、実行ファイルへのパスを指定します。例2.6 プロファイルからの Bash スクリプトの実行
プロファイルディレクトリーに置かれた
script.shという名前の Bash スクリプトを実行するには、次のコマンドを実行します。[script] script=${i:PROFILE_DIR}/script.sh[script] script=${i:PROFILE_DIR}/script.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
プロファイルの読み込み時に
sysfsプラグインオプションで指定したさまざまな
sysfs設定を設定します。構文は
name=valueとなります。name は、使用するsysfsパスです。このプラグインは、他のプラグインで対応していない一部の設定を変更する必要がある場合に使用します。特定のプラグインが必要な設定に対応する場合は、そのプラグインを優先します。
videoビデオカードのさまざまな省電力レベルを設定します。現在、Radeon カードにのみ対応しています。
省電力レベルは、
radeon_powersaveオプションを使用して指定できます。対応している値は次のとおりです。-
default -
auto -
low -
mid -
High -
dynpm -
dpm-battery -
dpm-balanced -
dpm-perfomance
詳細は www.x.org を参照してください。このプラグインは実験的なものであるため、今後のリリースでオプションが変更する可能性があることに注意してください。
-
bootloaderカーネルコマンドラインにオプションを追加します。このプラグインは GRUB ブートローダーのみをサポートします。
GRUB 設定ファイルのカスタマイズされた非標準の場所は、
grub2_cfg_fileオプションで指定できます。そのカーネルオプションは、現在の GRUB 設定とそのテンプレートに追加されます。カーネルオプションを有効にするには、システムを再起動する必要があります。
別のプロファイルに切り替えるか、
TuneDサービスを手動で停止すると、追加のオプションが削除されます。システムをシャットダウンまたは再起動しても、カーネルオプションはgrub.cfgファイルに残ります。カーネルオプションは、以下の構文で指定できます。
cmdline=arg1 arg2 ... argN
cmdline=arg1 arg2 ... argNCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例2.7 カーネルコマンドラインの変更
たとえば、
quietカーネルオプションを TuneD プロファイルに追加するには、tuned.confファイルに次の行を含めます。[bootloader] cmdline=quiet
[bootloader] cmdline=quietCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に、
isolcpus=2オプションをカーネルコマンドラインに追加するカスタムプロファイルの例を示します。[bootloader] cmdline=isolcpus=2
[bootloader] cmdline=isolcpus=2Copy to Clipboard Copied! Toggle word wrap Toggle overflow serviceプラグインオプションで指定されたさまざまな
sysvinit、sysv-rc、openrc、およびsystemdサービスを処理します。構文は
service.service_name=command[,file:file]です。サポートされているサービス処理コマンドは次のとおりです。
-
start -
stop -
enable -
disable
コンマ (
,) またはセミコロン (;) を使用して、複数のコマンドを区切ります。ディレクティブの競合の場合、serviceプラグインは最後にリストされたものを使用します。オプションの
file:fileディレクティブを使用して、systemd専用のオーバーレイ設定ファイルfileをインストールします。他の init システムは、このディレクティブを無視します。serviceプラグインは、オーバーレイ設定ファイルを/etc/systemd/system/service_name.service.d/ディレクトリーにコピーします。プロファイルがアンロードされると、serviceプラグインは、これらのディレクトリーが空の場合は削除します。注記serviceプラグインは、systemdinit システム以外の現在のランレベルでのみ動作します。例2.8 オーバーレイファイルを使用した
sendmailサービスの開始および有効化[service] service.sendmail=start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.conf[service] service.sendmail=start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 内部変数
${i:PROFILE_DIR}は、プラグインがプロファイルをロードするディレクトリーを指します。-
scheduler- スケジューリングの優先度、CPU コア分離、プロセスアフィニティー、スレッドアフィニティー、および IRQ アフィニティーを調整するためのさまざまなオプションを提供します。
利用可能なさまざまなオプションの詳細は、Functionalities of the scheduler TuneD plug-in を参照してください。
2.9. scheduler TuneD プラグインの機能 リンクのコピーリンクがクリップボードにコピーされました!
scheduler TuneD プラグインを使用して、スケジューリングの優先度、CPU コアの分離、プロセスアフィニティー、スレッドアフィニティー、および IRQ アフィニティーを制御および調整します。
CPU の分離
プロセス、スレッド、および IRQ が特定の CPU を使用しないようにするには、isolated_cores オプションを使用します。これは、プロセスおよびスレッドアフィニティー、IRQ アフィニティーを変更し、IRQ の default_smp_affinity パラメーターを設定します。
CPU アフィニティーマスクは、sched_setaffinity() システムコールの成功を条件として、ps_whitelist オプションに一致するすべてのプロセスとスレッドに対して調整されます。ps_whitelist 正規表現のデフォルト設定は、すべてのプロセスおよびスレッド名に一致する .* です。特定のプロセスおよびスレッドを除外するには、ps_blacklist オプションを使用します。このオプションの値も正規表現として解釈されます。プロセス名とスレッド名は、その正規表現と照合されます。プロファイルロールバックにより、一致するすべてのプロセスとスレッドがすべての CPU で実行され、プロファイルアプリケーションの前に IRQ 設定が復元されます。
ps_whitelist オプションおよび ps_blacklist オプションで、; で区切った複数の正規表現がサポートされます。エスケープされたセミコロン \; はそのまま使用されます。
例2.9 CPUs 2-4 の分離
以下の設定は CPU 2-4 を分離します。ps_blacklist 正規表現に一致するプロセスおよびスレッドは、分離に関係なく任意の CPU を使用できます。
[scheduler] isolated_cores=2-4 ps_blacklist=.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*
[scheduler]
isolated_cores=2-4
ps_blacklist=.*pmd.*;.*PMD.*;^DPDK;.*qemu-kvm.*
IRQ SMP アフィニティー
/proc/irq/default_smp_affinity ファイルには、すべての非アクティブな割り込み要求 (IRQ) ソース用のシステム上のデフォルトのターゲット CPU コアを表すビットマスクが含まれます。IRQ がアクティブまたは割り当てられると、/proc/irq/default_smp_affinity ファイルの値は IRQ のアフィニティービットマスクを決定します。
default_irq_smp_affinity パラメーターは、TuneD が /proc/irq/default_smp_affinity ファイルに書き込むものを制御します。default_irq_smp_affinity パラメーターは、以下の値と動作をサポートします。
calcisolated_coresパラメーターから/proc/irq/default_smp_affinityファイルの内容を計算します。isolated_coresパラメーターの反転は、分離していないコアを計算します。次に、分離されていないコアの交差部分と、
/proc/irq/default_smp_affinityファイルの以前の内容が/proc/irq/default_smp_affinityファイルに書き込まれます。これは、
default_irq_smp_affinityパラメーターが省略された場合のデフォルトの動作です。ignore-
TuneD は、
/proc/irq/default_smp_affinityファイルを変更しません。 - CPU リスト
1などの単一の数値、1,3などのコンマ区切りのリスト、または3-5などの範囲の形式を取ります。CPU リストを展開し、これを
/proc/irq/default_smp_affinityファイルに直接書き込みます。
例2.10 明示的な CPU リストを使用したデフォルトの IRQ smp アフィニティーの設定
以下の例では、明示的な CPU リストを使用して、デフォルトの IRQ SMP アフィニティーを CPU 0 および 2 に設定します。
[scheduler] isolated_cores=1,3 default_irq_smp_affinity=0,2
[scheduler]
isolated_cores=1,3
default_irq_smp_affinity=0,2
スケジューリングポリシー
プロセスまたはスレッドのグループのスケジューリングポリシー、優先度、およびアフィニティーを調整するには、以下の構文を使用します。
group.groupname=rule_prio:sched:prio:affinity:regex
group.groupname=rule_prio:sched:prio:affinity:regex
ここで rule_prio は、ルールの内部 TuneD 優先度を定義します。ルールは優先度に基づいてソートされます。これは、継承が以前に定義されたルールを並べ替えることができるようにするために必要です。同等の rule_prio ルールは、定義された順序で処理される必要があります。ただし、これは Python インタープリターに依存します。groupname の継承されたルールを無効にするには、以下を使用します。
group.groupname=
group.groupname=
sched は以下のいずれかである必要があります。
f- 先入れ先出し (FIFO)
b- バッチ
r- ラウンドロビン
o- その他
*- 変更対象外
affinity は 16 進数での CPU アフィニティーです。変更しない場合は * を使用します。
prio はスケジューリングの優先度です (chrt -m を参照)。
regex は Python の正規表現です。これは、ps -eo cmd コマンドの出力と照合されます。
指定したプロセス名は、複数のグループに一致させることができます。このような場合、最後に一致する regex により、優先順位とスケジューリングポリシーが決まります。
例2.11 スケジューリングポリシーおよび優先度の設定
以下の例では、スケジューリングポリシーと優先度をカーネルスレッドおよびウォッチドッグに設定します。
[scheduler] group.kthreads=0:*:1:*:\[.*\]$ group.watchdog=0:f:99:*:\[watchdog.*\]
[scheduler]
group.kthreads=0:*:1:*:\[.*\]$
group.watchdog=0:f:99:*:\[watchdog.*\]
scheduler プラグインは、perf イベントループを使用して、新しく作成されたプロセスを識別します。デフォルトでは、perf.RECORD_COMM および perf.RECORD_EXIT のイベントをリッスンします。
perf_process_fork パラメーターを true に設定すると、プラグインに対して perf.RECORD_FORK イベントもリッスンするように指示します。つまり、fork() システムコールによって作成された子プロセスが処理されます。
perf イベントの処理には大量の CPU オーバーヘッドが発生する可能性があります。
スケジューラープラグインの CPU オーバーヘッドは、スケジューラー runtime オプションを使用して 0 に設定することで軽減できます。これにより、動的スケジューラー機能が完全に無効になり、perf イベントは監視されず、処理されません。これによるデメリットは、プロセスとスレッドの調整がプロファイルアプリケーションでのみ実行されることです。
例2.12 動的スケジューラー機能の無効化
以下の例では、CPU 1 と 3 を分離しながら、動的スケジューラー機能を無効にします。
[scheduler] runtime=0 isolated_cores=1,3
[scheduler]
runtime=0
isolated_cores=1,3
mmapped バッファーは perf イベントに使用されます。負荷が大きい場合、このバッファーがオーバーフローする可能性があり、プラグインが欠落しているイベントを開始し、新しく作成されたプロセスを処理しない可能性があります。このような場合は、perf_mmap_pages パラメーターを使用してバッファーサイズを増やします。perf_mmap_pages パラメーターの値は 2 の累乗である必要があります。perf_mmap_pages パラメーターが手動で設定されていない場合は、デフォルト値の 128 が使用されます。
cgroupsを使用した制限
scheduler プラグインは、cgroups v1 を使用したプロセスおよびスレッド制限をサポートします。
cgroup_mount_point オプションは、cgroup ファイルシステムをマウントするパス、または、TuneD のマウントが想定される場所を指定します。設定されていない場合、/sys/fs/cgroup/cpuset が想定されます。
cgroup_groups_init オプションが 1 に設定されている場合、TuneD は、cgroup* オプションで定義されたすべての cgroups を作成および削除します。これがデフォルトの動作です。cgroup_mount_point オプションが 0 に設定されている場合、cgroups は他の方法で事前設定する必要があります。
cgroup_mount_point_init オプションが 1 に設定されている場合、TuneD は cgroup マウントポイントを作成し、削除します。これは cgroup_groups_init = 1 を意味します。cgroup_mount_point_init オプションが 0 に設定されている場合は、他の方法で cgroups マウントポイントを事前設定する必要があります。これがデフォルトの動作です。
cgroup_for_isolated_cores オプションは、isolated_cores オプション機能の cgroup 名です。たとえば、システムに 4 つの CPU がある場合、isolated_cores=1 は、Tuned がすべてのプロセスとスレッドを CPU 0、2、および 3 に移動することを意味します。scheduler プラグインは、計算された CPU アフィニティーを指定された cgroup の cpuset.cpus コントロールファイルに書き込み、一致するすべてのプロセスおよびスレッドをこのグループに移動することで、指定されたコアを分離します。このオプションが設定されていない場合、sched_setaffinity() を使用する従来の cpuset アフィニティーが CPU アフィニティーを設定します。
cgroup.cgroup_name オプションは、任意の cgroups のアフィニティーを定義します。階層的な cgroups を使用することもできますが、階層を正しい順序で指定する必要があります。TuneD は、cgroup_mount_point オプションで指定された場所に cgroup を強制的に配置する点を除き、ここでは健全性チェックを行いません。
group. で始まるスケジューラーオプションの構文が拡張され、16 進数の affinity ではなく、cgroup.cgroup_name が使用されるようになりました。一致するプロセスは cgroup cgroup_name に移動されます。上記のように、cgroup. オプションで定義されていない cgroup を使用することもできます。たとえば、TuneD によって管理されない cgroups などがあります。
すべての cgroup 名は、ピリオド (.) をスラッシュ (/) に置き換えてサニタイズされます。これにより、プラグインが cgroup_mount_point オプションで指定された場所の外部に書き込むことを防ぎます。
例2.13 scheduler プラグインでの cgroups v1 の使用
以下の例では、2 つの cgroups、group1、および group2 を作成します。cgroup group1 アフィニティーを CPU 2 に設定し、cgroup group2 を CPU 0 および 2 に設定します。4 つの CPU 設定を指定すると、isolated_cores=1 オプションはすべてのプロセスとスレッドを CPU コア 0、2、および 3 に移動します。ps_blacklist 正規表現で指定されたプロセスおよびスレッドは移動されません。
cgroup_ps_blacklist オプションは、指定された cgroups に属するプロセスを除外します。このオプションで指定された正規表現は、/proc/PID/cgroups の cgroup 階層と照合されます。コンマ (,) は、正規表現の一致前に cgroups v1 階層を /proc/PID/cgroups から分離します。以下は、正規表現が照合される内容の例です。
10:hugetlb:/,9:perf_event:/,8:blkio:/
10:hugetlb:/,9:perf_event:/,8:blkio:/
複数の正規表現はセミコロン (;) で区切ることができます。セミコロンは論理 'or' 演算子を表します。
例2.14 cgroups を使用したスケジューラーからのプロセスの除外
以下の例では、scheduler プラグインは、cgroup /daemons に属するプロセスを除いて、すべてのプロセスをコア 1 から移動します。\b 文字列は、単語境界に一致する正規表現のメタ文字です。
[scheduler] isolated_cores=1 cgroup_ps_blacklist=:/daemons\b
[scheduler]
isolated_cores=1
cgroup_ps_blacklist=:/daemons\b
以下の例では、scheduler プラグインは、階層 ID が 8 で、controller-list blkio を持つ cgroup に属するすべてのプロセスを除外します。
[scheduler] isolated_cores=1 cgroup_ps_blacklist=\b8:blkio:
[scheduler]
isolated_cores=1
cgroup_ps_blacklist=\b8:blkio:
最近のカーネルは、一部の sched_ および numa_balancing_ カーネルランタイムパラメーターを sysctl ユーティリティーが管理する /proc/sys/kernel ディレクトリーから、通常は /sys/kernel/debug ディレクトリーにマウントされる debugfs に移動しました。TuneD は、scheduler プラグインを介して以下のパラメーターの抽象化メカニズムを提供します。このメカニズムでは、TuneD は、使用されるカーネルに基づいて、指定された値を正しい場所に書き込みます。
-
sched_min_granularity_ns -
sched_latency_ns -
sched_wakeup_granularity_ns -
sched_tunable_scaling -
sched_migration_cost_ns -
sched_nr_migrate -
numa_balancing_scan_delay_ms -
numa_balancing_scan_period_min_ms -
numa_balancing_scan_period_max_ms numa_balancing_scan_size_mb例2.15 移行を決定するためにタスクの "cache hot" 値を設定します。
古いカーネルで以下のパラメーターを設定すると、
sysctlは500000の値を/proc/sys/kernel/sched_migration_cost_nsファイルに書き込むことを意味します。[sysctl] kernel.sched_migration_cost_ns=500000
[sysctl] kernel.sched_migration_cost_ns=500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、最近のカーネルでは、
schedulerプラグインを介して次のパラメーターを設定するのと同じです。[scheduler] sched_migration_cost_ns=500000
[scheduler] sched_migration_cost_ns=500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow つまり、TuneD は
500000の値を/sys/kernel/debug/sched/migration_cost_nsファイルに書き込みます。
2.10. TuneD プロファイルの変数 リンクのコピーリンクがクリップボードにコピーされました!
TuneD プロファイルがアクティブになると、変数は実行時にデプロイメントします。
TuneD変数を使用すると、TuneDプロファイルで必要な入力を減らすことができます。
TuneDプロファイルには事前定義された変数はありません。プロファイルに [variables] セクションを作成し、以下の構文を使用すると、独自の変数を定義できます。
[variables] variable_name=value
[variables]
variable_name=value
プロファイル内の変数の値をデプロイメントするには、以下の構文を使用します。
${variable_name}
${variable_name}
例2.16 変数を使用した CPU コアの分離
以下の例では、${isolated_cores} 変数が 1,2 にデプロイメントされるため、カーネルは isolcpus=1,2 オプションで起動します。
[variables]
isolated_cores=1,2
[bootloader]
cmdline=isolcpus=${isolated_cores}
[variables]
isolated_cores=1,2
[bootloader]
cmdline=isolcpus=${isolated_cores}
変数は個別のファイルで指定できます。たとえば、次の行を tuned.conf に追加できます。
[variables]
include=/etc/tuned/my-variables.conf
[bootloader]
cmdline=isolcpus=${isolated_cores}
[variables]
include=/etc/tuned/my-variables.conf
[bootloader]
cmdline=isolcpus=${isolated_cores}
isolated_cores=1,2 オプションを /etc/tuned/my-variables.conf ファイルに追加すると、カーネルが isolcpus=1,2 オプションで起動します。
2.11. TuneD プロファイルの組み込み関数 リンクのコピーリンクがクリップボードにコピーされました!
組み込み関数は、TuneD プロファイルがアクティブになると、実行時に拡張します。
これにより、以下が可能になります。
- さまざまな組み込み関数と、TuneD変数の使用
- Python でカスタム関数を作成し、プラグインの形式でTuneD に追加します。
関数を呼び出すには、以下の構文を使用します。
${f:function_name:argument_1:argument_2}
${f:function_name:argument_1:argument_2}
プロファイルと tuned.conf ファイルが置かれたディレクトリーパスをデプロイメントするには、特殊な構文が必要な PROFILE_DIR 関数を使用します、
${i:PROFILE_DIR}
${i:PROFILE_DIR}
例2.17 変数と組み込み関数を使用した CPU コア分離
次の例では、${non_isolated_cores} 変数は 0,3-5 にデプロイメントされ、cpulist_invert 組み込み関数が 0,3-5 引数で呼び出されます。
[variables]
non_isolated_cores=0,3-5
[bootloader]
cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}
[variables]
non_isolated_cores=0,3-5
[bootloader]
cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}
cpulist_invert 関数は、CPU のリストを反転します。6 CPU のマシンでは、反転が 1,2 になり、カーネルは isolcpus=1,2 コマンドラインオプションで起動します。
2.12. TuneD プロファイルで利用可能な組み込み関数 リンクのコピーリンクがクリップボードにコピーされました!
すべての TuneD プロファイルで、以下の組み込み関数を使用できます。
PROFILE_DIR-
プロファイルと
tuned.confファイルが置かれているディレクトリーパスを返します。 exec- プロセスを実行し、その出力を返します。
assertion- 2 つの引数を比較します。一致しない 場合、関数は最初の引数からテキストをログに記録し、プロファイルの読み込みを中止します。
assertion_non_equal- 2 つの引数を比較します。2 つの引数が 一致する 場合、関数は最初の引数からテキストをログに記録し、プロファイルの読み込みを中止します。
kb2s- キロバイトをディスクセクターに変換します。
s2kb- ディスクセクターをキロバイトに変換します。
strip- 渡されたすべての引数から文字列を作成し、最初と最後の空白の両方を削除します。
virt_checkTuneD が仮想マシン (VM) またはベアメタルのどちらで実行しているかを確認します。
- 仮想マシン内では、この関数が最初の引数を返します。
- ベアメタルでは、この関数は、エラーが発生した場合でも 2 番目の引数を返します。
cpulist_invert-
補完するために CPU のリストを反転します。たとえば、0 から 3 までの番号が付けられた 4 つの CPU を持つシステムでは、リスト
0,2,3の反転は1です。 cpulist2hex- CPU リストを 16 進数の CPU マスクに変換します。
cpulist2hex_invert- CPU リストを 16 進数の CPU マスクに変換し、反転します。
hex2cpulist- 16 進数の CPU マスクを CPU リストに変換します。
cpulist_online- リストからの CPU がオンラインかどうかをチェックします。オンライン CPU のみを含むリストを返します。
cpulist_present- リストに CPU が存在するかどうかを確認します。存在する CPU のみを含むリストを返します。
cpulist_unpack-
1-3,4形式の CPU リストを、1,2,3,4にデプロイメントします。 cpulist_pack-
CPU リストを、
1,2,3,5の形式で1-3,5に圧縮します。
2.13. 新しい TuneD プロファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、カスタムパフォーマンスルールを使用して新しいTuneDプロファイルを作成します。
前提条件
-
TuneDサービスが実行中である。詳細は、TuneD のインストールと有効化 を参照してください。
手順
/etc/tuned/ディレクトリーで、作成するプロファイルと同じ名前の新しいディレクトリー作成します。mkdir /etc/tuned/my-profile
# mkdir /etc/tuned/my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに、ファイル
tuned.confを作成します。必要に応じて、[main]セクションとプラグイン定義を追加します。たとえば、
balancedプロファイルの設定を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルをアクティベートするには、次のコマンドを実行します。
tuned-adm profile my-profile
# tuned-adm profile my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD プロファイルが有効であり、システム設定が適用されていることを確認します。
tuned-adm active Current active profile: my-profile
$ tuned-adm active Current active profile: my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.14. 既存の TuneD プロファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、既存のTuneD プロファイルに基づいて変更した子プロファイルを作成します。
前提条件
-
TuneDサービスが実行中である。詳細は、TuneD のインストールと有効化 を参照してください。
手順
/etc/tuned/ディレクトリーで、作成するプロファイルと同じ名前の新しいディレクトリー作成します。mkdir /etc/tuned/modified-profile
# mkdir /etc/tuned/modified-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに、ファイル
tuned.confを作成し、以下のように[main]セクションを設定します。[main] include=parent-profile
[main] include=parent-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow parent-profile を、変更しているプロファイルの名前に置き換えます。
プロファイルの変更を含めます。
例2.18 throughput-performance プロファイルでスワップを低減
throughput-performanceプロファイルの設定を使用し、vm.swappinessの値を、デフォルトの 10 ではなく 5 に変更するには、以下を使用します。[main] include=throughput-performance [sysctl] vm.swappiness=5
[main] include=throughput-performance [sysctl] vm.swappiness=5Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルをアクティベートするには、次のコマンドを実行します。
tuned-adm profile modified-profile
# tuned-adm profile modified-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD プロファイルが有効であり、システム設定が適用されていることを確認します。
tuned-adm active Current active profile: my-profile
$ tuned-adm active Current active profile: my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.15. TuneD を使用したディスクスケジューラーの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、選択したブロックデバイスに特定のディスクスケジューラーを設定するTuneD プロファイルを作成して有効にします。この設定は、システムを再起動しても持続します。
以下のコマンドと設定で、以下の内容を置き換えます。
-
device をブロックデバイスの名前に置き換えます (例:
sdf)。 -
selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例:
bfq)。
前提条件
-
TuneDサービスがインストールされ、有効になっている。詳細は、TuneD のインストールと有効化 を参照してください。
手順
必要に応じて、プロファイルのベースとなる既存のTuneDプロファイルを選択します。利用可能なプロファイルのリストは、RHEL とともに配布される TuneD プロファイル を参照してください。
現在アクティブなプロファイルを確認するには、次のコマンドを実行します。
tuned-adm active
$ tuned-adm activeCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD プロファイルを保持する新しいディレクトリーを作成します。
mkdir /etc/tuned/my-profile
# mkdir /etc/tuned/my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 選択したブロックデバイスのシステム固有の識別子を見つけます。
udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)' ID_WWN=0x5002538d00000000_ ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 ID_SERIAL_SHORT=20120501030900000
$ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)' ID_WWN=0x5002538d00000000_ ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 ID_SERIAL_SHORT=20120501030900000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。
/etc/tuned/my-profile/tuned.conf設定ファイルを作成します。このファイルで、以下のオプションを設定します。必要に応じて、既存のプロファイルを追加します。
[main] include=existing-profile
[main] include=existing-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow WWN 識別子に一致するデバイスに対して選択したディスクスケジューラーを設定します。
[disk] devices_udev_regex=IDNAME=device system unique id elevator=selected-scheduler
[disk] devices_udev_regex=IDNAME=device system unique id elevator=selected-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
IDNAME を、使用されている識別子名に置き換えます (例:
ID_WWN)。 device system unique id を、選択した識別子の値に置き換えます (例:
0x5002538d00000000)。devices_udev_regexオプションで複数のデバイスに一致させるには、識別子を括弧で囲み、垂直バーで区切ります。devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
IDNAME を、使用されている識別子名に置き換えます (例:
プロファイルを有効にします。
tuned-adm profile my-profile
# tuned-adm profile my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TuneD プロファイルがアクティブで、適用されていることを確認します。
tuned-adm active Current active profile: my-profile
$ tuned-adm active Current active profile: my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/block/device/queue/schedulerファイルの内容を読み取ります。cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq none
# cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル名の device を、
sdcなどのブロックデバイス名に置き換えます。アクティブなスケジューラーは、角括弧 (
[]) にリスト表示されます。
第3章 tuna インターフェイスを使用したシステムの確認 リンクのコピーリンクがクリップボードにコピーされました!
tuna ツールは、チューニングタスクを実行する際の複雑性を軽減します。tuna を使用して、スケジューラーの調整可能パラメーターの調整、スレッド優先度や IRQ ハンドラーのチューニング、CPU コアおよびソケットの分離を行います。tuna ツールを使用すると、次の操作を実行できます。
- システム上の CPU の表示
- システム上で現在実行中の割り込み要求 (IRQ) の表示
- スレッドに関するポリシーおよび優先度の情報の変更
- システムの現在のポリシーと優先度の表示
3.1. tuna ツールのインストール リンクのコピーリンクがクリップボードにコピーされました!
tuna ツールは、稼働中のシステムで使用されるように設計されています。これにより、アプリケーション固有の測定ツールで、変更の直後にシステムパフォーマンスを確認および分析できます。
手順
tunaツールをインストールします。dnf install tuna
# dnf install tunaCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
利用可能な
tunaCLI オプションを表示します。tuna -h
# tuna -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. tuna ツールを使用したシステムの状態の表示 リンクのコピーリンクがクリップボードにコピーされました!
tuna コマンドラインインターフェイス (CLI) ツールを使用して、システムの状態を表示できます。
前提条件
-
tunaツールがインストールされている。詳細は、tuna ツールのインストール を参照してください。
手順
現在のポリシーおよび優先度を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、PID に対応する、またはコマンド名に一致する特定のスレッドを表示するには、次のように入力します。
tuna show_threads -t pid_or_cmd_list
# tuna show_threads -t pid_or_cmd_listCopy to Clipboard Copied! Toggle word wrap Toggle overflow pid_or_cmd_list 引数は、コンマ区切りの PID またはコマンド名パターンのリストです。
シナリオに応じて、次のいずれかのアクションを実行します。
-
tunaCLI を使用して CPU をチューニングするには、tuna ツールを使用した CPU のチューニング の手順を完了します。 -
tunaツールを使用して IRQ を調整するには、tuna ツールを使用した IRQ のチューニング の手順を完了します。
-
変更した設定を保存します。
tuna save filename
# tuna save filenameCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、現在実行中のカーネルスレッドのみを保存します。実行していないプロセスは保存されません。
3.3. tuna ツールを使用した CPU のチューニング リンクのコピーリンクがクリップボードにコピーされました!
tuna ツールコマンドは、個別の CPU をターゲットとして指定できます。tuna ツールを使用すると、次のアクションを実行できます。
Isolate CPUs- 指定した CPU で実行しているすべてのタスクが、次に利用可能な CPU に移動します。CPU を分離すると、すべてのスレッドのアフィニティーマスクから CPU が削除され、CPU が利用できなくなります。
Include CPUs- 指定された CPU でタスクを実行できるようにします。
Restore CPUs- 指定した CPU を以前の設定に戻します。
前提条件
-
tunaツールがインストールされている。詳細は、tuna ツールのインストール を参照してください。
手順
すべての CPU をリスト表示し、コマンドの影響を受ける CPU のリストを指定します。
ps ax | awk 'BEGIN { ORS="," }{ print $1 }' PID,1,2,3,4,5,6,8,10,11,12,13,14,15,16,17,19# ps ax | awk 'BEGIN { ORS="," }{ print $1 }' PID,1,2,3,4,5,6,8,10,11,12,13,14,15,16,17,19Copy to Clipboard Copied! Toggle word wrap Toggle overflow tunaインターフェイスでスレッドリストを表示します。tuna show_threads -t 'thread_list from above cmd'
# tuna show_threads -t 'thread_list from above cmd'Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの影響を受ける CPU のリストを指定します。
*tuna [command] --cpus cpu_list *
# *tuna [command] --cpus cpu_list *Copy to Clipboard Copied! Toggle word wrap Toggle overflow cpu_list 引数は、
--cpus 0,2などのコンマ区切り CPU 番号のリストです。現在の cpu_list に特定の CPU を追加するには、たとえば
--cpus +0を使用します。状況に応じて、次のいずれかの操作を実行します。
CPU を分離するには、次のように入力します。
tuna isolate --cpus cpu_list
# tuna isolate --cpus cpu_listCopy to Clipboard Copied! Toggle word wrap Toggle overflow CPU を含めるには、次のように入力します。
tuna include --cpus cpu_list
# tuna include --cpus cpu_listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4 つ以上のプロセッサーを搭載したシステムを使用する場合は、すべての
sshスレッドを CPU 0 と 1 で実行し、すべてのhttpスレッドを CPU 2 と 3 で実行します。tuna move --cpus 0,1 -t ssh* tuna move --cpus 2,3 -t http\*
# tuna move --cpus 0,1 -t ssh* # tuna move --cpus 2,3 -t http\*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
現在の設定を表示し、変更が適用されたことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. tuna ツールを使用した IRQ のチューニング リンクのコピーリンクがクリップボードにコピーされました!
/proc/interrupts ファイルには、IRQ ごとの割り込みの数、割り込みのタイプ、およびその IRQ にあるデバイスの名前が記録されます。
前提条件
-
tunaツールがインストールされている。詳細は、tuna ツールのインストール を参照してください。
手順
現在の IRQ とそれらのアフィニティーを表示します。
tuna show_irqs users affinity 0 timer 0 1 i8042 0 7 parport0 0
# tuna show_irqs # users affinity 0 timer 0 1 i8042 0 7 parport0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの影響を受ける IRQ のリストを指定します。
tuna [command] --irqs irq_list --cpus cpu_list
# tuna [command] --irqs irq_list --cpus cpu_listCopy to Clipboard Copied! Toggle word wrap Toggle overflow irq_list 引数は、コンマ区切りの IRQ 番号またはユーザー名パターンのリストです。
[コマンド] を、たとえば
--spreadに置き換えます。指定した CPU に割り込みを移動します。
tuna show_irqs --irqs 128 users affinity 128 iwlwifi 0,1,2,3 tuna move --irqs 128 --cpus 3
# tuna show_irqs --irqs 128 users affinity 128 iwlwifi 0,1,2,3 # tuna move --irqs 128 --cpus 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 128 を irq_list 引数に置き換え、3 を cpu_list 引数に置き換えます。
cpu_list 引数は、
--cpus 0,2などのコンマ区切り CPU 番号のリストです。詳細は、tuna ツールを使用した CPU のチューニング を参照してください。
検証
選択した IRQ の状態を、割り込みを指定の CPU に移動してから比較します。
tuna show_irqs --irqs 128 users affinity 128 iwlwifi 3# tuna show_irqs --irqs 128 users affinity 128 iwlwifi 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 RHEL システムロールを使用した PCP によるパフォーマンス監視の設定 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) は、システムパフォーマンス分析ツールキットです。これを使用すると、Red Hat Enterprise Linux システム上の多くのコンポーネントからパフォーマンスデータを記録および分析できます。
metrics RHEL システムロールを使用すると、PCP のインストールと設定を自動化できます。また、ロールを使用して Grafana を設定し、PCP メトリクスを視覚化できます。
4.1. metrics RHEL システムロールを使用して Performance Co-Pilot を設定する リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) を使用すると、CPU 使用率やメモリー使用量など、多くのメトリクスを監視できます。これは、たとえばリソースとパフォーマンスのボトルネックを特定するのに役立ちます。metrics RHEL システムロールを使用すると、複数のホストに PCP をリモートで設定してメトリクスを記録できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
metrics_retention_days: <number>-
pmlogger_dailysystemd タイマーが古い PCP アーカイブを削除するまでの日数を設定します。 metrics_manage_firewall: <true|false>-
firewalldサービスで必要なポートをロールによって開くかどうかを定義します。管理対象ノード上の PCP にリモートでアクセスする場合は、この変数をtrueに設定します。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.metrics/README.mdファイルを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
メトリクスをクエリーします。次に例を示します。
ansible managed-node-01.example.com -m command -a 'pminfo -f kernel.all.load'
# ansible managed-node-01.example.com -m command -a 'pminfo -f kernel.all.load'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
4.2. metrics RHEL システムロールを使用して認証を使用する Performance Co-Pilot を設定する リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) で認証を有効にすると、pmcd サービスと Performance Metrics Domain Agent (PDMA) によって、監視ツールを実行しているユーザーにアクションの実行を許可するかどうかを決定できるようになります。認証されたユーザーは機密情報を含むメトリクスにアクセスできます。また、エージェントの中には認証が必要なものもあります。たとえば、bpftrace エージェントは、認証を使用して、bpftrace スクリプトをカーネルにロードしてメトリクスを生成することがユーザーに許可されているかどうかを確認します。
metrics RHEL システムロールを使用すると、認証を使用する PCP を複数のホストにリモートで設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
機密性の高い変数を暗号化されたファイルに保存します。
vault を作成します。
ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
$ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ansible-vault createコマンドでエディターが開いたら、機密データを<key>: <value>形式で入力します。metrics_usr: <username> metrics_pwd: <password>
metrics_usr: <username> metrics_pwd: <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
metrics_retention_days: <number>-
pmlogger_dailysystemd タイマーが古い PCP アーカイブを削除するまでの日数を設定します。 metrics_manage_firewall: <true|false>-
firewalldサービスで必要なポートをロールによって開くかどうかを定義します。管理対象ノード上の PCP にリモートでアクセスする場合は、この変数をtrueに設定します。 metrics_username: <username>-
このロールは、管理対象ノード上でこのユーザーをローカルに作成し、Simple Authentication and Security Layer (SASL) データベース
/etc/pcp/passwd.dbに認証情報を追加し、PCP に認証を設定します。さらに、Playbook でmetrics_from_bpftrace: trueを設定すると、PCP がこのアカウントを使用してbpftraceスクリプトを登録します。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.metrics/README.mdファイルを参照してください。Playbook の構文を検証します。
ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pcpパッケージがインストールされているホストで、認証を必要とするメトリクスをクエリーします。Playbook で使用した認証情報を使用してメトリクスをクエリーします。
pminfo -fmdt -h pcp://managed-node-01.example.com?username=<user> proc.fd.count Password: <password> proc.fd.count inst [844 or "000844 /var/lib/pcp/pmdas/proc/pmdaproc"] value 5# pminfo -fmdt -h pcp://managed-node-01.example.com?username=<user> proc.fd.count Password: <password> proc.fd.count inst [844 or "000844 /var/lib/pcp/pmdas/proc/pmdaproc"] value 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが成功すると、
proc.fd.countメトリクスの値が返されます。ユーザー名を省略してコマンドを再度実行し、認証されていないユーザーの場合はコマンドが失敗することを確認します。
pminfo -fmdt -h pcp://managed-node-01.example.com proc.fd.count proc.fd.count Error: No permission to perform requested operation
# pminfo -fmdt -h pcp://managed-node-01.example.com proc.fd.count proc.fd.count Error: No permission to perform requested operationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
4.3. Performance Co-Pilot で複数のホストを監視するために metrics RHEL システムロールを使用して Grafana を設定する リンクのコピーリンクがクリップボードにコピーされました!
複数のホストに Performance Co-Pilot (PCP) をすでに設定している場合は、Grafana のインスタンスを使用して、これらのホストのメトリクスを視覚化できます。ライブデータを表示できます。PCP データが Redis データベースに保存されている場合は、過去のデータも表示できます。
metrics RHEL システムロールを使用すると、Grafana、PCP プラグイン、オプションの Redis データベース、およびデータソースの設定のセットアッププロセスを自動化できます。
metrics ロールを使用してホストに Grafana をインストールすると、ロールによってこのホストに PCP も自動的にインストールされます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。 - 監視対象ホストへのリモートアクセス用に PCP が設定されている。
- Grafana をインストールするホストが、監視する予定の PCP ノードのポート 44321 にアクセスできる。
手順
機密性の高い変数を暗号化されたファイルに保存します。
vault を作成します。
ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
$ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ansible-vault createコマンドでエディターが開いたら、機密データを<key>: <value>形式で入力します。grafana_admin_pwd: <password>
grafana_admin_pwd: <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
metrics_graph_service: true-
Grafana と PCP プラグインをインストールします。さらに、
PCP Vector、PCP Redis、およびPCP bpftraceデータソースが Grafana に追加されます。 metrics_query_service: <true|false>- ロールによって、一元的なメトリクス記録用に Redis をインストールして設定する必要があるかどうかを定義します。有効にすると、PCP クライアントから収集されたデータが Redis に保存され、ライブデータだけでなく履歴データも表示できるようになります。
metrics_monitored_hosts: <list_of_hosts>- 監視するホストのリストを定義します。定義すると、Grafana で、これらのホストのデータに加えて、Grafana を実行しているホストのデータを表示できます。
metrics_manage_firewall: <true|false>-
firewalldサービスで必要なポートをロールによって開くかどうかを定義します。この変数をtrueに設定すると、たとえば Grafana にリモートでアクセスできるようになります。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.metrics/README.mdファイルを参照してください。Playbook の構文を検証します。
ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
-
ブラウザーで
http://<grafana_server_IP_or_hostname>:3000を開き、上記手順で設定したパスワードを使用してadminユーザーとしてログインします。 監視データを表示します。
ライブデータを表示するには、次の手順を実行します。
- → → →
-
デフォルトでは、Grafana を実行しているホストからのメトリクスがグラフに表示されます。別のホストに切り替えるには、
hostspecフィールドにホスト名を入力して Enter キー を押します。
-
Redis データベースに保存されている履歴データを表示するには、PCP Redis データソースを使用してパネルを作成 します。そのためには、Playbook で
metrics_query_service: trueを設定する必要があります。
4.4. metrics RHEL システムロールを使用して Performance Co-Pilot に Web フックを設定する リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) スイートには、Performance Metrics Inference Engine (PMIE) サービスが含まれています。このサービスは、パフォーマンスルールをリアルタイムで評価します。たとえば、デフォルトのルールを使用すると、過剰なスワップアクティビティーを検出できます。
1 台のホストを、複数の PCP ノードから監視データを収集する中央 PCP 管理サイトとして設定できます。ルールが一致すると、この中央ホストは Web フックに通知を送信して他のサービスに通知します。たとえば、Web フックによって、イベントを引き起こしたホスト上の Ansible Automation Platform テンプレートまたは Playbook に対して Event-Driven Ansible を実行するようにトリガーできます。
metrics RHEL システムロールを使用すると、Web フックに通知する中央 PCP 管理ホストの設定を自動化できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。 - 監視対象ホストへのリモートアクセス用に PCP が設定されている。
- PMIE を設定するホストが、監視する予定の PCP ノードのポート 44321 にアクセスできる。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル Playbook で指定されている設定は次のとおりです。
metrics_retention_days: <number>-
pmlogger_dailysystemd タイマーが古い PCP アーカイブを削除するまでの日数を設定します。 metrics_manage_firewall: <true|false>-
firewalldサービスで必要なポートをロールによって開くかどうかを定義します。管理対象ノード上の PCP にリモートでアクセスする場合は、この変数をtrueに設定します。 metrics_monitored_hosts: <list_of_hosts>- 監視するホストを指定します。
metrics_webhook_endpoint: <URL>- Performance Metrics Inference Engine (PMIE) がパフォーマンスに関して検出された問題に関する通知を送信する Web フックエンドポイントを設定します。デフォルトでは、この問題はローカルシステムにのみ記録されます。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.metrics/README.mdファイルを参照してください。Playbook の構文を検証します。
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
managed-node-node-01.example.comの設定概要を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最後の 3 行から、PMIE が 3 つのシステムを監視するように設定されていることを確認できます。
第5章 PCP の設定 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) は、システムレベルのパフォーマンス測定を監視、視覚化、保存、および分析するためのツール、サービス、およびライブラリーのスイートです。
5.1. PCP の概要 リンクのコピーリンクがクリップボードにコピーされました!
Python、Perl、C++、および C のインターフェイスを使用したパフォーマンスメトリックを追加できます。分析ツールは、Python、C++、C のクライアント API を直接使用でき、豊富な Web アプリケーションは、JSON インターフェイスを使用して利用可能なすべてのパフォーマンスデータを調べることができます。
ライブ結果とアーカイブされたデータを比較して、データパターンを解析できます。
PCP の機能:
- 軽量の分散アーキテクチャー。複雑なシステムの集中分析に役に立ちます。
- これにより、リアルタイムデータの監視および管理が可能になります。
- これにより、履歴データのログおよび取得が可能になります。
PCP には以下のコンポーネントがあります。
-
Performance Metric Collector Daemon (
pmcd) は、インストールされている Performance Metric Domain Agents (pmda) からパフォーマンスデータを収集します。PMDA は、システムで個別にロードまたはアンロードでき、同じホストの PMCD によって制御されます。 -
pminfoやpmstatなどのさまざまなクライアントツールは、同じホストまたはネットワーク上でこのデータを取得、表示、アーカイブ、処理できます。 -
pcpパッケージは、コマンドラインツールと、基本的な機能を提供します。 -
pcp-guiパッケージは、グラフィカルアプリケーションを提供します。dnf install pcp-guiコマンドを実行して、pcp-guiパッケージをインストールします。詳細は、Visually tracing PCP log archives with the PCP Charts application を参照してください。
5.2. PCP のインストールおよび有効化 リンクのコピーリンクがクリップボードにコピーされました!
PCP の使用を開始するには、必要なパッケージをすべてインストールし、PCP 監視サービスを有効にします。
この手順では、pcp パッケージを使用して PCP をインストールする方法を説明します。PCP のインストールを自動化するには、pcp-zeroconf パッケージを使用してインストールします。pcp-zeroconf を使用して PCP をインストールする方法の詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
手順
pcpパッケージをインストールします。dnf install pcp
# dnf install pcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストマシンで
pmcdサービスを有効にして起動します。systemctl enable pmcd systemctl start pmcd
# systemctl enable pmcd # systemctl start pmcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmcdプロセスがホストで実行されているかどうかを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 最小限の PCP 設定のデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
最小 PCP 設定は、Red Hat Enterprise Linux でパフォーマンス統計を収集します。この設定は、詳細な分析のためにデータを収集するために必要な、実稼働システムに最低限のパッケージを追加します。
作成された tar.gz ファイルおよび pmlogger の出力のアーカイブは、さまざまな PCP ツールを使用して解析し、その他のソースのパフォーマンス情報と比較できます。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
pmlogger設定を更新します。pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
# pmlogconf -r /var/lib/pcp/config/pmlogger/config.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmcdサービスおよびpmloggerサービスを起動します。systemctl start pmcd.service systemctl start pmlogger.service
# systemctl start pmcd.service # systemctl start pmlogger.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 必要な操作を実行して、パフォーマンスデータを記録します。
pmcdサービスおよびpmloggerサービスを停止します。systemctl stop pmcd.service systemctl stop pmlogger.service
# systemctl stop pmcd.service # systemctl stop pmlogger.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力を保存し、ホスト名と現在の日時に基づいて名前が付けられた
tar.gzファイルに保存します。cd /var/log/pcp/pmlogger/ tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)
# cd /var/log/pcp/pmlogger/ # tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルをデプロイメントし、PCP ツールを使用してデータを解析します。
5.4. PCP で配布されるシステムサービスおよびツール リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) には、パフォーマンスの測定に使用できるさまざまなシステムサービスとツールが含まれます。基本パッケージ pcp には、システムサービスと基本ツールが含まれます。追加のツールは、pcp-system-tools、pcp-gui、および pcp-devel パッケージで提供されます。
PCP で配布されるシステムサービスのロール
pmcd- PMCD (Performance Metric Collector Daemon)
pmie- Performance Metrics Inference Engine
pmlogger- パフォーマンスメトリックロガー。
pmproxy- リアルタイムおよびヒストリカルなパフォーマンスメトリックのプロキシー、時系列クエリー、REST API サービス。
基本 PCP パッケージで配布されるツール
pcp- Performance Co-Pilot インストールの現在のステータスを表示します。
pcp-vmstat- システムパフォーマンスの概要を 5 秒ごとに表示します。プロセス、メモリー、ページング、ブロック IO、トラップ、CPU のアクティビティーに関する情報を表示します。
pmconfig- 設定パラメーターの値を表示します。
pmdiff- パフォーマンスのリグレッションを検索する際に重要と思われる変更について、指定された時間枠で、1 つまたは 2 つのアーカイブのすべてのメトリックの平均値を比較します。
pmdumplog- Performance Co-Pilot アーカイブファイルの制御、メタデータ、インデックス、および状態に関する情報を表示します。
pmfind- ネットワークで PCP サービスを見つけます。
pmie- 一連の演算式、論理式、およびルール式を定期的に評価する推論エンジン。メトリックは、ライブシステムまたは Performance Co-Pilot アーカイブファイルのいずれかから収集されます。
pmieconf-
設定可能な
pmie変数を表示または設定します。 pmiectl-
pmieのプライマリー以外のインスタンスを管理します。 pminfo- パフォーマンスメトリックに関する情報を表示します。メトリックは、ライブシステムまたは Performance Co-Pilot アーカイブファイルのいずれかから収集されます。
pmlc-
アクティブな
pmloggerインスタンスを対話的に設定します。 pmlogcheck- Performance Co-Pilot アーカイブファイルで無効なデータを特定します。
pmlogconf-
pmlogger設定ファイルを作成および変更します。 pmlogctl-
pmloggerのプライマリー以外のインスタンスを管理します。 pmloglabel- Performance Co-Pilot アーカイブファイルのラベルを検証、変更、または修復します。
pmlogredact- PCP アーカイブから機密情報を削除します。
pmlogsummary- Performance Co-Pilot アーカイブファイルに格納されたパフォーマンスメトリックに関する統計情報を計算します。
pmprobe- パフォーマンスメトリックの可用性を決定します。
pmsocks- ファイアウォールを介して Performance Co-Pilot ホストへのアクセスを許可します。
pmstat- システムパフォーマンスの簡単な概要を定期的に表示します。
pmstore- パフォーマンスメトリックの値を変更します。
pmtrace- トレース PMDA のコマンドラインインターフェイスを提供します。
pmval- パフォーマンスメトリックの現在の値を表示します。
別途インストールする pcp-system-tools パッケージで配布されるツール
pcp-atop- パフォーマンスの観点から最も重要なハードウェアリソース (CPU、メモリー、ディスク、およびネットワーク) のシステムレベルの占有を表示します。
pcp-atopsar-
さまざまなシステムリソースの使用状況に関するシステムレベルのアクティビティーレポートを生成します。このレポートは、
pmloggerまたはpcp-atopの-wオプションを使用してあらかじめ記録された生のログファイルから生成されます。 pcp-buddyinfo- buddy アルゴリズムの統計情報を報告します。
pcp-dmcache- 設定されたデバイスマッパーキャッシュターゲット (デバイスの IOP、キャッシュデバイスとメタデータデバイスの使用率、各キャッシュデバイスの読み取り/書き込みのヒット率とミス率、比率など) に関する情報を表示します。
pcp-dstat-
一度に 1 台のシステムのメトリックを表示します。複数のシステムのメトリックを表示するには、
--hostオプションを使用します。 pcp-free- システム内の空きメモリーと使用済みメモリーを報告します。
pcp-htop-
システム上で実行されているすべてのプロセスとそのコマンドライン引数を、
topコマンドと同様の形式で表示しますが、縦横にスクロールしたり、マウスで操作したりすることができます。また、プロセスをツリー形式で表示したり、複数のプロセスを選択して一度に処理することもできます。 pcp-ipcs- 呼び出しプロセスが読み取りアクセスできる inter-process communication (IPC) ファシリティーの情報を表示します。
pcp-meminfo- カーネルシステムメモリーの統計情報を報告します。
pcp-mpstat- CPU および割り込み関連の統計情報を報告します。
pcp-netstat- ネットワークプロトコルとネットワークインターフェイスの統計情報を報告します。
pcp-numastat- カーネルのメモリーアロケータからの NUMA 割り当て統計を表示します。
pcp-pidstat- システム上で動作している個々のタスクやプロセスに関する情報を表示します (CPU パーセンテージ、メモリーやスタックの使用率、スケジューリング、優先度など)。デフォルトでは、ローカルホストのライブデータを報告します。
pcp-shping-
pmdashpingPerformance Metrics Domain Agent (PMDA) がエクスポートした shell-ping サービスメトリクスをサンプリングして報告します。 pcp-slabinfo- カーネルスラブアロケーターの統計情報を報告します。
pcp-ss-
pmdasocketsPMDA が収集したソケットの統計情報を表示します。 pcp-tapestat- テープデバイスの I/O 統計情報を報告します。
pcp-uptime- システムの稼働時間、現在ログオンしているユーザー数、過去 1 分、5 分、15 分のシステム負荷の平均値を表示します。
pcp-zoneinfo- Non-Uniform Memory Access (NUMA) ノードに関連する統計情報を報告します。
pcp-verify- Performance Co-Pilot コレクターのインストールのさまざまな側面を検査し、特定の動作モードに対して正しく設定されているかを報告します。
pmiostat-
SCSI デバイス (デフォルト) またはデバイスマッパーデバイス (
-xデバイスマッパーオプションを使用) の I/O 統計情報を報告します。 pmrep- 選択した、簡単にカスタマイズ可能なパフォーマンスメトリック値に関するレポート。
別途インストールする pcp-gui パッケージで配布されるツール
pmchart- Performance Co-Pilot の機能を介して利用可能なパフォーマンスメトリック値を描画します。
pmdumptext- ライブまたは Performance Co-Pilot アーカイブから収集されたパフォーマンスメトリックの値を出力します。
別途インストールする pcp-devel パッケージで配布されるツール
pmclient- PMAPI (Performance Metrics Application Programming Interface) を使用して、高水準のシステムパフォーマンスメトリックを表示します。
pmdbg- 利用可能な Performance Co-Pilot デバッグ制御フラグとその値を表示します。
pmerr- 利用可能な Performance Co-Pilot エラーコードと、それに対応するエラーメッセージを表示します。
別途インストールする pcp-geolocate パッケージで配布されるツール
pcp-geolocate- コレクターシステムの地理ラベルを検出し、ローカル PCP コレクターホストの緯度と経度を JSON 形式で報告します。
5.5. PCP デプロイメントのアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) は、PCP デプロイメントの規模に基づいて、複数のデプロイメントアーキテクチャーをサポートし、高度なセットアップを実現するための多くのオプションを提供します。
Red Hat によって設定された推奨デプロイメント、サイジング係数、および設定オプションに基づいた、利用可能なスケーリングデプロイメントセットアップバリアントには、以下が含まれます。
Localhost各サービスは監視対象のマシン上でローカルに動作します。設定を変更せずにサービスを開始した場合、これがデフォルトのデプロイメントです。この場合、個々のノードを超えたスケーリングはできません。
デフォルトでは、Redis のデプロイメント設定は、スタンドアロン、localhost となっています。しかし、Redis はオプションとして、データを複数のホストで共有する、高可用性と高スケーラビリティを備えたクラスター形態で実行することができます。また、クラウド上に Redis クラスターをデプロイしたり、クラウドベンダーが提供するマネージド Redis クラスターを利用したりすることも可能です。
Decentralizedローカルホストと分散型のセットアップの唯一の違いは、集中型の Redis サービスです。このモデルでは、ホストは監視対象の各ホスト上で
pmloggerサービスを実行し、ローカルのpmcdインスタンスからメトリックを取得します。そして、ローカルのpmproxyサービスは、パフォーマンスメトリックを中央の Redis インスタンスにエクスポートします。図5.1 分散型ロギング
集中型ロギング - pmlogger ファーム監視対象ホストのリソース使用量が制限されている場合、
pmloggerファームというデプロイメントオプションもあります。これは集中型ロギングとも呼ばれます。この設定では、1 つのロガーホストが複数のpmloggerプロセスを実行し、それぞれが異なるリモートpmcdホストからパフォーマンスメトリックを取得するように設定されます。集中ロガーのホストはpmproxyサービスを実行するように設定され、このサービスは、結果として生じる PCP アーカイブズのログを検出し、メトリックデータを Redis インスタンスに読み込みます。図5.2 集中型ロギング - pmlogger ファーム
統合型 - 複数の pmlogger ファーム大規模なデプロイメントの場合、Red Hat は複数の
pmloggerファームを統合させてデプロイすることを推奨します。例えば、ラックやデータセンターごとに 1 つのpmloggerファームをデプロイします。各pmloggerファームは、メトリックを中央の Redis インスタンスに読み込みます。図5.3 統合型 - 複数の pmlogger ファーム
デフォルトでは、Redis のデプロイメント設定は、スタンドアロン、localhost となっています。しかし、Redis はオプションとして、データを複数のホストで共有する、高可用性と高スケーラビリティを備えたクラスター形態で実行することができます。また、クラウド上に Redis クラスターをデプロイしたり、クラウドベンダーが提供するマネージド Redis クラスターを利用したりすることも可能です。
5.6. 推奨されるデプロイメントアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
次の表は、監視するホストの数に応じて推奨されるデプロイメントアーキテクチャーを示しています。
| ホストの数 (N) | 1-10 | 10-100 | 100-1000 |
|---|---|---|---|
|
| N | N | N |
|
| 1 から N | N/10 から N | N/100 から N |
|
| 1 から N | 1 から N | N/100 から N |
| Redis サーバー | 1 から N | 1 から N/10 | N/100 から N/10 |
| Redis クラスター | No | Maybe | Yes |
| 推奨されるデプロイメント設定 | ローカルホスト、分散型、または集中型のロギング | 分散型、集中型ロギング、または統合型 | 分散型または統合型 |
5.7. サイジングファクター リンクのコピーリンクがクリップボードにコピーされました!
スケーリングに必要なサイジングファクターは以下のとおりです。
Remote system size-
CPU、ディスク、ネットワーク・インターフェイスおよびその他のハードウェアリソースの数は、集中型ロギングホスト上の各
pmloggerが収集するデータ量に影響します。 Logged Metrics-
ログメトリックの数と種類が重要なロールを果たします。具体的には、
per-process proc.*メトリックには、大きなディスク容量が必要です。たとえば、標準的なpcp-zeroconfの設定で 10 秒のログ取得間隔の場合、proc メトリックなしでは 11MB、proc メトリックありでは 155MB と、係数は 10 倍以上になります。さらに、各メトリックのインスタンス数、たとえば CPU、ブロックデバイス、ネットワークインターフェイスの数なども、必要なストレージ容量に影響を与えます。 Logging Interval-
メトリックのログを取る間隔は、ストレージの要件に影響します。各
pmloggerインスタンスのpmlogger.logファイルには、毎日の PCP アーカイブファイルの予想サイズが書き込まれます。これらの値は圧縮されていない推定値です。PCP のアーカイブは約 10:1 と非常によく圧縮されるため、実際の長期的なディスク容量の要件は、特定のサイトで決定することができます。 pmlogrewrite-
PCP をアップグレードするたびに
pmlogrewriteツールが実行され、旧バージョンと新バージョンの PCP でメトリックのメタデータに変更があった場合、古いアーカイブが書き換えられます。この処理時間は、保存されているアーカイブの数に応じてリニアに変化します。
5.8. PCP スケーリングの設定オプション リンクのコピーリンクがクリップボードにコピーされました!
スケーリングに必要な設定オプションを以下に示します。
sysctl and rlimit settings-
アーカイブ検出を有効にすると、
pmproxyは、監視またはログテーリングを行っているすべてのpmloggerに対して 4 つの記述子を必要とし、さらに、サービスログとpmproxyクライアントソケットのための追加のファイル記述子があれば、それも必要となります。各pmloggerプロセスは、リモートのpmcdソケット、アーカイブファイル、サービスログなどのために約 20 個のファイル記述子を使用します。合計すると、約 200 のpmloggerプロセスを実行しているシステムでは、デフォルトの 1024 ソフトの制限を超えてしまいます。pcp-5.3.0以降のpmproxyサービスでは、ソフトリミットがハードリミットに自動的に引き上げられます。以前のバージョンの PCP では、多数のpmloggerプロセスをデプロイする場合、チューニングが必要です。これは、pmloggerのソフトリミットまたはハードリミットを増やすことで実現できます。詳細は、Red Hat ナレッジベースソリューション How to set limits (ulimit) for services run by systemd を参照してください。 ローカルアーカイブ-
pmloggerサービスは、ローカルおよびリモートのpmcdのメトリックを/var/log/pcp/pmlogger/ディレクトリーに保存します。ローカルシステムのロギング間隔を制御するには、/etc/pcp/pmlogger/control.d/configfileファイルを更新し、引数に-t Xを追加してください (Xは秒単位のロギング間隔)。どのメトリックを記録するかを設定するには、pmlogconf /var/lib/pcp/config/pmlogger/config.clienthostnameを実行します。このコマンドは、デフォルトのメトリックのセットを含む設定ファイルをデプロイしますが、オプションでさらにカスタマイズすることもできます。古い PCP アーカイブをいつパージするかという保存設定を行うには、/etc/sysconfig/pmlogger_timersfile and specifyPMLOGGER_DAILY_PARAMS="-E -k X"を更新します。ここで、Xは PCP アーカイブを保持する日数です。 Redispmproxyサービスは、pmloggerからのログされたメトリックを Redis インスタンスに送信します。設定ファイル/etc/pcp/pmproxy/pmproxy.confで保持設定を指定する際に使用できる 2 つのオプションを以下に示します。-
stream.expireでは、古いメトリックを削除するまでの期間を指定します (つまり、指定した秒数の間更新されなかったメトリック)。 -
stream.maxlenは、ホストごとに 1 つのメトリックの最大メトリック値の数を指定します。この設定は、保存期間をログ間隔で割ったものでなければなりません。例えば、保存期間が 14 日、ログ間隔が 60 秒の場合は 20160 となります (60*60*24*14/60)。
-
5.9. 例: 集中ロギングデプロイメントの分析 リンクのコピーリンクがクリップボードにコピーされました!
以下の結果は、集約ロギングセットアップ (pmlogger ファームデプロイメントとも呼ばれる) で集約されています。デフォルトの pcp-zeroconf 5.3.0 インストールでは、各リモートホストが、64 の CPU コア、376 GB RAM、および 1 つのディスクが接続されたサーバーで pmcd を実行している同一のコンテナーインスタンスになります。
ロギング間隔は 10 秒で、リモートノードの proc メトリックは含まれず、メモリー値は Resident Set Size (RSS) の値を参照します。
| ホスト数 | 10 | 50 |
|---|---|---|
| 1 日あたりの PCP アーカイブストレージ | 91 MB | 522 MB |
|
| 160 MB | 580 MB |
|
1 日あたりの | 2 MB | 9 MB |
|
| 1.4 GB | 6.3 GB |
| 1 日あたりの Redis メモリー | 2.6 GB | 12 GB |
| ホスト数 | 10 | 50 | 100 |
|---|---|---|---|
| 1 日あたりの PCP アーカイブストレージ | 20 MB | 120 MB | 271 MB |
|
| 104 MB | 524 MB | 1049 MB |
|
1 日あたりの | 0.38 MB | 1.75 MB | 3.48 MB |
|
| 2.67 GB | 5.5GB | 9 GB |
| 1 日あたりの Redis メモリー | 0.54 GB | 2.65 GB | 5.3 GB |
pmproxy は Redis 要求をキューに入れ、Redis パイプラインを使用して Redis クエリーを高速化します。これにより、メモリー使用率が高くなる可能性があります。この問題をトラブルシューティングする場合は、Troubleshooting high memory usage を参照してください。
5.10. 例: 統合型セットアップデプロイメントの分析 リンクのコピーリンクがクリップボードにコピーされました!
以下の結果が、統合型セットアップ (複数の pmlogger ファームとも呼ばれる) で確認されました。これは、3 つの集中ロギング (pmlogger ファーム) セットアップで構成されます。各 pmlogger ファームは 100 のリモートホスト、つまり合計 300 のホストを監視していました。
pmlogger ファームのこのセットアップは、Redis サーバーがクラスターモードで動作していたことを除いて、60 秒のロギング間隔での
例: 集中ロギングデプロイメントの分析 で説明した設定と同じです。
| 1 日あたりの PCP アーカイブストレージ | pmlogger メモリー | 1 日あたりのネットワーク (In/Out) | pmproxy メモリー | 1 日あたりの Redis メモリー |
|---|---|---|---|---|
| 277 MB | 1058 MB | 15.6 MB / 12.3 MB | 6-8 GB | 5.5 GB |
ここでは、すべての値はホストごとになります。Redis クラスターのノード間通信により、ネットワーク帯域幅が高まります。
5.11. セキュアな PCP 接続の確立 リンクのコピーリンクがクリップボードにコピーされました!
セキュアな PCP プロトコルエクスチェンジに参加するように、PCP コレクターとモニタリングコンポーネントを設定できます。
5.11.1. セキュアな PCP 接続 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) コレクターとモニタリングコンポーネントの間にセキュアな接続を確立できます。PCP コレクターコンポーネントは、さまざまなソースからパフォーマンスデータを収集および抽出する PCP の構成要素です。PCP モニターコンポーネントは、PCP コレクターコンポーネントがインストールされているホストまたはアーカイブから収集されたデータを表示する PCP の構成要素です。これらのコンポーネント間にセキュアな接続を確立すると、収集および監視対象のデータへの、権限のない第三者によるアクセスや変更を防ぐことができます。
Performance Metrics Collector Daemon (pmcd) との接続は、すべて TCP/IP ベースの PCP プロトコルを使用して行われます。プロトコルプロキシーと PCP REST API は pmproxy デーモンによって提供されます。REST API は HTTPS 経由でアクセスできるため、セキュアな接続が確保されます。
pmcd デーモンと pmproxy デーモンはどちらも、単一ポート上で TLS 通信と TLS 以外の通信を同時に実行できます。pmcd のデフォルトポートは 44321 で、pmproxy のデフォルトポートは 44322 です。これは、PCP コレクターシステムで TLS 通信と TLS 以外の通信のどちらかを選択する必要がなく、両方を同時に使用できることを意味します。
5.11.2. PCP コレクターコンポーネントのセキュアな接続の設定 リンクのコピーリンクがクリップボードにコピーされました!
セキュアな PCP プロトコルエクスチェンジに参加するには、すべての PCP コレクターシステムに有効な証明書が必要です。
pmproxy デーモンは、TLS の観点からはクライアントとサーバーの両方として動作します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
クライアントの秘密鍵が
/etc/pcp/tls/client.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS クライアント証明書が
/etc/pcp/tls/client.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。 -
CA 証明書が
/etc/pcp/tls/ca.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。さらに、pmproxyデーモンの場合、次の条件を満たす必要があります。 -
サーバーの秘密鍵が
/etc/pcp/tls/server.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。 -
TLS サーバー証明書が
/etc/pcp/tls/server.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。
手順
CA 発行の証明書を使用してセキュアな接続を確立するために、コレクターシステム上の PCP TLS 設定ファイルを更新します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PCP コレクターインフラストラクチャーを再起動します。
systemctl restart pmcd.service systemctl restart pmproxy.service
# systemctl restart pmcd.service # systemctl restart pmproxy.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TLS 設定を確認します。
pmcdサービスの場合:grep 'Info:' /var/log/pcp/pmcd/pmcd.log [Tue Feb 07 11:47:33] pmcd(6558) Info: OpenSSL 3.0.7 setup
# grep 'Info:' /var/log/pcp/pmcd/pmcd.log [Tue Feb 07 11:47:33] pmcd(6558) Info: OpenSSL 3.0.7 setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmproxyサービスの場合:grep 'Info:' /var/log/pcp/pmproxy/pmproxy.log [Tue Feb 07 11:44:13] pmproxy(6014) Info: OpenSSL 3.0.7 setup
# grep 'Info:' /var/log/pcp/pmproxy/pmproxy.log [Tue Feb 07 11:44:13] pmproxy(6014) Info: OpenSSL 3.0.7 setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.11.3. PCP モニタリングコンポーネントのセキュアな接続の設定 リンクのコピーリンクがクリップボードにコピーされました!
セキュアな PCP プロトコルエクスチェンジに参加するように、PCP モニタリングコンポーネントを設定します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
クライアントの秘密鍵が
~/.pcp/tls/client.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS クライアント証明書が
~/.pcp/tls/client.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。 -
CA 証明書が
/etc/pcp/tls/ca.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。
手順
次の情報を使用して TLS 設定ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow セキュアな接続を確立します。
export PCP_SECURE_SOCKETS=enforce export PCP_TLSCONF_PATH=~/.pcp/tls.conf
$ export PCP_SECURE_SOCKETS=enforce $ export PCP_TLSCONF_PATH=~/.pcp/tls.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
セキュアな接続が設定されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.12. 高メモリー使用率のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下のシナリオでは、メモリー使用率が高くなる可能性があります。
-
pmproxyプロセスは新しい PCP アーカイブの処理がビジーで、Redis の要求および応答を処理するための予備の CPU サイクルがありません。 - Redis ノードまたはクラスターが過負荷になり、時間が経過しても着信要求を処理できません。
pmproxy サービスデーモンは、Redis ストリームを使用し、設定パラメーター (PCP チューニングパラメーター) をサポートします。これは、Redis のメモリー使用量および鍵の保存に影響します。/etc/pcp/pmproxy/pmproxy.conf ファイルには、pmproxy で利用可能な設定オプションと、関連する API がリスト表示されます。
次の手順では、メモリー使用率が高い問題をトラブルシューティングする方法を説明します。
前提条件
pcp-pmda-redisパッケージをインストールします。dnf install pcp-pmda-redis
# dnf install pcp-pmda-redisCopy to Clipboard Copied! Toggle word wrap Toggle overflow redis PMDA をインストールします。
cd /var/lib/pcp/pmdas/redis && ./Install
# cd /var/lib/pcp/pmdas/redis && ./InstallCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
高いメモリー使用率のトラブルシューティングを行うには、次のコマンドを実行して、
inflight列を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この列は、Redis リクエストが転送中である数を示しています。つまり、キューに入れられているか送信されており、現時点では応答は受信されていません。
数値が高い場合は、次のいずれかの状態を示します。
-
pmproxyプロセスは新しい PCP アーカイブの処理がビジーで、Redis の要求および応答を処理するための予備の CPU サイクルがありません。 - Redis ノードまたはクラスターが過負荷になり、時間が経過しても着信要求を処理できません。
-
メモリー使用量が多い問題のトラブルシューティングを行うには、このファームの
pmloggerプロセスの数を減らし、別の pmlogger ファームを追加します。統合型 (複数の pmlogger ファームの設定) を使用します。Redis ノードが長時間にわたって CPU を 100% 使用している場合は、パフォーマンスが向上しているホストに移動するか、代わりにクラスター化された Redis 設定を使用します。
pmproxy.redis.*メトリックスを表示するには、次のコマンドを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow インフライトのリクエスト数を表示するには、
pmproxy.redis.requests.inflight.totalメトリックスとpmproxy.redis.requests.inflight.bytesメトリックスを参照して、現在のすべてのインフライトの Redis リクエストで占有されているバイト数を表示します。通常、redis 要求キューは 0 ですが、大きな pmlogger ファームの使用量に基づいて構築できます。これによりスケーラビリティーが制限され、
pmproxyクライアントのレイテンシーが高くなる可能性があります。pminfoコマンドを実行すると、パフォーマンスメトリックスの詳細が表示されます。たとえば、redis.*メトリックスを表示するには、次のコマンドを使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ピークメモリー使用量を表示するには、
redis.used_memory_peakメトリックスを参照してください。
第6章 pmda-openmetrics の設定 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP)は、システムパフォーマンスを監視および管理するための柔軟で拡張可能なシステムです。これには、PostgreSQL、Apache HTTPD、KVM 仮想マシンなどの一般的に使用されるアプリケーションやサービスからメトリクスを収集する、Performance Metric Domain Agents (PMDA)と呼ばれる組み込みエージェントが複数含まれています。
6.1. pmda-openmetrics の概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat リポジトリーには、追加設定なしの PMDA が存在しないカスタムまたは少ないアプリケーションを実行できます。このようなシナリオでは、pmda-openmetrics エージェントはギャップをブリッジするのに役立ちます。pmda-openmetrics PMDA は、OpenMetrics 形式の形式のテキストファイルを PCP 互換メトリクスに変換することで、任意のアプリケーションからパフォーマンスメトリックを公開します。OpenMetrics は、Prometheus およびその他のモニタリングツールによって使用される広く採用された形式であり、統合を容易にします。
pmda-openmetrics を実行して、次のタスクを実行できます。
- 既存の PMDA で対応していないカスタムアプリケーションを監視します。
-
既存の OpenMetrics または
Prometheus がエクスポートしたメトリクスを PCP フレームワークに統合します。 - 診断またはデモンストレーションの目的で、クイックモデルまたはテストメトリクスを作成する。
6.2. pmda-openmetrics のインストールおよび設定 リンクのコピーリンクがクリップボードにコピーされました!
pmda-openmetrics をインストールして設定する前に、pmda-openmetrics をインストールして設定する必要があります。以下の例は、pmda-openmetrics を使用して、テキストファイルから単一の数値を PCP メトリクスとして公開する方法を示しています。
前提条件
-
PCP がインストールされ、
pmcdが稼働している。詳細は PCP の pcp-zeroconf での設定 を 参照してください。
手順
pmda-openmetricsPMDA をインストールします。dnf -y install pcp-pmda-openmetrics cd /var/lib/pcp/pmdas/openmetrics/ ./Install
# dnf -y install pcp-pmda-openmetrics # cd /var/lib/pcp/pmdas/openmetrics/ # ./InstallCopy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル OpenMetrics ファイルを作成します。
echo 'var1 {var2="var3"} 42' > /tmp/example.txt# echo 'var1 {var2="var3"} 42' > /tmp/example.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow .txt の 例 を目的のファイル名に置き換えます。
ファイルが正しく作成されていることを確認します。
cat /tmp/example.txt
# cat /tmp/example.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow メトリックファイルのパスを OpenMetrics エージェントに登録します。
echo "file:///tmp/example.txt" > /etc/pcp/openmetrics/example.url
# echo "file:///tmp/example.txt" > /etc/pcp/openmetrics/example.urlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しく作成されていることを確認します。
cat /etc/pcp/openmetrics/example.url
# cat /etc/pcp/openmetrics/example.urlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なシンボリックリンクを作成するように
systemd-tmpfilesを設定します。echo 'L+ /var/lib/pcp/pmdas/openmetrics/config.d/example.url - - - - ../../../../../../etc/pcp/openmetrics/example.url' \ > /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.conf
# echo 'L+ /var/lib/pcp/pmdas/openmetrics/config.d/example.url - - - - ../../../../../../etc/pcp/openmetrics/example.url' \ > /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow symlink が正しく設定されていることを確認します。
cat /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.conf
# cat /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow tmpfiles 設定を適用することで、シンボリックリンクを作成します。
systemd-tmpfiles --create --remove /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.conf
# systemd-tmpfiles --create --remove /usr/lib/tmpfiles.d/pcp-pmda-openmetrics-cust.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow symlink が正しく作成されていることを確認します。
ls -al /var/lib/pcp/pmdas/openmetrics/config.d/
# ls -al /var/lib/pcp/pmdas/openmetrics/config.d/Copy to Clipboard Copied! Toggle word wrap Toggle overflow メトリックが正しく報告されていることを確認します。
pminfo -f openmetrics.example.var1 inst [0 or "0 var2:var3"] value 42# pminfo -f openmetrics.example.var1 inst [0 or "0 var2:var3"] value 42Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
-
pcpを実行し、openmetricsが表示されていることを確認します。 -
systemd-analyze cat-config tmpfiles.dを実行し、サンプル.urlが出力に表示されることを確認します。 -
pminfoを使用して、メトリックの存在と値を確認します。
第7章 pmlogger でのパフォーマンスデータのロギング リンクのコピーリンクがクリップボードにコピーされました!
PCP ツールを使用してパフォーマンスのメトリック値をログに記録すると、後で再生できます。これにより、遡及的なパフォーマンス解析を実行できます。
pmlogger ツールを使用すると、以下が可能になります。
- 選択したメトリックのアーカイブログをシステムに作成する
- システムに記録されるメトリックとその頻度を指定する
7.1. pmlogconf で pmlogger 設定ファイルの変更 リンクのコピーリンクがクリップボードにコピーされました!
pmlogger サービスの実行中、PCP はホストでメトリックのデフォルトセットをログに記録します。
pmlogconf ユーティリティーを使用してデフォルト設定を確認します。pmlogger 設定ファイルが存在しない場合は、pmlogconf がデフォルトのメトリック値で作成します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
pmlogger設定ファイルを作成または変更します。pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
# pmlogconf -r /var/lib/pcp/config/pmlogger/config.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
pmlogconfプロンプトに従い、関連するパフォーマンスメトリックのグループを有効または無効にし、有効な各グループのロギング間隔を制御します。
7.2. pmlogger の設定ファイルの手動編集 リンクのコピーリンクがクリップボードにコピーされました!
指定したメトリックと間隔でカスタマイズしたロギング設定を作成する場合は、pmlogger 設定ファイルを手動で編集します。デフォルトの pmlogger 設定ファイルは /var/lib/pcp/config/pmlogger/config.default です。設定ファイルでは、プライマリーのロギングインスタンスによって記録されるメトリックを指定します。
手動の設定では、以下が可能になります。
- 自動設定のリストに記載されていないメトリックを記録する。
- カスタムロギングの周波数を選択する。
- アプリケーションのメトリックを使用して PMDA を追加する。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
/var/lib/pcp/config/pmlogger/config.defaultファイルを開いて編集し、特定のメトリックを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. pmlogger サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
ローカルマシンでメトリック値のログを記録するには、pmlogger サービスを開始して有効にする必要があります。
この手順では、pmlogger サービスを有効にする方法を説明します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
pmloggerサービスを開始して、有効にします。systemctl start pmlogger systemctl enable pmlogger
# systemctl start pmlogger # systemctl enable pmloggerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmloggerサービスが有効になっているかどうかを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. メトリクス収集のためのクライアントシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、中央サーバーが、PCP を実行しているクライアントからメトリックを収集できるように、クライアントシステムを設定する方法を説明します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
pcp-system-toolsパッケージをインストールします。dnf install pcp-system-tools
# dnf install pcp-system-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmcdの IP アドレスを設定します。echo "-i 192.168.4.62" >>/etc/pcp/pmcd/pmcd.options
# echo "-i 192.168.4.62" >>/etc/pcp/pmcd/pmcd.optionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 192.168.4.62 を、クライアントがリッスンする IP アドレスに置き換えます。
デフォルトでは、
pmcdは、ローカルホストをリッスンします。パブリック
zoneを永続的に追加するように、ファイアウォールを設定します。firewall-cmd --permanent --zone=public --add-port=44321/tcp success firewall-cmd --reload success
# firewall-cmd --permanent --zone=public --add-port=44321/tcp success # firewall-cmd --reload successCopy to Clipboard Copied! Toggle word wrap Toggle overflow SELinux ブール値を設定します。
setsebool -P pcp_bind_all_unreserved_ports on
# setsebool -P pcp_bind_all_unreserved_ports onCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmcdサービスおよびpmloggerサービスを有効にします。systemctl enable pmcd pmlogger systemctl restart pmcd pmlogger
# systemctl enable pmcd pmlogger # systemctl restart pmcd pmloggerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmcdが、設定した IP アドレスを正しくリッスンしているかどうかを確認します。ss -tlp | grep 44321 LISTEN 0 5 127.0.0.1:44321 0.0.0.0:* users:(("pmcd",pid=151595,fd=6)) LISTEN 0 5 192.168.4.62:44321 0.0.0.0:* users:(("pmcd",pid=151595,fd=0)) LISTEN 0 5 [::1]:44321 [::]:* users:(("pmcd",pid=151595,fd=7))# ss -tlp | grep 44321 LISTEN 0 5 127.0.0.1:44321 0.0.0.0:* users:(("pmcd",pid=151595,fd=6)) LISTEN 0 5 192.168.4.62:44321 0.0.0.0:* users:(("pmcd",pid=151595,fd=0)) LISTEN 0 5 [::1]:44321 [::]:* users:(("pmcd",pid=151595,fd=7))Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5. データ収集用の中央サーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、PCP を実行しているクライアントからメトリックを収集する中央サーバーを作成する方法を説明します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
- クライアントがメトリック収集用に設定されている。詳細は、メトリクス収集のためのクライアントシステムの設定 を参照してください。
手順
pcp-system-toolsパッケージをインストールします。dnf install pcp-system-tools
# dnf install pcp-system-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の内容で
/etc/pcp/pmlogger/control.d/remoteファイルを作成してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 192.168.4.13、192.168.4.14、192.168.4.62、および 192.168.4.69 を、クライアントの IP アドレスに置き換えます。
pmcdサービスおよびpmloggerサービスを有効にします。systemctl enable pmcd pmlogger systemctl restart pmcd pmlogger
# systemctl enable pmcd pmlogger # systemctl restart pmcd pmloggerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
各ディレクトリーから最新のアーカイブファイルにアクセスできることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /var/log/pcp/pmlogger/ディレクトリーのアーカイブファイルは、詳細な分析とグラフ作成に使用できます。
7.6. systemd ユニットと pmlogger リンクのコピーリンクがクリップボードにコピーされました!
pmlogger サービスを、それ自体を監視する単一のホストとして、または複数のリモートホストからメトリクスを収集する単一のホストを含む pmlogger ファームとしてデプロイすると、関連する systemd サービスとタイマーユニットがいくつか自動的にデプロイされます。これらのサービスとタイマーは、pmlogger インスタンスが実行していることを確認するための定期的なチェックを提供し、不足しているインスタンスを再起動し、ファイル圧縮などのアーカイブ管理を実行します。
pmlogger によって通常展開されるチェックおよびハウスキーピングサービスは次のとおりです。
pmlogger_daily.service-
デフォルトでは、毎日、深夜直後に実行され、1 つ以上の PCP アーカイブセットを集約、圧縮、およびローテートします。また、制限 (デフォルトでは 2 週間) よりも古いアーカイブも削除されます。
pmlogger.serviceユニットに必要なpmlogger_daily.timerユニットによってトリガーされます。 pmlogger_check-
pmloggerインスタンスが実行中であるかどうかを 30 分ごとにチェックします。不足しているインスタンスを再起動し、必要な圧縮タスクを実行します。pmlogger.serviceユニットに必要なpmlogger_check.timerユニットによってトリガーされます。 pmlogger_farm_check-
設定されたすべての
pmloggerインスタンスのステータスを確認します。不足しているインスタンスを再起動します。すべての非プライマリーインスタンスをpmlogger_farmサービスに移行します。pmlogger_farm_check.timerによってトリガーされます。これは、pmlogger_farm.serviceユニットによって必要とされ、pmlogger_farm.service ユニット自体はpmlogger.serviceユニットによって必要とされます。
これらのサービスは一連の肯定的な依存関係を通じて管理されます。つまり、プライマリー pmlogger インスタンスをアクティブ化すると、すべて有効になります。pmlogger_daily.service はデフォルトで無効になっていますが、pmlogger.service との依存関係によって pmlogger_daily.timer がアクティブになると、pmlogger_daily.service の実行がトリガーされることに注意してください。
pmlogger_daily は、マージ前にアーカイブを自動的に書き換えるために pmlogrewrite とも統合されています。これにより、実稼働環境や PMDA が変化する中でもメタデータの一貫性を確保できます。たとえば、ログ記録間隔中に監視対象ホストの 1 台で pmcd が更新されると、ホスト上の一部のメトリクスのセマンティクスが更新され、新しいアーカイブがそのホストから以前に記録されたアーカイブと互換性がなくなる可能性があります。詳細は、pmlogrewrite(1) の man ページを参照してください。
pmlogger によってトリガーされる systemd サービスの管理
pmlogger インスタンスによって収集されたデータ用の自動化されたカスタムアーカイブ管理システムを作成できます。これは制御ファイルを使用して行われます。これらの制御ファイルは次のとおりです。
プライマリー
pmloggerインスタンスの場合:-
etc/pcp/pmlogger/control -
/etc/pcp/pmlogger/control.d/local
-
リモートホストの場合:
/etc/pcp/pmlogger/control.d/remoteremote を希望のファイル名に置き換えます。
- 注記
-
プライマリー
pmloggerインスタンスは、接続先のpmcdと同じホストで実行している必要があります。1 つのセントラルホストがリモートホストで実行しているpmcdインスタンスに接続された複数のpmloggerインスタンスでデータを収集している場合は、プライマリーインスタンスは必要ありません。また、設定でプライマリーインスタンスが必要ない場合もあります。
ファイルには、ログに記録するホストごとに 1 行が含まれている必要があります。自動的に作成されるプライマリーロガーインスタンスのデフォルトの形式は次のようになります。
フィールドの詳細は以下のとおりです。
Host- ログに記録するホスト名
P?-
“Primary?” の略です。このフィールドは、ホストがプライマリーロガーインスタンスである (
y) か、そうでない (n) かを示します。設定内のすべてのファイルにわたってプライマリーロガーは 1 つだけ存在でき、接続先のpmcdと同じホスト上で実行している必要があります。 S?-
“Socks?” の略です。このフィールドは、このロガーインスタンスがファイアウォール経由で
pmcdに接続するためにSOCKSプロトコルを使用する必要がある (y) か、必要がない (n) かを示します。 directory- この行に関連付けられたすべてのアーカイブがこのディレクトリーに作成されます。
argspmloggerに渡される引数。argsフィールドのデフォルト値は次のとおりです。-r- アーカイブのサイズと増加率を報告します。
T24h10m-
各日のログ記録を終了するタイミングを指定します。これは通常、
pmlogger_daily.serviceが実行する時間です。デフォルト値の24h10mは、ログ記録が開始してから遅くとも 24 時間 10 分後に終了することを示します。 -c config.default- 使用する設定ファイルを指定します。これは基本的に、記録するメトリクスを定義します。
-v 100Mb-
1 つのデータボリュームがいっぱいになり、別のボリュームが作成されるサイズを指定します。新しいアーカイブに切り替わった後、以前に記録されたものは
pmlogger_dailyまたはpmlogger_checkのいずれかによって圧縮されます。
7.7. pmrep で PCP ログアーカイブの再生 リンクのコピーリンクがクリップボードにコピーされました!
メトリックデータの記録後、PCP ログアーカイブを再生できます。ログをテキストファイルにエクスポートして、スプレッドシートにインポートするには、pcp2csv、pcp2xml、pmrep または pmlogsummary などの PCP ユーティリティーを使用します。
pmrep ツールを使用すると、以下のことが可能になります。
- ログファイルを表示する
- 選択した PCP ログアーカイブを解析し、値を ASCII テーブルにエクスポートする
- アーカイブログ全体をデプロイメントするか、コマンドラインで個別のメトリックを指定して、ログからメトリック値のみを選択する
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
-
pmloggerサービスが有効になっている。詳細は、pmlogger サービスの有効化 を参照してください。 pcp-guiパッケージがインストールされている。dnf install pcp-gui
# dnf install pcp-guiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
メトリックのデータを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、5 秒 間隔でアーカイブに収集された
disk.dev.writeメトリックスのデータをコンマ区切り値の形式で表示します。注記この例の
20211128を、データを表示するpmloggerアーカイブを含むファイル名に置き換えます。
7.8. PCP バージョン 3 アーカイブの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) アーカイブは、単一のホストから記録した PCP メトリクスの過去の値を保存し、遡及的なパフォーマンス分析をサポートします。PCP アーカイブには、オフラインまたはオフサイト分析に必要なすべての重要なメトリクスデータとメタデータが含まれています。これらのアーカイブは、ほとんどの PCP クライアントツールで読み取ることも、pmdumplog ツールでそのままダンプすることもできます。
PCP 6.0 からは、バージョン 2 アーカイブに加えてバージョン 3 アーカイブもサポートされます。バージョン 2 アーカイブは、引き続きデフォルトであり、下位互換性の目的で今後も長期サポートを受けます。バージョン 3 アーカイブは、RHEL 9.2 以降から長期サポートを受けます。
PCP バージョン 3 アーカイブを使用すると、バージョン 2 に比べて次の利点があります。
- インスタンスのドメイン変更デルタのサポート
- Y2038 対応のタイムスタンプ
- ナノ秒精度のタイムスタンプ
- 任意のタイムゾーンのサポート
- 2 GB を超える個々のボリュームに使用される 64 ビットファイルオフセット
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
任意のテキストエディターで
/etc/pcp.confファイルを開き、PCP アーカイブバージョンを設定します。PCP_ARCHIVE_VERSION=3
PCP_ARCHIVE_VERSION=3Copy to Clipboard Copied! Toggle word wrap Toggle overflow pmloggerサービスを再起動して、設定の変更を適用します。systemctl restart pmlogger.service
# systemctl restart pmlogger.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 新しい設定を使用して、新しい PCP アーカイブログを作成します。詳細は、pmlogger でのパフォーマンスデータのロギング を参照してください。
検証
新しい設定で作成したアーカイブのバージョンを確認します。
pmloglabel -l /var/log/pcp/pmlogger/20230208 Log Label (Log Format Version 3) Performance metrics from host host1 commencing Wed Feb 08 00:11:09.396 2023 ending Thu Feb 07 00:13:54.347 2023# pmloglabel -l /var/log/pcp/pmlogger/20230208 Log Label (Log Format Version 3) Performance metrics from host host1 commencing Wed Feb 08 00:11:09.396 2023 ending Thu Feb 07 00:13:54.347 2023Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 Performance Co-Pilot によるパフォーマンスの監視 リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot (PCP) は、システムレベルのパフォーマンス測定を監視、視覚化、保存、および分析するためのツール、サービス、およびライブラリーのスイートです。
システム管理者は、Red Hat Enterprise Linux 9 の PCP アプリケーションを使用して、システムのパフォーマンスを監視できます。
8.1. pmda-postfix での postfix の監視 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、pmda-postfix を使用して postfix メールサーバーのパフォーマンスメトリックを監視する方法を説明します。これは、1 秒間に受信した電子メールの数を確認するのに役立ちます。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
-
pmloggerサービスが有効になっている。詳細は、pmlogger サービスの有効化 を参照してください。
手順
以下のパッケージをインストールします。
pcp-system-toolsをインストールします。dnf install pcp-system-tools
# dnf install pcp-system-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmda-postfixパッケージをインストールして、postfixを監視します。dnf install pcp-pmda-postfix postfix
# dnf install pcp-pmda-postfix postfixCopy to Clipboard Copied! Toggle word wrap Toggle overflow ロギングデーモンをインストールします。
dnf install rsyslog
# dnf install rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow テスト用にメールクライアントをインストールします。
dnf install mutt
# dnf install muttCopy to Clipboard Copied! Toggle word wrap Toggle overflow
postfixサービスおよびrsyslogサービスを有効にします。systemctl enable postfix rsyslog systemctl restart postfix rsyslog
# systemctl enable postfix rsyslog # systemctl restart postfix rsyslogCopy to Clipboard Copied! Toggle word wrap Toggle overflow SELinux ブール値を有効にして、
pmda-postfixが必要なログファイルにアクセスできるようにします。setsebool -P pcp_read_generic_logs=on
# setsebool -P pcp_read_generic_logs=onCopy to Clipboard Copied! Toggle word wrap Toggle overflow PMDAをインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmda-postfix操作を確認します。echo testmail | mutt root
echo testmail | mutt rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 利用可能なメトリックを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. PCP Charts アプリケーションで PCP ログアーカイブを視覚的にトレース リンクのコピーリンクがクリップボードにコピーされました!
メトリックデータの記録後、PCP ログアーカイブをグラフとして再生できます。メトリックは、PCP ログアーカイブのメトリックデータを履歴データのソースとして使用する代替オプションを持つ 1 台または複数のライブホストから提供されます。PCP Charts アプリケーションインターフェイスをカスタマイズしてパフォーマンスメトリックのデータを表示するには、ラインプロット、バーグラフ、または使用状況グラフを使用します。
PCP Charts アプリケーションを使用すると、以下が可能になります。
- PCP Charts アプリケーションのデータを再生し、グラフを使用して、システムのライブデータとともに遡及データを視覚化する。
- パフォーマンスメトリック値をグラフに描画する。
- 複数のチャートを同時に表示する。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
-
pmloggerでパフォーマンスデータをログに記録している。詳細は、pmlogger でのパフォーマンスデータのロギング を参照してください。 pcp-guiパッケージがインストールされている。dnf install pcp-gui
# dnf install pcp-guiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
コマンドラインで PCP Charts アプリケーションを起動します。
pmchart
# pmchartCopy to Clipboard Copied! Toggle word wrap Toggle overflow 図8.1 PCP Charts アプリケーション
pmtimeサーバー設定は下部にあります。start ボタンおよび pause ボタンを使用すると、以下を制御できます。- PCP がメトリックデータをポーリングする間隔
- 履歴データのメトリックの日付および時間
- File をクリックしてから、New Chart をクリックして、ホスト名またはアドレスを指定して、ローカルマシンおよびリモートマシンの両方からメトリックを選択します。高度な設定オプションには、チャートの軸値を手動で設定する機能、およびプロットの色を手動で選択する機能が含まれます。
PCP Charts アプリケーションで作成したビューを記録します。
以下は、PCP Charts アプリケーションで作成したイメージを撮影したり、ビューを記録するためのオプションです。
- File をクリックしてから Export をクリックして、現在のビューのイメージを保存します。
- Record をクリックしてから Start をクリックし、録画を開始します。Record をクリックしてから Stop をクリックし、録画を停止します。録画の停止後、記録されたメトリックは後で表示できるようにアーカイブが作成されます。
必要に応じて、PCP Charts アプリケーションでは、ビュー と呼ばれるメインの設定ファイルによって、1 つ以上のチャートに関連付けられたメタデータを保存できます。このメタデータでは、使用されるメトリックや、チャート列など、チャート側面をすべて記述します。File をクリックしてから Save View をクリックして、カスタム view 設定を保存し、後で view 設定を読み込みます。
以下の PCP Charts アプリケーションビューの設定ファイルの例では、指定の XFS ファイルシステム
loop1に対して読み書きされた合計バイト数を示す積み上げチャートグラフを説明します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. PCP を使用した SQL Server からのデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
SQL Server エージェントは、PCP (Performance Co-Pilot) で利用できます。これにより、データベースのパフォーマンス問題を監視および分析できます。
この手順では、システムの pcp を使用して Microsoft SQL Server のデータを収集する方法を説明します。
前提条件
- Red Hat Enterprise Linux に Microsoft SQL Server をインストールし、SQL Server への '信頼できる' 接続を確立している。
- Red Hat Enterprise Linux 用の SQL Server の Microsoft ODBC ドライバーがインストールされている。
手順
PCP をインストールします。
dnf install pcp-zeroconf
# dnf install pcp-zeroconfCopy to Clipboard Copied! Toggle word wrap Toggle overflow pyodbcドライバーに必要なパッケージをインストールします。dnf install python3-pyodbc
# dnf install python3-pyodbcCopy to Clipboard Copied! Toggle word wrap Toggle overflow mssqlエージェントをインストールします。PCP の Microsoft SQL Server ドメインエージェントをインストールします。
dnf install pcp-pmda-mssql
# dnf install pcp-pmda-mssqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/pcp/mssql/mssql.confファイルを編集して、mssqlエージェントの SQL サーバーアカウントのユーザー名およびパスワードを設定します。設定するアカウントに、パフォーマンスデータに対するアクセス権限があることを確認します。username: user_name password: user_password
username: user_name password: user_passwordCopy to Clipboard Copied! Toggle word wrap Toggle overflow user_name を SQL Server アカウントに置き換え、user_password をこのアカウントの SQL Server ユーザーパスワードに置き換えます。
エージェントをインストールします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pcpコマンドを使用して、SQL Server PMDA (mssql) が読み込まれて実行されていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow PCP が SQL Server から収集できるメトリックの完全なリストを表示します。
pminfo mssql
# pminfo mssqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow メトリックのリストを表示した後は、トランザクションのレートを報告できます。たとえば、5 秒間の時間枠で、1 秒あたりの全体的なトランザクション数を報告するには、以下のコマンドを実行します。
pmval -t 1 -T 5 mssql.databases.transactions
# pmval -t 1 -T 5 mssql.databases.transactionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
pmchartコマンドを使用して、システムでこれらのメトリックのグラフィックチャートを表示します。詳細は、Visually tracing PCP log archives with the PCP Charts application を参照してください。
8.4. sadc アーカイブから PCP アーカイブの生成 リンクのコピーリンクがクリップボードにコピーされました!
sysstat が提供する sadf ツールを使用して、ネイティブの sadc アーカイブから PCP アーカイブを生成できます。
前提条件
sadcアーカイブが作成されました。/usr/lib64/sa/sadc 1 5 -
# /usr/lib64/sa/sadc 1 5 -Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
sadcは 5 秒間隔でシステムデータを 1 回サンプリングします。出力ファイルは、標準システムアクティビティーの日次データファイルにデータを書き込むsadcになる-として指定されます。このファイルの名前は saDD で、デフォルトで /var/log/sa ディレクトリーにあります。
手順
sadcアーカイブから PCP アーカイブを生成します。sadf -l -O pcparchive=/tmp/recording -2
# sadf -l -O pcparchive=/tmp/recording -2Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
-2オプションを使用すると 2 日前に記録されたsadcアーカイブから PCP アーカイブをsadfが生成します。
検証
PCP コマンドを使用すると、ネイティブ PCP アーカイブの場合と同様に、sadc アーカイブから生成された PCP アーカイブを調べて分析できます。以下に例を示します。
sadcアーカイブから生成された PCP アーカイブのメトリックのリストを表示するには、次のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow アーカイブのタイムスペースと、PCP アーカイブのホスト名を表示するには、次のコマンドを実行します。
pmdumplog --label /tmp/recording Log Label (Log Format Version 2) Performance metrics from host shard commencing Tue Jul 20 00:10:30.642477 2021 ending Wed Jul 21 00:10:30.222176 2021$ pmdumplog --label /tmp/recording Log Label (Log Format Version 2) Performance metrics from host shard commencing Tue Jul 20 00:10:30.642477 2021 ending Wed Jul 21 00:10:30.222176 2021Copy to Clipboard Copied! Toggle word wrap Toggle overflow パフォーマンスメトリックの値をグラフにプロットするには、次のコマンドを実行します。
pmchart --archive /tmp/recording
$ pmchart --archive /tmp/recordingCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第9章 PCP を使用した XFS のパフォーマンス分析 リンクのコピーリンクがクリップボードにコピーされました!
XFS PMDA は、pcp パッケージの一部として提供され、インストール時にデフォルトで有効になります。これは、Performance Co-Pilot (PCP) で XFS ファイルシステムのパフォーマンスメトリックデータを収集するために使用されます。
PCP を使用して、XFS ファイルシステムのパフォーマンスを分析できます。
9.1. XFS PMDA の手動インストール リンクのコピーリンクがクリップボードにコピーされました!
XFS PMDA が pcp 設定出力に記載されていない場合は、PMDA エージェントを手動でインストールします。
この手順では、PMDA エージェントを手動でインストールする方法を説明します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
xfs ディレクトリーに移動します。
cd /var/lib/pcp/pmdas/xfs/
# cd /var/lib/pcp/pmdas/xfs/Copy to Clipboard Copied! Toggle word wrap Toggle overflow XFS PMDA を手動でインストールします。
xfs]# ./Install Updating the Performance Metrics Name Space (PMNS) ... Terminate PMDA if already installed ... Updating the PMCD control file, and notifying PMCD ... Check xfs metrics have appeared ... 387 metrics and 387 values
xfs]# ./Install Updating the Performance Metrics Name Space (PMNS) ... Terminate PMDA if already installed ... Updating the PMCD control file, and notifying PMCD ... Check xfs metrics have appeared ... 387 metrics and 387 valuesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmcdプロセスがホストで実行しており、設定リストに XFS PMDA が有効として記載されていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. pminfo を使用した XFS パフォーマンスメトリックの検証 リンクのコピーリンクがクリップボードにコピーされました!
PCP は XFS PMDA を有効にして、マウントされた各 XFS ファイルシステムに対して特定の XFS メトリックの報告を可能にします。これにより、特定のマウントされたファイルシステムの問題を特定して、パフォーマンスを評価することが容易になります。
pminfo コマンドは、マウントされた各 XFS ファイルシステムの各デバイスに対する XFS メトリックを提供します。
この手順では、XFS PMDA が提供する利用可能なすべてのメトリックのリストを表示します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
XFS PMDA が提供する利用可能なメトリックのリストを表示します。
pminfo xfs
# pminfo xfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 個別のメトリックの情報を表示します。以下の例は、
pminfoツールを使用して、特定の XFS のreadメトリックおよびwriteメトリックを検証します。xfs.write_bytesメトリックの簡単な説明を表示します。pminfo --oneline xfs.write_bytes xfs.write_bytes [number of bytes written in XFS file system write operations]
# pminfo --oneline xfs.write_bytes xfs.write_bytes [number of bytes written in XFS file system write operations]Copy to Clipboard Copied! Toggle word wrap Toggle overflow xfs.read_bytesメトリックの長い説明を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow xfs.read_bytesメトリックの現在のパフォーマンス値を取得します。pminfo --fetch xfs.read_bytes xfs.read_bytes value 4891346238# pminfo --fetch xfs.read_bytes xfs.read_bytes value 4891346238Copy to Clipboard Copied! Toggle word wrap Toggle overflow pminfoで、デバイスごとの XFS メトリックを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. pmstore を使用した XFS パフォーマンスメトリックのリセット リンクのコピーリンクがクリップボードにコピーされました!
PCP を使用すると、特に特定のメトリックが、xfs.control.reset メトリックなどの制御変数として動作する場合は、そのメトリックの値を変更できます。メトリックの値を変更するには、pmstore ツールを使用します。
この手順では、pmstore ツールを使用して XFS メトリックをリセットする方法を説明します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
メトリックの値を表示します。
pminfo -f xfs.write xfs.write value 325262$ pminfo -f xfs.write xfs.write value 325262Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべての XFS メトリックをリセットします。
pmstore xfs.control.reset 1 xfs.control.reset old value=0 new value=1
# pmstore xfs.control.reset 1 xfs.control.reset old value=0 new value=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
メトリックをリセットした後に情報を表示します。
pminfo --fetch xfs.write xfs.write value 0$ pminfo --fetch xfs.write xfs.write value 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. XFS の PCP メトリックグループ リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、XFS で利用可能な PCP メトリックグループを説明しています。
| メトリックグループ | 提供されたメトリック |
|
| 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
|
| ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
|
| メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
|
| 作成、エントリー削除、“getdent” の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
|
| メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。 |
|
| オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
|
| XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。 |
|
| XFS フラッシュデーモンによりフラッシュされたファイルデータのバイト数と、ディスク上の連続および非連続の領域にフラッシュされたバッファーの数のカウンター。 |
|
| すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。 |
|
| XFS ファイルシステムでのクォータ操作のメトリック。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。 |
|
| XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
|
| XFS btree の操作に関するメトリック。 |
|
| XFS 統計のメトリックカウンターをリセットするのに使用される設定メトリック。コントロールメトリックは、pmstore ツールを使用して切り替えられます。 |
9.5. XFS のデバイスごとの PCP メトリックグループ リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、XFS で利用可能なデバイスごとの PCP メトリックグループを説明しています。
| メトリックグループ | 提供されたメトリック |
|
| 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
|
| ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
|
| メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
|
| 作成、エントリー削除、“getdent” の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
|
| メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。 |
|
| オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
|
| XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。 |
|
| XFS フラッシュデーモンによりフラッシュされたファイルデータのバイト数と、ディスク上の連続および非連続の領域にフラッシュされたバッファーの数のカウンター。 |
|
| すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。 |
|
| XFS ファイルシステムでのクォータ操作のメトリック。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。 |
|
| XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
|
| XFS btree の操作に関するメトリック。 |
第10章 PCP メトリックのグラフィカル表示の設定 リンクのコピーリンクがクリップボードにコピーされました!
pcp、grafana、pcp redis、pcp bpftrace、pcp vector を組み合わせて使用すると、ライブデータまたは Performance Co-Pilot (PCP) によって収集されたデータをグラフィカルに表示できます。
10.1. pcp-zeroconf を使用した PCP の設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、pcp-zeroconf パッケージでシステムに PCP を設定する方法を説明します。pcp-zeroconf パッケージがインストールされると、システムはメトリックのデフォルトセットをアーカイブファイルに記録します。
手順
pcp-zeroconfパッケージをインストールします。dnf install pcp-zeroconf
# dnf install pcp-zeroconfCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmloggerサービスがアクティブであることを確認し、メトリックのアーカイブを開始します。pcp | grep pmlogger pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12
# pcp | grep pmlogger pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2. Grafana サーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Grafana は、ブラウザーからアクセスできるグラフを生成します。Grafana サーバーは、Grafana ダッシュボードのバックエンドサーバーです。これは、デフォルトですべてのインターフェイスでリッスンし、Web ブラウザーからアクセスする Web サービスを提供します。grafana-pcp プラグインは、バックエンドの pmproxy デーモンと対話します。
この手順では、Grafana サーバーをセットアップする方法について説明します。
前提条件
- PCP が設定されている。詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
手順
以下のパッケージをインストールします。
dnf install grafana grafana-pcp
# dnf install grafana grafana-pcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサービスを再起動して有効にします。
systemctl restart grafana-server systemctl enable grafana-server
# systemctl restart grafana-server # systemctl enable grafana-serverCopy to Clipboard Copied! Toggle word wrap Toggle overflow Grafana サービスへのネットワークトラフィック用にサーバーのファイアウォールを開きます。
firewall-cmd --permanent --add-service=grafana success firewall-cmd --reload success
# firewall-cmd --permanent --add-service=grafana success # firewall-cmd --reload successCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Grafana サーバーが要求を待ち受けて応答していることを確認します。
ss -ntlp | grep 3000 LISTEN 0 128 *:3000 *:* users:(("grafana-server",pid=19522,fd=7))# ss -ntlp | grep 3000 LISTEN 0 128 *:3000 *:* users:(("grafana-server",pid=19522,fd=7))Copy to Clipboard Copied! Toggle word wrap Toggle overflow grafana-pcpプラグインがインストールされていることを確認します。grafana-cli plugins ls | grep performancecopilot-pcp-app performancecopilot-pcp-app @ 5.1.1
# grafana-cli plugins ls | grep performancecopilot-pcp-app performancecopilot-pcp-app @ 5.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3. Grafana Web UI へのアクセス リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Grafana Web インターフェイスにアクセスする方法を説明します。
Grafana Web インターフェイスを使用すると、以下が可能になります。
- PCP Redis、PCP bpftrace、および PCP Vector データソースを追加する
- ダッシュボードを作成する
- 有用なメトリクスの概要を表示する
- PCP Redis でアラートを作成する
前提条件
- PCP が設定されている。詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
手順
-
クライアントシステムで、ブラウザーから
http://<grafana_server_IP_address_or_hostname>:3000を開きます。 最初のログインでは、Email or username と Password の両方のフィールドに admin と入力します。
Grafana は、新しいパスワード を設定してセキュアなアカウントを作成するようにプロンプトを表示します。
- メニューで Administration に移動し、Plugins をクリックします。
-
Plugins タブで、Search Grafana plugins テキストボックスに
Performance Co-Pilotと入力し、Performance Co-Pilot (PCP) プラグインをクリックします。 - Plugins / Performance Co-Pilot ペインで、 をクリックします。
Grafana アイコン
をクリックします。Grafana Home ページが表示されます。
図10.1 Home ダッシュボード
注記画面右上には、一般的な ダッシュボード 設定を制御する設定(歯車アイコン)アイコン
があります。
Grafana Home ページで、Add your first data source をクリックして PCP Redis、PCP bpftrace、および PCP Vector データソースを追加します。データソースの追加に関する詳細は、以下を参照してください。
- pcp redis データソースを追加するには、デフォルトのダッシュボードを表示し、パネルとアラートルールを作成します。詳細は、PCP Redis データソースでのパネルおよびアラートの作成 を参照してください。
- pcp bpftrace データソースを追加してデフォルトのダッシュボードを表示するには、PCP bpftrace システム分析ダッシュボードの表示 を参照してください。
- pcp vector データソースを追加するには、デフォルトのダッシュボードを表示します。Vector Checklist を表示するには、PCP Vector Checklist の表示 を参照してください。
-
オプション:メニューで、admin プロファイルアイコン
にカーソルを合わせると、Profile を更新するか、Notifications history を表示、Change password、または Sign out out を行います。
10.4. Grafana のセキュアな接続の設定 リンクのコピーリンクがクリップボードにコピーされました!
Grafana と Performance Co-Pilot (PCP) コンポーネントの間にセキュアな接続を確立できます。これらのコンポーネント間にセキュアな接続を確立すると、収集および監視対象のデータへの、権限のない第三者によるアクセスや変更を防ぐことができます。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
クライアントの秘密鍵が
/etc/grafana/grafana.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS クライアント証明書が
/etc/grafana/grafana.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。
手順
root ユーザーとして、
/etc/grafana/grafana.iniファイルを開き、[server]セクションの次のオプションを調整して、以下の内容を反映させます。protocol = https cert_key = /etc/grafana/grafana.key cert_file = /etc/grafana/grafana.crt
protocol = https cert_key = /etc/grafana/grafana.key cert_file = /etc/grafana/grafana.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow grafana が証明書にアクセスできることを確認します。
su grafana -s /bin/bash -c \ 'ls -1 /etc/grafana/grafana.crt /etc/grafana/grafana.key' /etc/grafana/grafana.crt /etc/grafana/grafana.key
# su grafana -s /bin/bash -c \ 'ls -1 /etc/grafana/grafana.crt /etc/grafana/grafana.key' /etc/grafana/grafana.crt /etc/grafana/grafana.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Grafana サービスを再起動して有効にし、設定の変更を適用します。
systemctl restart grafana-server systemctl enable grafana-server
# systemctl restart grafana-server # systemctl enable grafana-serverCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- クライアントシステムでブラウザーを開き、https://192.0.2.0:3000 リンクを使用してポート 3000 の Grafana サーバーマシンにアクセスします。192.0.2.0 は、マシンの IP に置き換えます。
アドレスバーの横にロックアイコン
が表示されていることを確認します。
注記プロトコルが
httpに設定されている場合に HTTPS 接続を試行すると、ERR_SSL_PROTOCOL_ERRORエラーが発生します。プロトコルがhttpsに設定されている場合に HTTP 接続を試行すると、Grafana サーバーは "Client sent an HTTP request to an HTTPS server" というメッセージで応答します。
10.5. PCP Redis の設定 リンクのコピーリンクがクリップボードにコピーされました!
PCP Redis データソースを使用して以下を行います。
- データアーカイブの表示
- pmseries 言語を使用したクエリー時系列
- 複数のホストにまたがるデータの分析
前提条件
- PCP が設定されている。詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
-
メール転送エージェント (
sendmailまたはpostfixなど) がインストールされ、設定されている。
手順
redisパッケージをインストールします。dnf install redis
# dnf install redisCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサービスを開始して有効にします。
systemctl start pmproxy redis systemctl enable pmproxy redis
# systemctl start pmproxy redis # systemctl enable pmproxy redisCopy to Clipboard Copied! Toggle word wrap Toggle overflow Grafana サーバーを再起動します。
systemctl restart grafana-server
# systemctl restart grafana-serverCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
pmproxyおよびredisが動作していることを確認します。pmseries disk.dev.read 2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
# pmseries disk.dev.read 2eb3e58d8f1e231361fb15cf1aa26fe534b4d9dfCopy to Clipboard Copied! Toggle word wrap Toggle overflow redisパッケージがインストールされていない場合は、このコマンドはデータを返しません。
10.6. PCP Redis のセキュアな接続の設定 リンクのコピーリンクがクリップボードにコピーされました!
パフォーマンスコパイロット (PCP)、Grafana、および PCP redis の間にセキュアな接続を確立できます。これらのコンポーネント間にセキュアな接続を確立すると、収集および監視対象のデータへの、権限のない第三者によるアクセスや変更を防ぐことができます。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
- PCP redis がインストールされている。詳細は PCP Redis の設定 を参照してください。
クライアントの秘密鍵が
/etc/redis/client.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS クライアント証明書が
/etc/redis/client.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。 -
TLS サーバー鍵が
/etc/redis/redis.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。 -
TLS サーバー証明書が
/etc/redis/redis.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。 -
CA 証明書が
/etc/redis/ca.crtファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。
さらに、pmproxy デーモンの場合、次の条件を満たす必要があります。
-
サーバーの秘密鍵が
/etc/pcp/tls/server.keyファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。
手順
root ユーザーとして
/etc/redis/redis.confファイルを開き、次のプロパティーを反映するように TLS/SSL オプションを調整します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow redisが TLS 証明書にアクセスできることを確認します。su redis -s /bin/bash -c \ 'ls -1 /etc/redis/ca.crt /etc/redis/redis.key /etc/redis/redis.crt' /etc/redis/ca.crt /etc/redis/redis.crt /etc/redis/redis.key
# su redis -s /bin/bash -c \ 'ls -1 /etc/redis/ca.crt /etc/redis/redis.key /etc/redis/redis.crt' /etc/redis/ca.crt /etc/redis/redis.crt /etc/redis/redis.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow redisサーバーを再起動して、設定の変更を適用します。systemctl restart redis
# systemctl restart redisCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TLS 設定が機能していることを確認します。
redis-cli --tls --cert /etc/redis/client.crt \ --key /etc/redis/client.key \ --cacert /etc/redis/ca.crt <<< "PING" PONG# redis-cli --tls --cert /etc/redis/client.crt \ --key /etc/redis/client.key \ --cacert /etc/redis/ca.crt <<< "PING" PONGCopy to Clipboard Copied! Toggle word wrap Toggle overflow TLS 設定が失敗すると、次のエラーメッセージが表示される場合があります。
Could not negotiate a TLS connection: Invalid CA Certificate File/Directory
Could not negotiate a TLS connection: Invalid CA Certificate File/DirectoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.7. PCP Redis データソースでのパネルおよびアラートの作成 リンクのコピーリンクがクリップボードにコピーされました!
PCP Redis データソースを追加した後に、ダッシュボードに有用なメトリックの概要を表示し、負荷グラフを視覚化するためのクエリーを追加して、システムに問題が発生した場合にその問題を表示する上で役立つアラートを作成できます。
前提条件
- PCP Redis が設定されている。詳細は、PCP Redis の設定 を参照してください。
- Grafana サーバーにアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
手順
- Grafana Web UI にログインします。
- Grafana Home ページで、Add your first data source をクリックします。
-
Add data source ペインで、Filter by name or type テキストボックスに
redisと入力し、PCP Redis をクリックします。 Data Sources / PCP Redis ペインで、以下を実行します。
-
URL フィールドに
http://localhost:44322を追加し、 をクリックします。 - → → をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。
オプション:クロックアイコン
の横にあるドロップダウンメニューで、絶対時間範囲を設定するか、事前定義範囲を選択して、表示されるメトリックのタイムラインを設定できます。ズームアウトアイコン
を使用して、表示される時間範囲を変更することもできます。
注記デフォルトで表示される時間枠は、
pmloggerサービスによって作成されたアーカイブファイルが対象とする時間枠と一致しない可能性があります。図10.2 PCP Redis: ホストの概要
-
URL フィールドに
新しいパネルを追加します。
-
プラス記号
ドロップダウンメニューから、New dashboard を選択します。
-
Add
ドロップダウンメニューから、Visualization を選択します。
- Query タブで、Data source として pcp-redis-datasource を選択します。
-
A の下のテキストフィールドに、カーネル負荷グラフを可視化するためのメトリクス (例:
kernel.all.load) を入力します。 - オプション: 右側の Time series ドロップダウンメニューから、Bar chart、Table、Heatmap など、別の視覚化形式を選択します。
- オプション: Panel title と Description を追加し、その他のオプションを更新します。
- をクリックして変更を適用し、ダッシュボードを保存します。Title を追加します。
をクリックして変更を適用し、ダッシュボードに戻ります。
図10.3 PCP Redis クエリーパネル
-
プラス記号
アラートルールを作成します。
-
PCP Redis query panel で Alert
をクリックしてから、New alert rule をクリックします。
- アラートルール名を入力します。
- クエリーとアラート条件を定義します。
- 評価動作を設定します。
- オプション: アノテーションを追加します。
- ラベルと通知を追加します。
- をクリックしてアラートルールの変更を適用します。
をクリックして変更を適用し、ダッシュボードに戻ります。
図10.4 PCP Redis パネルでのアラートの作成
作成したアラートルールに通知チャネルを追加して Grafana からアラート通知を受信するには、アラートの通知チャネルの追加 を参照してください。
-
PCP Redis query panel で Alert
10.8. アラートの通知チャネルの追加 リンクのコピーリンクがクリップボードにコピーされました!
通知チャネルを追加すると、アラートルールの条件が満たされ、システムのさらなる監視が必要になったときに、Grafana からアラート通知を受け取ることができます。
サポートされている通知のリストからいずれかのタイプを選択すると、このようなアラートを受信できます。サポートされている通知のリストには以下が含まれます。
- Alertmanager
- Cisco Webex Teams
- DingDing
- Discord
- Google Chat
- Kafka REST Proxy
- LINE
- Microsoft Teams
- OpsGenie
- PagerDuty
- Pushover
- Sensu Go
- Slack
- Telegram
- Threema Gateway
- VictorOps
- WeCom
- Webhook
前提条件
- Grafana サーバーにアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
- アラートルールが作成されている。詳細は、PCP Redis データソースでのパネルおよびアラートの作成 を参照してください。
手順
SMTP を設定し、
/etc/grafana/grafana.iniファイルに有効な送信者のメールアドレスを追加します。[smtp] enabled = true from_address = <sender_email_address>
[smtp] enabled = true from_address = <sender_email_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Grafana サーバーを再起動します。
systemctl restart grafana-server.service
# systemctl restart grafana-server.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow メニューから、 → → を選択します。
図10.5 Grafana のアラート
Create contact point ビューで、次の操作を実行します。
- Name テキストボックスに名前を入力します。
- Integration タイプ (Email など) を選択し、1 つまたは複数のメールアドレスを入力します。
- オプション: Optional Email settings および Notification settings を設定します。
- をクリックします。
アラートルールで通知チャネルを選択します。
- Alerting メニューから Notification policies を選択します。
-
Default policy の右端にある 3 つの点アイコン
をクリックし、Edit を選択します。
- 作成した Contact point を選択し、Update default policy をクリックします。
- オプション: デフォルトポリシーに加えて、ネストされたポリシーを設定します。
- オプション: Mute Timings を設定します。
10.9. PCP コンポーネント間の認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
Simple Authentication Security Layer (SASL) フレームワークを介して PCP によってサポートされる scram-sha-256 認証メカニズムを使用して認証を設定できます。
手順
scram-sha-256認証メカニズムのsaslフレームワークをインストールします。dnf install cyrus-sasl-scram cyrus-sasl-lib
# dnf install cyrus-sasl-scram cyrus-sasl-libCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmcd.confファイルに、サポートされている認証メカニズムとユーザーデータベースのパスを指定します。vi /etc/sasl2/pmcd.conf mech_list: scram-sha-256 sasldb_path: /etc/pcp/passwd.db
# vi /etc/sasl2/pmcd.conf mech_list: scram-sha-256 sasldb_path: /etc/pcp/passwd.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいユーザーを作成します。
useradd -r metrics
# useradd -r metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow metrics をユーザー名に置き換えます。
作成したユーザーをユーザーデータベースに追加します。
saslpasswd2 -a pmcd metrics Password: Again (for verification):
# saslpasswd2 -a pmcd metrics Password: Again (for verification):Copy to Clipboard Copied! Toggle word wrap Toggle overflow 作成したユーザーを追加するには、メトリック アカウントのパスワードを入力する必要があります。
ユーザーデータベースのパーミッションを設定します。
chown root:pcp /etc/pcp/passwd.db chmod 640 /etc/pcp/passwd.db
# chown root:pcp /etc/pcp/passwd.db # chmod 640 /etc/pcp/passwd.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmcdサービスを再起動します。systemctl restart pmcd
# systemctl restart pmcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
sasl設定を確認します。pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read Password: disk.dev.read inst [0 or "sda"] value 19540
# pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read Password: disk.dev.read inst [0 or "sda"] value 19540Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.10. PCP bpftrace のインストール リンクのコピーリンクがクリップボードにコピーされました!
PCP bpftrace エージェントをインストールして、システムをイントロスペクトし、カーネルおよびユーザー空間トレースポイントからメトリックを収集します。
bpftrace エージェントは bpftrace スクリプトを使用してメトリックを収集します。bpftrace スクリプトは、強化された Berkeley Packet Filter (eBPF) を使用します。
この手順では、pcp bpftrace をインストールする方法を説明します。
前提条件
- PCP が設定されている。詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
-
scram-sha-256認証メカニズムが設定されている。詳細は、PCP コンポーネント間の認証の設定 を参照してください。
手順
pcp-pmda-bpftraceパッケージをインストールします。dnf install pcp-pmda-bpftrace
# dnf install pcp-pmda-bpftraceCopy to Clipboard Copied! Toggle word wrap Toggle overflow bpftrace.confファイルを編集し、PCP コンポーネント間の認証の設定 で作成したユーザーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow metrics をユーザー名に置き換えます。
bpftracePMDA をインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pmda-bpftraceがインストールされたため、ユーザーの認証後にのみ使用できるようになりました。詳細は PCP bpftrace システム分析ダッシュボードの表示 を参照してください。
10.11. PCP bpftrace システム分析ダッシュボードの表示 リンクのコピーリンクがクリップボードにコピーされました!
PCP bpftrace データソースを使用すると、pmlogger またはアーカイブからの通常のデータとして利用できないソースからのライブデータにアクセスできます。
PCP bpftrace データソースでは、ダッシュボードに有用なメトリックの概要を表示できます。
前提条件
- PCP bpftrace がインストールされている。詳細は、PCP bpftrace のインストール を参照してください。
- Grafana サーバーにアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
手順
- Grafana Web UI にログインします。
- メニューで、 → → に移動します。
- Add data source ペインで、Filter by name or type テキストボックスに bpftrace と入力して、PCP bpftrace をクリックします。
Data Sources / pcp-bpftrace-datasource ペインで、次の操作を実行します。
-
URL フィールドに
http://localhost:44322を追加します。 - Basic Auth オプションを切り替えて、作成されたユーザーの認証情報を、User フィールドおよび Password フィールドに追加します。
をクリックします。
図10.6 データソースへの PCP bpftrace の追加
→ → をクリックし、有用なメトリックの概要を含むダッシュボードを表示します。
図10.7 PCP bpftrace: システム分析
-
URL フィールドに
10.12. PCP Vector のインストール リンクのコピーリンクがクリップボードにコピーされました!
リアルタイムの pmwebapi インターフェイスからホスト上のライブのメトリクスを表示するには、pcp vector データソースをインストールします。このデータソースは、個々のホストのオンデマンドパフォーマンス監視を目的としており、コンテナーをサポートしています。
前提条件
- PCP が設定されている。詳細は、pcp-zeroconf を使用した PCP の設定 を参照してください。
- Grafana サーバーが設定されている。詳細は、Grafana サーバーの設定 を参照してください。
手順
pcp-pmda-bccパッケージをインストールします。dnf install pcp-pmda-bcc
# dnf install pcp-pmda-bccCopy to Clipboard Copied! Toggle word wrap Toggle overflow bccPMDA をインストールします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.13. PCP Vector Checklist の表示 リンクのコピーリンクがクリップボードにコピーされました!
PCP Vector データソースはライブメトリックを表示し、pcp メトリックを使用します。各ホストのデータを分析します。
PCP Vector データソースを追加した後に、ダッシュボードに有用なメトリックの概要を表示し、チェックリストで関連するトラブルシューティングまたは参照リンクを表示できます。
前提条件
- PCP Vector がインストールされている。詳細は、PCP Vector のインストール を参照してください。
- Grafana サーバーにアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
手順
- Grafana Web UI にログインします。
- メニューで、 → → に移動します。
- Add data source ペインで、Filter by name or type テキストボックスに vector と入力してから PCP Vector をクリックします。
Data Sources / pcp-vector-datasource ペインで、次の操作を実行します。
-
URL フィールドに
http://localhost:44322を追加し、 をクリックします。 → → をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。
図10.8 PCP Vector: ホストの概要
-
URL フィールドに
メニューで、 → → に移動します。
PCP チェックで疑問符アイコン
をクリックしてヘルプするか、警告アイコン
をクリックして、関連するトラブルシューティングまたは参照リンクを表示します。
図10.9 Performance Co-Pilot / PCP Vector チェックリスト
10.14. Grafana のヒートマップの使用 リンクのコピーリンクがクリップボードにコピーされました!
Grafana のヒートマップを使用すると、経時的なデータのヒストグラムを表示し、データの傾向とパターンを特定し、時間の経過に伴う変化を確認できます。ヒートマップ内の各列は単一のヒストグラムを表します。それぞれのセルの色は、そのヒストグラム内における特定の値の観測密度を表します。
このワークフローは、RHEL9 の Grafana バージョン 10 以降のヒートマップ用です。
前提条件
- PCP Redis が設定されている。詳細は、PCP Redis の設定 を参照してください。
- Grafana サーバーにアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
- PCP Redis データソースが設定されている。詳細は、PCP Redis データソースでのパネルおよびアラートの作成 を参照してください。
手順
- メニューで、 → → を選択します。
- Select data source ペインで、pcp-redis-datasource を選択します。
-
Query タブの A の下のテキストフィールドに、カーネル負荷グラフを可視化するためのメトリクス (例:
kernel.all.load) を入力します。 - 右側の Time series ドロップダウンメニューから、Heatmap を選択します。
- オプション: Panel Options ドロップダウンメニューで、Panel Title と Description を追加します。
Heatmap ドロップダウンメニューの Calculate from data 設定で、Yes をクリックします。
ヒートマップ
- オプション: Colors ドロップダウンメニューで、Scheme をデフォルトの Orange から変更し、ステップ数 (色の濃淡) を選択します。
オプション: Tooltip ドロップダウンメニューで、トグルをクリックすると、ヒートマップ内のセルの上にカーソルを置いたときに、そのヒストグラム内におけるセルの位置が表示されます。以下に例を示します。
Show histogram (Y Axis) のセルの表示
10.15. Grafana に関する問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Grafana にデータが表示されない、ダッシュボードが黒くなる、または同様の問題など、Grafana の問題のトラブルシューティングが必要になる場合があります。
手順
以下のコマンドを実行して、
pmloggerサービスが起動していることを確認します。systemctl status pmlogger
$ systemctl status pmloggerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、ディスクにファイルが作成または変更されているかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
pmproxyサービスが動作していることを確認します。systemctl status pmproxy
$ systemctl status pmproxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow pmproxyが動作していること、時系列サポートが有効になっていること、Redis への接続が確立されていることを、/var/log/pcp/pmproxy/pmproxy.logファイルを見て、以下のテキストが含まれていることで確認してください。pmproxy(1716) Info: Redis slots, command keys, schema version setup
pmproxy(1716) Info: Redis slots, command keys, schema version setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、1716は pmproxy の PID であり、
pmproxyを起動するたびに異なる値になります。以下のコマンドを実行して、Redis データベースにキーが含まれているかどうかを確認します。
redis-cli dbsize (integer) 34837
$ redis-cli dbsize (integer) 34837Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、PCP メトリックが Redis データベースに存在し、
pmproxyがアクセスできるかどうかを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、Grafana のログにエラーがあるかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第11章 Web コンソールを使用したシステムパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
以下では、RHEL Web コンソールでパフォーマンスプロファイルを設定し、選択したタスクに対してシステムのパフォーマンスを最適化する方法を説明します。
11.1. Web コンソールでのパフォーマンスチューニングオプション リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 9 には、以下のタスクに対してシステムを最適化する複数のパフォーマンスプロファイルが同梱されています。
- デスクトップを使用するシステム
- スループットパフォーマンス
- レイテンシーパフォーマンス
- ネットワークパフォーマンス
- 電力の低消費
- 仮想マシン
TuneD サービスは、選択したプロファイルに一致するようにシステムオプションを最適化します。
Web コンソールでは、システムが使用するパフォーマンスプロファイルを設定できます。
11.2. Web コンソールでのパフォーマンスプロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
実行するタスクに応じて、Web コンソールを使用して適切なパフォーマンスプロファイルを設定することでシステムパフォーマンスを最適化できます。
前提条件
- RHEL 9 Web コンソールがインストールされている。
- cockpit サービスが有効になっている。
ユーザーアカウントが Web コンソールにログインできる。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
RHEL 9 Web コンソールにログインします。
詳細は、Web コンソールへのログイン を参照してください。
- Overview をクリックします。
Configuration セクションで、現在のパフォーマンスプロファイルをクリックします。
Change Performance Profile ダイアログボックスで、必要なプロファイルを設定します。
- をクリックします。
検証
- Overview タブの Configuration セクションに、選択したパフォーマンスプロファイルが表示されます。
11.3. Web コンソールを使用したローカルシステムのパフォーマンスの監視 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux の Web コンソールは、トラブルシューティングに Utilization Saturation and Errors (USE) メソッドを使用します。新しいパフォーマンスメトリックページには、データの履歴ビューが時系列に整理されており、最新のデータが上部に表示されます。
Metrics and history ページでは、イベント、エラー、リソースの使用率と飽和状態のグラフィカル表示を表示できます。
前提条件
- RHEL 9 Web コンソールがインストールされている。
- cockpit サービスが有効になっている。
ユーザーアカウントが Web コンソールにログインできる。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
パフォーマンスメトリクスの収集を可能にする
cockpit-pcpパッケージがインストールされている。 Performance Co-Pilot (PCP) サービスが有効になっている。
systemctl enable --now pmlogger.service pmproxy.service
# systemctl enable --now pmlogger.service pmproxy.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
RHEL 9 Web コンソールにログインします。
詳細は、Web コンソールへのログイン を参照してください。
- Overview をクリックします。
Usage セクションで、View metrics and history をクリックします。
Metrics and history セクションが開きます。
-
現在のシステム設定と使用状況:
-
ユーザー指定の時間間隔におけるグラフィック形式のパフォーマンスメトリクス:
-
現在のシステム設定と使用状況:
11.4. Web コンソールと Grafana を使用して複数のシステムのパフォーマンスを監視する リンクのコピーリンクがクリップボードにコピーされました!
Grafana を使用すると、一度に複数のシステムからデータを収集し、収集した Performance Co-Pilot (PCP) メトリックのグラフィカル表現を確認できます。Web コンソールインターフェイスで、複数のシステムのパフォーマンスメトリックの監視およびエクスポートを設定できます。
前提条件
- RHEL 9 Web コンソールがインストールされている。
- cockpit サービスが有効になっている。
ユーザーアカウントが Web コンソールにログインできる。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
cockpit-pcpパッケージがインストールされている。 PCP サービスが有効になっている。
systemctl enable --now pmlogger.service pmproxy.service
# systemctl enable --now pmlogger.service pmproxy.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Grafana ダッシュボードが設定されている。詳細は、grafana-server の設定 を参照してください。
redisパッケージがインストールされている。または、手順の後半で Web コンソールインターフェイスからパッケージをインストールすることもできます。
手順
RHEL 9 Web コンソールにログインします。
詳細は、Web コンソールへのログイン を参照してください。
- Overview ページで、Usage テーブルの View metrics and history をクリックします。
- ボタンをクリックします。
Export to network スライダーをアクティブな位置に移動します。
redisパッケージがインストールされていない場合は、Web コンソールでインストールするように求められます。-
pmproxyサービスを開くには、ドロップダウンリストからゾーンを選択し、 ボタンをクリックします。 - Save をクリックします。
検証
- Networking をクリックします。
- Firewall テーブルで、 ボタンをクリックします。
-
選択したゾーンで
pmproxyを検索します。
監視するすべてのシステムでこの手順を繰り返します。
第12章 ディスクスケジューラーの設定 リンクのコピーリンクがクリップボードにコピーされました!
ディスクスケジューラーは、ストレージデバイスに送信された I/O 要求を順序付けます。
スケジューラーは以下の複数の方法で設定できます。
- Setting the disk scheduler using TuneD の説明に従って、TuneD を使用してスケジューラーを設定します。
-
udev ルールを使用したディスクスケジューラーの設定 で説明されているように、
udevを使用してスケジューラーを設定します。 - 特定ディスクに任意のスケジューラーを一時的に設定 で説明されているように、実行中のシステムのスケジューラーを一時的に変更します。
Red Hat Enterprise Linux 9 では、ブロックデバイスはマルチキュースケジューリングのみに対応します。これにより、ブロックレイヤーのパフォーマンスを高速ソリッドステートドライブ (SSD) およびマルチコアシステムで適切に拡張できます。
Red Hat Enterprise Linux 7 以前のバージョンで利用できた従来のシングルキュースケジューラーが削除されました。
12.1. 利用可能なディスクスケジューラー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 9 では、以下のマルチキューディスクスケジューラーに対応しています。
none- FIFO (First-in First-out) スケジューリングアルゴリズムを実装します。これにより、汎用のブロック層で単純な last-hit キャッシュを介して要求がマージされます。
mq-deadlineこれにより、要求がスケジューラーに到達した時点からの要求のレイテンシーが保証されます。
mq-deadlineスケジューラーは、キュー待ちの I/O リクエストを読み取りバッチまたは書き込みバッチに分類します。そして、論理ブロックアドレス (LBA) を増大順に実行するためのスケジュール設定を行います。デフォルトでは、アプリケーションは読み取り I/O 操作でブロックする可能性の方が高いため、読み取りバッチの方が書き込みバッチより優先されます。mq-deadlineがバッチを処理すると、このプロセスは書き込み動作が待機している長さを確認して、次の読み取りバッチまたは書き込みバッチをスケジュールします。このスケジューラーはほとんどのユースケースに適していますが、必要に応じて特に書き込み動作より読み取り動作の方が頻繁に起こるユースケースに適しています。
bfqデスクトップシステムおよび対話式のタスクを対象とします。
bfqスケジューラーは、単一のアプリケーションがすべての帯域幅を使用しないようにします。これにより、ストレージデバイスがアイドル状態であるかのように常に応答できるようになります。デフォルトの設定では、bfqは、最大スループットを実現するのではなく、レイテンシーを最小限に抑えることに焦点を合わせています。bfqはcfqコードに基づいています。一定のタイムスライスごとにディスクを各プロセスに付与するのではなく、セクター数単位で測定された バジェット をプロセスに割り当てます。このスケジューラーは大きなファイルをコピーする際に適しており、この場合、システムが応答しなくなることはありません。
kyberスケジューラーは、ブロック I/O レイヤーに送信されたすべての I/O 要求のレイテンシーを計算することで、レイテンシーゴールを達成するために自身を調整します。cache-misses の場合、読み込み/同期書き込みリクエストにターゲットレイテンシーを設定できます。
このスケジューラーは、NVMe、SSD などの低レイテンシーデバイスなど、高速なデバイスに適しています。
12.2. 各種ユースケースで異なるディスクスケジューラー リンクのコピーリンクがクリップボードにコピーされました!
システムが実行するタスクに応じて、分析タスクおよびチューニングタスクの前に、以下のディスクスケジューラーがベースラインとして推奨されます。
| ユースケース | ディスクスケジューラー |
|---|---|
| SCSI インターフェイスを備えた従来の HDD |
|
| 高速ストレージで高パフォーマンスの SSD または CPU がバインドされたシステム |
特にエンタープライズアプリケーションを実行する場合は |
| デスクトップまたはインタラクティブなタスク |
|
| 仮想ゲスト |
|
12.3. デフォルトのディスクスケジューラー リンクのコピーリンクがクリップボードにコピーされました!
ブロックデバイスは、別のスケジューラーを指定しない限り、デフォルトのディスクスケジューラーを使用します。
NVMe (Non-volatile Memory Express) ブロックデバイスの場合、デフォルトのスケジューラーは none であり、Red Hat ではこれを変更しないことを推奨します。
カーネルは、デバイスのタイプに基づいてデフォルトのディスクスケジューラーを選択します。自動的に選択されたスケジューラーは、通常、最適な設定です。別のスケジューラーが必要な場合は、Red Hat では、udev ルールまたは TuneD アプリケーションを使用して設定することを推奨しています。選択したデバイスを一致させ、それらのデバイスのスケジューラーのみを切り替えます。
12.4. アクティブなディスクスケジューラーの決定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、特定のブロックデバイスで現在アクティブなディスクスケジューラーを確認します。
手順
/sys/block/device/queue/schedulerファイルの内容を読み取ります。cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq none
# cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル名の device を、
sdcなどのブロックデバイス名に置き換えます。アクティブなスケジューラーは、角括弧 (
[ ]) にリスト表示されます。
12.5. TuneD を使用したディスクスケジューラーの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、選択したブロックデバイスに特定のディスクスケジューラーを設定するTuneD プロファイルを作成して有効にします。この設定は、システムを再起動しても持続します。
以下のコマンドと設定で、以下の内容を置き換えます。
-
device をブロックデバイスの名前に置き換えます (例:
sdf)。 -
selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例:
bfq)。
前提条件
-
TuneDサービスがインストールされ、有効になっている。詳細は、TuneD のインストールと有効化 を参照してください。
手順
必要に応じて、プロファイルのベースとなる既存のTuneDプロファイルを選択します。利用可能なプロファイルのリストは、RHEL とともに配布される TuneD プロファイル を参照してください。
現在アクティブなプロファイルを確認するには、次のコマンドを実行します。
tuned-adm active
$ tuned-adm activeCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD プロファイルを保持する新しいディレクトリーを作成します。
mkdir /etc/tuned/my-profile
# mkdir /etc/tuned/my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 選択したブロックデバイスのシステム固有の識別子を見つけます。
udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)' ID_WWN=0x5002538d00000000_ ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 ID_SERIAL_SHORT=20120501030900000
$ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)' ID_WWN=0x5002538d00000000_ ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 ID_SERIAL_SHORT=20120501030900000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。
/etc/tuned/my-profile/tuned.conf設定ファイルを作成します。このファイルで、以下のオプションを設定します。必要に応じて、既存のプロファイルを追加します。
[main] include=existing-profile
[main] include=existing-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow WWN 識別子に一致するデバイスに対して選択したディスクスケジューラーを設定します。
[disk] devices_udev_regex=IDNAME=device system unique id elevator=selected-scheduler
[disk] devices_udev_regex=IDNAME=device system unique id elevator=selected-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
IDNAME を、使用されている識別子名に置き換えます (例:
ID_WWN)。 device system unique id を、選択した識別子の値に置き換えます (例:
0x5002538d00000000)。devices_udev_regexオプションで複数のデバイスに一致させるには、識別子を括弧で囲み、垂直バーで区切ります。devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
IDNAME を、使用されている識別子名に置き換えます (例:
プロファイルを有効にします。
tuned-adm profile my-profile
# tuned-adm profile my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TuneD プロファイルがアクティブで、適用されていることを確認します。
tuned-adm active Current active profile: my-profile
$ tuned-adm active Current active profile: my-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.$ tuned-adm verify Verification succeeded, current system settings match the preset profile. See TuneD log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/block/device/queue/schedulerファイルの内容を読み取ります。cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq none
# cat /sys/block/device/queue/scheduler [mq-deadline] kyber bfq noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル名の device を、
sdcなどのブロックデバイス名に置き換えます。アクティブなスケジューラーは、角括弧 (
[]) にリスト表示されます。
12.6. udev ルールを使用したディスクスケジューラーの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、udev ルールを使用して、特定ブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動しても持続します。
以下のコマンドと設定で、以下の内容を置き換えます。
-
device をブロックデバイスの名前に置き換えます (例:
sdf)。 -
selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例:
bfq)。
手順
ブロックデバイスのシステム固有の識別子を見つけます。
udevadm info --name=/dev/device | grep -E '(WWN|SERIAL)' E: ID_WWN=0x5002538d00000000 E: ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 E: ID_SERIAL_SHORT=20120501030900000
$ udevadm info --name=/dev/device | grep -E '(WWN|SERIAL)' E: ID_WWN=0x5002538d00000000 E: ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0 E: ID_SERIAL_SHORT=20120501030900000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。
udevルールを設定します。以下の内容で/etc/udev/rules.d/99-scheduler.rulesファイルを作成します。ACTION=="add|change", SUBSYSTEM=="block", ENV{IDNAME}=="device system unique id", ATTR{queue/scheduler}="selected-scheduler"ACTION=="add|change", SUBSYSTEM=="block", ENV{IDNAME}=="device system unique id", ATTR{queue/scheduler}="selected-scheduler"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
IDNAME を、使用されている識別子名に置き換えます (例:
ID_WWN)。 -
device system unique id を、選択した識別子の値に置き換えます (例:
0x5002538d00000000)。
-
IDNAME を、使用されている識別子名に置き換えます (例:
udevルールを再読み込みします。udevadm control --reload-rules
# udevadm control --reload-rulesCopy to Clipboard Copied! Toggle word wrap Toggle overflow スケジューラー設定を適用します。
udevadm trigger --type=devices --action=change
# udevadm trigger --type=devices --action=changeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
アクティブなスケジューラーを確認します。
cat /sys/block/device/queue/scheduler
# cat /sys/block/device/queue/schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.7. 特定ディスクに任意のスケジューラーを一時的に設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、特定のブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動すると元に戻ります。
手順
選択したスケジューラーの名前を、
/sys/block/device/queue/schedulerファイルに書き込みます。echo selected-scheduler > /sys/block/device/queue/scheduler
# echo selected-scheduler > /sys/block/device/queue/schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイル名の device を、
sdcなどのブロックデバイス名に置き換えます。
検証
スケジューラーがデバイスでアクティブになっていることを確認します。
cat /sys/block/device/queue/scheduler
# cat /sys/block/device/queue/schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 Samba サーバーのパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
特定の状況で Samba のパフォーマンスを向上させることができる設定と、パフォーマンスに悪影響を与える可能性がある設定を説明します。
このセクションの一部は、Samba Wiki に公開されているドキュメント Performance Tuning に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
前提条件
- Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。
13.1. SMB プロトコルバージョンの設定 リンクのコピーリンクがクリップボードにコピーされました!
新しい SMB バージョンごとに機能が追加され、プロトコルのパフォーマンスが向上します。最新の Windows および Windows Server オペレーティングシステムは、常に最新のプロトコルバージョンに対応しています。Samba がプロトコルの最新バージョンも使用している場合は、Samba に接続する Windows クライアントで、このパフォーマンス改善を活用できます。Samba では、server max protocol のデフォルト値が、対応している安定した SMB プロトコルの最新バージョンに設定されます。
常に最新の安定した SMB プロトコルバージョンを有効にするには、server max protocol パラメーターを設定しないでください。このパラメーターを手動で設定する場合は、最新のプロトコルバージョンを有効にするために、それぞれ新しいバージョンの SMB プロトコルで設定を変更する必要があります。
次の手順では、server max protocol パラメーターでデフォルト値を使用する方法を説明します。
手順
-
/etc/samba/smb.confファイルの[global]セクションから、server max protocolパラメーターを削除します。 Samba 設定を再読み込みします。
smbcontrol all reload-config
# smbcontrol all reload-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3. パフォーマンスが低下する可能性のある設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスが高くなるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf ファイルに socket options パラメーターを設定すると、このカーネル設定が上書きされます。その結果、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。
カーネルの最適化された設定を使用するには、/etc/samba/smb.conf の [global] セクションから socket options パラメーターを削除します。
第14章 仮想マシンのパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンでは、ホストと比べて、パフォーマンス低下が常に見られます。以下のセクションでは、この低下の理由を説明します。また、ハードウェアのインフラストラクチャーリソースを可能な限り効率的に使用できるように、RHEL 9 での仮想化によるパフォーマンスへの影響を最小限に抑える方法を説明します。
14.1. 仮想マシンのパフォーマンスに影響を及ぼすもの リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンは、ホストのユーザー空間プロセスとして実行します。したがって、ハイパーバイザーは、仮想マシンがホストシステムのリソースを使用できるように、ホストのシステムリソースを変換する必要があります。したがって、変換によりリソースの一部が消費されるため、仮想マシンのパフォーマンス効率は、ホストと同じにはなりません。
システムパフォーマンスにおける仮想化の影響
仮想マシンのパフォーマンス低下の理由には、以下のようなものがあります。
- 仮想 CPU (vCPU) がホスト上のスレッドとして実装され、Linux スケジューラーで処理される。
- 仮想マシンは、ホストカーネルから NUMA や Huge Page などの最適化機能を自動的に継承しない。
- ホストのディスクおよびネットワーク I/O の設定が、仮想マシンのパフォーマンスに大きく影響する可能性がある。
- ネットワークトラフィックは、一般的に、ソフトウェアベースのブリッジから仮想マシンに流れる。
- ホストデバイスとそのモデルによっては、その特定のハードウェアのエミュレーションにより、オーバーヘッドが著しくなる可能性がある。
仮想化が仮想マシンのパフォーマンスに与える影響の重大度は、次のようなさまざまな要因の影響を受けます。
- 同時に実行している仮想マシンの数
- 各仮想マシンで使用される仮想デバイスのサイズ
- 仮想マシンが使用するデバイスの種類
仮想マシンのパフォーマンス損失を減らす
RHEL 9 は、仮想化のパフォーマンスへの悪影響を減らすのに使用できる多くの機能を提供します。以下に例を示します。
-
TuneDサービス により、仮想マシンのリソース配分とパフォーマンスを自動的に最適化できます。 - ブロック I/O チューニング により、ディスクなどの仮想マシンのブロックデバイスのパフォーマンスを改善できます。
- NUMA のチューニング により、vCPU のパフォーマンスを向上できます。
- 仮想ネットワーク をさまざまな方法で最適化できます。
仮想マシンのパフォーマンスのチューニングは、その他の仮想化機能に悪影響を与える可能性があります。たとえば、変更した仮想マシンの移行がより困難になります。
14.2. TuneD を使用した仮想マシンのパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
TuneD ユーティリティーは、CPU 集中型タスクや、ストレージネットワークスループットの応答などの特定のワークロードの特性に対して RHEL を調整するプロファイル配信メカニズムです。これにより、特定のユースケースで、パフォーマンスを強化し、電力消費を減らすように事前設定されたチューニングプロファイルを多数利用できます。これらのプロファイルを編集するか、新規プロファイルを作成して、仮想化環境に適したパフォーマンスソリューション (仮想化環境を含む) を作成できます。
RHEL 9 を仮想化に最適化するには、次のプロファイルを使用します。
-
RHEL 9 仮想マシンの場合は、virtual-guest プロファイルを使用します。これは、一般的に適用された
throughput-performanceプロファイルをベースにしていますが、仮想メモリーのスワップは減少します。 - RHEL 9 仮想ホストの場合は、virtual-host プロファイルを使用します。これにより、ダーティーメモリーページのより集中的なライトバックが有効になり、ホストのパフォーマンスを活用できます。
前提条件
-
TuneDサービスがインストールされており、有効になっている。
手順
特定の TuneD プロファイルを有効にするには、以下を実行します。
利用可能な
TuneDプロファイルをリスト表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 新しい
TuneDプロファイルを作成するか、既存のTuneDプロファイルを編集します。詳細は、TuneD プロファイルのカスタマイズ を参照してください。
TuneDプロファイルをアクティベートします。tuned-adm profile selected-profile
# tuned-adm profile selected-profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想化ホストを最適化するには、virtual-host プロファイルを使用します。
tuned-adm profile virtual-host
# tuned-adm profile virtual-hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow RHEL ゲストオペレーティングシステムで、virtual-guest プロファイルを使用します。
tuned-adm profile virtual-guest
# tuned-adm profile virtual-guestCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
TuneDのアクティブなプロファイルを表示します。tuned-adm active Current active profile: virtual-host
# tuned-adm active Current active profile: virtual-hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneDプロファイル設定がシステムに適用されていることを確認します。tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.# tuned-adm verify Verification succeeded, current system settings match the preset profile. See tuned log file ('/var/log/tuned/tuned.log') for details.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3. 特定のワークロードに合わせた仮想マシンのパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) は、多くの場合、特定のワークロードを実行するために専用に使用されます。目的のワークロードに合わせて仮想マシンの設定を最適化することで、仮想マシンのパフォーマンスを向上させることができます。
| ユースケース | IOThread | 仮想 CPU ピニング | vNUMA ピニング | huge page | multi-queue |
|---|---|---|---|---|---|
| データベース | データベースディスク用 | はい* | はい* | はい* | はい (multi-queue virtio-blk、virtio-scsi を参照) |
| 仮想ネットワーク機能 (VNF) | なし | はい | はい | はい | はい (multi-queue virtio-net を参照) |
| ハイパフォーマンスコンピューティング (HPC) | なし | はい | はい | はい | なし |
| バックアップサーバー | バックアップディスク用 | なし | なし | なし | はい (multi-queue virtio-blk、virtio-scsi を参照) |
| 多数の CPU を搭載した仮想マシン (通常 32 個以上) | なし | はい* | はい* | なし | なし |
| 大容量 RAM を搭載した仮想マシン (通常 128 GB 以上) | なし | なし | はい* | はい | なし |
* 仮想マシンに複数の NUMA ノードを使用するのに十分な CPU と RAM がある場合。
仮想マシンは、複数のカテゴリーのユースケースに適合できます。そのような状況では、推奨される設定をすべて適用する必要があります。
14.4. libvirt デーモンの最適化 リンクのコピーリンクがクリップボードにコピーされました!
libvirt 仮想化スイートは、RHEL ハイパーバイザーの管理層として機能し、libvirt の設定は仮想化ホストに大きな影響を与えます。特に、RHEL 9 には、モノリシックまたはモジュラーの 2 つのタイプの libvirt デーモンが含まれており、使用するデーモンのタイプは、個々の仮想化ドライバーをどの程度細かく設定できるかに影響します。
14.4.1. libvirt デーモンのタイプ リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 は、以下の libvirt デーモンタイプをサポートします。
- モノリシックな libvirt
従来の
libvirtデーモンであるlibvirtdは、単一の設定ファイル/etc/libvirt/libvirtd.confを使用して、さまざまな仮想化ドライバーを制御します。このため、
libvirtdは一元化されたハイパーバイザー設定を可能にしますが、システムリソースの使用が非効率的となる可能性があります。したがって、libvirtdは、RHEL の今後のメジャーリリースではサポートされなくなる予定です。ただし、RHEL 8 から RHEL 9 に更新した場合、ホストはデフォルトで引き続き
libvirtdを使用します。- モジュラー libvirt
RHEL 9 で新たに導入されたモジュラー
libvirtは、仮想化ドライバーごとに特定のデーモンを提供します。これらには以下が含まれます。- virtqemud - ハイパーバイザー管理用のプライマリーデーモン
- virtinterfaced - ホストの NIC 管理用のセカンダリーデーモン
- virtnetworkd - 仮想ネットワーク管理用のセカンダリーデーモン
- virtnodedevd - ホストの物理デバイス管理用のセカンダリーデーモン
- virtnwfilterd - ホストのファイアウォール管理用のセカンダリーデーモン
- virtsecretd - ホストシークレット管理用のセカンダリーデーモン
- virtstoraged - ストレージ管理用のセカンダリーデーモン
デーモンごとに個別の設定ファイル (
/etc/libvirt/virtqemud.confなど) があります。したがって、モジュラーのlibvirtデーモンは、libvirtリソース管理を細かく調整するためのより良いオプションを提供します。RHEL 9 を新規インストールした場合、モジュラー
libvirtはデフォルトで設定されています。
次のステップ
-
RHEL 9 で
libvirtdを使用する場合、Red Hat は、モジュール式デーモンへの切り替えを推奨しています。手順は、モジュラー libvirt デーモンの有効化 を参照してください。
14.4.2. モジュラー libvirt デーモンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 では、libvirt ライブラリーは、ホスト上の個々の仮想化ドライバーセットを処理するモジュラーデーモンを使用します。たとえば、virtqemud デーモンは QEMU ドライバーを処理します。
RHEL 9 ホストの新規インストールを実行すると、ハイパーバイザーはデフォルトでモジュラー libvirt デーモンを使用します。ただし、ホストを RHEL 8 から RHEL 9 にアップグレードした場合、ハイパーバイザーは RHEL 8 のデフォルトであるモノリシックな libvirtd デーモンを使用します。
その場合、Red Hat は、代わりにモジュラー libvirt デーモンを有効にすることを推奨します。これは、libvirt リソース管理を微調整するためのより良いオプションを提供するためです。また、RHEL の今後のメジャーリリースでは libvirtd はサポートされなくなる予定です。
前提条件
ハイパーバイザーがモノリシックな
libvirtdサービスを使用している。systemctl is-active libvirtd.service active
# systemctl is-active libvirtd.service activeCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドで
activeが表示される場合、libvirtdを使用していることになります。- 仮想マシンがシャットダウンしている。
手順
libvirtdとそのソケットを停止します。systemctl stop libvirtd.service systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket$ systemctl stop libvirtd.service $ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socketCopy to Clipboard Copied! Toggle word wrap Toggle overflow libvirtdを無効にして、システムの起動時に開始されないようにします。systemctl disable libvirtd.service systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket$ systemctl disable libvirtd.service $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socketCopy to Clipboard Copied! Toggle word wrap Toggle overflow モジュラーの
libvirtデーモンを有効にします。for drv in qemu interface network nodedev nwfilter secret storage; do systemctl unmask virt${drv}d.service; systemctl unmask virt${drv}d{,-ro,-admin}.socket; systemctl enable virt${drv}d.service; systemctl enable virt${drv}d{,-ro,-admin}.socket; done# for drv in qemu interface network nodedev nwfilter secret storage; do systemctl unmask virt${drv}d.service; systemctl unmask virt${drv}d{,-ro,-admin}.socket; systemctl enable virt${drv}d.service; systemctl enable virt${drv}d{,-ro,-admin}.socket; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow モジュラーデーモンのソケットを起動します。
for drv in qemu network nodedev nwfilter secret storage; do systemctl start virt${drv}d{,-ro,-admin}.socket; done# for drv in qemu network nodedev nwfilter secret storage; do systemctl start virt${drv}d{,-ro,-admin}.socket; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: リモートホストからホストに接続する必要がある場合は、仮想化プロキシーデーモンを有効にして起動します。
システムで
libvirtd-tls.socketサービスが有効になっているかどうかを確認します。grep listen_tls /etc/libvirt/libvirtd.conf listen_tls = 0
# grep listen_tls /etc/libvirt/libvirtd.conf listen_tls = 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow libvirtd-tls.socketが有効になっていない場合 (listen_tls = 0)、次のようにvirtproxydをアクティブにします。systemctl unmask virtproxyd.service systemctl unmask virtproxyd{,-ro,-admin}.socket systemctl enable virtproxyd.service systemctl enable virtproxyd{,-ro,-admin}.socket systemctl start virtproxyd{,-ro,-admin}.socket# systemctl unmask virtproxyd.service # systemctl unmask virtproxyd{,-ro,-admin}.socket # systemctl enable virtproxyd.service # systemctl enable virtproxyd{,-ro,-admin}.socket # systemctl start virtproxyd{,-ro,-admin}.socketCopy to Clipboard Copied! Toggle word wrap Toggle overflow libvirtd-tls.socketが有効になっている場合 (listen_tls = 1)、次のようにvirtproxydをアクティブにします。systemctl unmask virtproxyd.service systemctl unmask virtproxyd{,-ro,-admin,-tls}.socket systemctl enable virtproxyd.service systemctl enable virtproxyd{,-ro,-admin,-tls}.socket systemctl start virtproxyd{,-ro,-admin,-tls}.socket# systemctl unmask virtproxyd.service # systemctl unmask virtproxyd{,-ro,-admin,-tls}.socket # systemctl enable virtproxyd.service # systemctl enable virtproxyd{,-ro,-admin,-tls}.socket # systemctl start virtproxyd{,-ro,-admin,-tls}.socketCopy to Clipboard Copied! Toggle word wrap Toggle overflow virtproxydの TLS ソケットを有効にするには、libvirtで使用できるように設定された TLS 証明書がホストに必要です。詳細は、アップストリームの libvirt ドキュメント を参照してください。
検証
有効化された仮想化デーモンをアクティブにします。
virsh uri qemu:///system
# virsh uri qemu:///systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが
virtqemudモジュラーデーモンを使用していることを確認します。systemctl is-active virtqemud.service active
# systemctl is-active virtqemud.service activeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ステータスが
activeの場合、libvirtモジュラーデーモンは正常に有効になっています。
14.5. 仮想マシンのメモリーの設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのパフォーマンスを改善するために、追加のホスト RAM を仮想マシンに割り当てることができます。同様に、仮想マシンに割り当てるメモリー量を減らして、ホストメモリーを他の仮想マシンやタスクに割り当てることができます。
14.5.1. メモリーのオーバーコミットメント リンクのコピーリンクがクリップボードにコピーされました!
KVM ハイパーバイザー上で実行される仮想マシン (VM) には、専用の物理 RAM ブロックが割り当てられません。代わりに、各仮想マシンが Linux プロセスとして機能し、要求された場合にのみホストの Linux カーネルがメモリーを割り当てます。また、ホストのメモリーマネージャーが、仮想マシンのメモリーを独自の物理メモリーとスワップ領域間で移動できます。メモリーオーバーコミットが有効な場合、仮想マシンによって要求された量よりも少ない物理メモリーを割り当てることをカーネルが決定できます。これは、要求されたメモリー量が仮想マシンのプロセスによって完全に使用されないことが多いためです。
デフォルトでは、Linux カーネルでメモリーオーバーコミットが有効になっており、カーネルは仮想マシンの要求に対して安全なメモリーオーバーコミット量を推定します。ただし、メモリーを大量に消費するワークロードでは、オーバーコミットが頻繁に発生するため、システムが不安定になる可能性があります。
メモリーのオーバーコミットを行うには、すべての仮想マシンを収容するためにホスト物理マシンに十分なスワップ領域を割り当てるとともに、ホスト物理マシンのプロセスに十分なメモリーを割り当てる必要があります。推奨される基本的なスワップ領域のサイズについては、What is the recommended swap size for Red Hat platforms? を参照してください。
ホストのメモリー不足に対処するには、次の方法を推奨します。
- 仮想マシンごとに割り当てるメモリーを減らします。
- ホストに物理メモリーを追加します。
- より大きなスワップ領域を使用します。
仮想マシンは頻繁にスワップされると実行速度が低下します。また、オーバーコミットによりシステムのメモリーが不足 (OOM) する可能性があります。これにより、Linux カーネルが重要なシステムプロセスをシャットダウンする可能性があります。
メモリーのオーバーコミットは、デバイスの割り当てでは対応していません。これは、デバイスの割り当てが使用中の場合に、割り当てられたデバイスでダイレクトメモリーアクセス (DMA) を有効にするには、仮想マシンのすべてのメモリーを静的に事前に割り当てる必要があるためです。
14.5.2. Web コンソールを使用した仮想マシンのメモリーの追加および削除 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのパフォーマンスを向上させるか、仮想マシンが使用するホストリソースを解放するために、Web コンソールを使用して、仮想マシンに割り当てられたメモリーの量を調整できます。
IBM Z システムの仮想マシンに割り当てるメモリー量を調整するには、memballoon デバイスのみを使用します。その他のすべてのシステムでは、仮想マシンのメモリーを追加および削除するための推奨されるソリューションは、virtio-mem デバイスを使用することです。
前提条件
- RHEL 9 Web コンソールがインストールされている。
- cockpit サービスが有効になっている。
ユーザーアカウントが Web コンソールにログインできる。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。
仮想マシンの設定に
memballoonデバイスが含まれていることを確認します。virsh dumpxml testguest | grep memballoon <memballoon model='virtio'> </memballoon># virsh dumpxml testguest | grep memballoon <memballoon model='virtio'> </memballoon>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドで出力が表示され、モデルが
noneに設定されていない場合は、memballoonデバイスが存在します。バルーンドライバーがゲスト OS で実行していることを確認します。
-
Windows ゲストでは、ドライバーは
virtio-winドライバーパッケージの一部としてインストールされます。手順は、Installing paravirtualized KVM drivers for Windows virtual machines を参照してください。 -
Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、
memballoonデバイスがあれば、アクティベートされます。
-
Windows ゲストでは、ドライバーは
- Web コンソールの VM プラグインが システムにインストールされている。
手順
オプション: 仮想マシンの最大メモリーと現在使用されているメモリーに関する情報を取得します。これは、変更のベースラインとしても、検証のためにも機能します。
virsh dominfo testguest Max memory: 2097152 KiB Used memory: 2097152 KiB
# virsh dominfo testguest Max memory: 2097152 KiB Used memory: 2097152 KiBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHEL 9 Web コンソールにログインします。
詳細は、Web コンソールへのログイン を参照してください。
インターフェイスで、情報を表示する仮想マシンを選択します。
新しいページが開き、選択した仮想マシンに関する基本情報を含む Overview セクションと、仮想マシンのグラフィカルインターフェイスにアクセスするための Console セクションが表示されます。
概要ペインで、
Memory行の横にある をクリックします。メモリー調整ダイアログが表示されます。選択した仮想マシンの仮想メモリーを設定します。
最大割り当て: 仮想マシンがそのプロセスに使用できるホストメモリーの最大量を設定します。VM の作成時に最大メモリーを指定することも、後で増やすこともできます。メモリーは、MiB または GiB の倍数で指定できます。
仮想マシンをシャットダウンしてからでないと、最大メモリー割り当てを調整できません。
現在の割り当て - 仮想マシンに割り当てる実際のメモリー量を設定します。この値は、最大割り当てより小さい値にすることができますが、上限を超えることはできません。値を調整して、仮想マシンで利用可能なメモリーをプロセス用に調整できます。メモリーは、MiB または GiB の倍数で指定できます。
この値を指定しない場合、デフォルトの割り当ては最大割り当て の値になります。
をクリックします。
仮想マシンのメモリー割り当てが調整されます。
14.5.3. コマンドラインを使用した仮想マシンのメモリーの追加と削除 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのパフォーマンスを改善したり、使用しているホストリソースを解放したりするために、CLI を使用して、memballoon デバイスを使用して仮想マシンに割り当てられたメモリー量を調整できます。
IBM Z システムの仮想マシンに割り当てるメモリー量を調整するには、memballoon デバイスのみを使用します。その他のすべてのシステムでは、仮想マシンのメモリーを追加および削除するための推奨されるソリューションは、virtio-mem デバイスを使用することです。
前提条件
ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。
仮想マシンの設定に
memballoonデバイスが含まれていることを確認します。virsh dumpxml testguest | grep memballoon <memballoon model='virtio'> </memballoon># virsh dumpxml testguest | grep memballoon <memballoon model='virtio'> </memballoon>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドで出力が表示され、モデルが
noneに設定されていない場合は、memballoonデバイスが存在します。ballon ドライバーがゲスト OS で実行されていることを確認します。
-
Windows ゲストでは、ドライバーは
virtio-winドライバーパッケージの一部としてインストールされます。手順は、Installing paravirtualized KVM drivers for Windows virtual machines を参照してください。 -
Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、
memballoonデバイスがあれば、アクティベートされます。
-
Windows ゲストでは、ドライバーは
手順
オプション: 仮想マシンの最大メモリーと現在使用されているメモリーに関する情報を取得します。これは、変更のベースラインとしても、検証のためにも機能します。
virsh dominfo testguest Max memory: 2097152 KiB Used memory: 2097152 KiB
# virsh dominfo testguest Max memory: 2097152 KiB Used memory: 2097152 KiBCopy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンに割り当てる最大メモリーを調整します。この値を増やすと、仮想マシンのパフォーマンスが低下する可能性が向上し、値を減らすことで、仮想マシンがホスト上にあるパフォーマンスフットプリントが低減します。この変更は、停止している仮想マシンでのみ実行できるため、実行中の仮想マシンを調整するには再起動する必要があります。
たとえば、仮想マシン testguest が使用可能な最大メモリーを 4096 MiB に変更するには、次のコマンドを実行します。
virt-xml testguest --edit --memory memory=4096,currentMemory=4096 Domain 'testguest' defined successfully. Changes will take effect after the domain is fully powered off.
# virt-xml testguest --edit --memory memory=4096,currentMemory=4096 Domain 'testguest' defined successfully. Changes will take effect after the domain is fully powered off.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実行中の仮想マシンの最大メモリーを増やすには、仮想マシンにメモリーデバイスを割り当てます。これは、メモリーのホットプラグとも呼ばれます。詳細は、デバイスの仮想マシンへの接続 を参照してください。
警告実行中の仮想マシン (メモリーのホットアンプラグとも呼ばれる) から、メモリーデバイスを削除することはサポートされておらず、Red Hat では推奨していません。
オプション: 仮想マシンで現在使用されているメモリーを最大割り当て量まで調整することもできます。これにより、仮想マシンの最大割り当てを変更せずに、仮想マシンが次回の再起動までホスト上にあるメモリー負荷が調整されます。
virsh setmem testguest --current 2048
# virsh setmem testguest --current 2048Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンが使用するメモリーが更新されていることを確認します。
virsh dominfo testguest Max memory: 4194304 KiB Used memory: 2097152 KiB
# virsh dominfo testguest Max memory: 4194304 KiB Used memory: 2097152 KiBCopy to Clipboard Copied! Toggle word wrap Toggle overflow 現在の仮想マシンメモリーを調整した場合は、仮想マシンのメモリーバルーンの統計情報を取得して、そのメモリー使用量がどの程度効果的に制御されているかを評価できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.5.4. huge page を使用するように仮想マシンを設定する リンクのコピーリンクがクリップボードにコピーされました!
特定のユースケースでは、デフォルトの 4 KiB メモリーページの代わりに huge page を使用することで、仮想マシン (VM) のメモリー割り当てを改善できます。たとえば、huge page は、データベースサーバーなど、メモリー使用率の高い仮想マシンのパフォーマンスを向上させることができます。
前提条件
- メモリー割り当てで huge page を使用するようにホストが設定されている。手順については、起動時の HugeTLB の設定 を参照してください。
手順
- 選択した仮想マシンが実行中の場合はシャットダウンします。
1 GiB の huge page を使用するように仮想マシンを設定するために、仮想マシンの XML 定義を開いて編集します。たとえば、
testguest仮想マシンを編集するには、次のコマンドを実行します。virsh edit testguest
# virsh edit testguestCopy to Clipboard Copied! Toggle word wrap Toggle overflow XML 定義の
<memoryBacking>セクションに次の行を追加します。<memoryBacking> <hugepages> <page size='1' unit='GiB'/> </hugepages> </memoryBacking><memoryBacking> <hugepages> <page size='1' unit='GiB'/> </hugepages> </memoryBacking>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- 仮想マシンを起動します。
ホストが実行中の仮想マシンに huge page を正常に割り当てたことを確認します。ホスト上で次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 空き huge page と予約済み huge page の数 (
HugePages_Free+HugePages_Rsvd) を足すと、結果が huge page の合計数 (HugePages_Total) よりも少なくなるはずです。この差は、実行中の仮想マシンによって使用される huge page の数によるものです。
14.5.5. virtio-mem を使用した仮想マシンメモリーの追加および削除 リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 は、virtio-mem 準仮想化メモリーデバイスを提供します。このデバイスを使用すると、仮想マシン (VM) 内のホストメモリーを動的に追加または削除できます。たとえば、virtio-mem を使用して、実行中の仮想マシン間でメモリーリソースを移動したり、現在の要件に基づいてクラウドセットアップの仮想マシンメモリーのサイズを変更したりできます。
14.5.5.1. virtio-mem の概要 リンクのコピーリンクがクリップボードにコピーされました!
virtio-mem は、仮想マシンでホストメモリーを動的に追加または削除するために使用できる準仮想化メモリーデバイスです。たとえば、このデバイスを使用して、実行中の仮想マシン間でメモリーリソースを移動したり、現在の要件に基づいてクラウドセットアップの仮想マシンメモリーのサイズを変更したりできます。
virtio-mem を使用すると、4 から数百メビバイト (MiB) の単位で、仮想マシンのメモリーを初期サイズより増やしたり、元のサイズに縮小したりできます。ただし、virtio-mem は、特にメモリーを確実にアンプラグするために、特定のゲストオペレーティングシステム設定にも依存していることに注意してください。
virtio-mem 機能の制限
virtio-mem は現在、以下の機能と互換性がありません。
- ホスト上のリアルタイムアプリケーションのメモリーロックの使用
- ホストでの暗号化された仮想化の使用
-
virtio-memとホスト上でのmemballoon膨張および収縮の組み合わせ -
仮想マシンでの
virtio_memドライバーのアンロードまたはリロード -
virtiofsを除く vhost-user デバイスの使用
14.5.5.2. 仮想マシンでのメモリーのオンライン化設定 リンクのコピーリンクがクリップボードにコピーされました!
virtio-mem を使用して実行中の仮想マシンにメモリーを接続する (メモリーのホットプラグとも呼ばれます) 前に、ホットプラグされたメモリーが自動的にオンライン状態に設定されるように仮想マシン (VM) オペレーティングシステムを設定する必要があります。そうしないと、ゲストオペレーティングシステムは追加メモリーを使用できなくなります。メモリーのオンライン化については、次のいずれかの設定から選択できます。
-
online_movable -
online_kernel -
auto-movable
これらの設定の違いについては、メモリーのオンライン化設定の比較 を参照してください。
RHEL では、メモリーのオンライン化はデフォルトで udev ルールで設定されます。ただし、virtio-mem を使用する場合は、カーネル内でメモリーのオンライン化を直接設定することを推奨します。
前提条件
- ホストが、Intel 64、AMD64、または ARM 64 CPU アーキテクチャーを使用している。
- ホストがオペレーティングシステムとして RHEL 9.4 以降を使用している。
ホスト上で実行されている仮想マシンが、次のいずれかのオペレーティングシステムバージョンを使用している。
RHEL 8.10
重要RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。
- RHEL 9
手順
仮想マシンで
online_movable設定を使用するようにメモリーオンライン化を設定するには、以下を実行します。memhp_default_stateカーネルコマンドラインパラメーターをonline_movableに設定します。grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_movable
# grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_movableCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンを再起動します。
仮想マシンで
online_kernel設定を使用するようにメモリーオンライン化を設定するには、以下を実行します。以下のように、
memhp_default_stateカーネルコマンドラインパラメーターをonline_kernelに設定します。grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_kernel
# grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_kernelCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンを再起動します。
仮想マシンで
auto-movableメモリーオンライン化ポリシーを使用するには、以下の手順を実行します。memhp_default_stateカーネルコマンドラインパラメーターをonlineに設定します。grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online
# grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=onlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow memory_hotplug.online_policyカーネルコマンドラインパラメーターをauto-movableに設定します。grubby --update-kernel=ALL --remove-args="memory_hotplug.online_policy" --args=memory_hotplug.online_policy=auto-movable
# grubby --update-kernel=ALL --remove-args="memory_hotplug.online_policy" --args=memory_hotplug.online_policy=auto-movableCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
auto-movableオンライン化ポリシーをさらにチューニングするには、memory_hotplug.auto_movable_ratioおよびmemory_hotplug.auto_movable_numa_awareパラメーターを変更します。grubby --update-kernel=ALL --remove-args="memory_hotplug.auto_movable_ratio" --args=memory_hotplug.auto_movable_ratio=<percentage> grubby --update-kernel=ALL --remove-args="memory_hotplug.memory_auto_movable_numa_aware" --args=memory_hotplug.auto_movable_numa_aware=<y/n>
# grubby --update-kernel=ALL --remove-args="memory_hotplug.auto_movable_ratio" --args=memory_hotplug.auto_movable_ratio=<percentage> # grubby --update-kernel=ALL --remove-args="memory_hotplug.memory_auto_movable_numa_aware" --args=memory_hotplug.auto_movable_numa_aware=<y/n>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
memory_hotplug.auto_movable_ratio parameterは、任意の割り当てに使用できるメモリーと比較すると、移動可能な割り当てにのみ使用できるメモリーの最大比率を設定します。比率はパーセントで表され、デフォルト値は 3:1 の比率である 301 (%) です。 memory_hotplug.auto_movable_numa_awareパラメーターは、memory_hotplug.auto_movable_ratioパラメーターを使用可能なすべての NUMA ノードのメモリーに適用するか、単一の NUMA ノード内のメモリーのみに適用するかを制御します。デフォルト値は y (yes) です。たとえば、最大比率を 301% に設定し、
memory_hotplug.auto_movable_numa_awareが y (yes) に設定されている場合は、アタッチされたvirtio-memデバイスを持つ NUMA ノード内でも 3:1 の比率が適用されます。パラメーターが n (no) に設定されている場合、最大 3:1 の比率はすべての NUMA ノード全体に対してのみ適用されます。また、比率を超えていない場合、新しくホットプラグされたメモリーは、移動可能な割り当てに対してのみ利用できます。それ以外の場合では、新しくホットプラグされたメモリーは、移動可能な割り当てと移動不可能な割り当ての両方に使用できます。
-
- 仮想マシンを再起動します。
検証
online_movable設定が正しく設定されているかを確認するには、memhp_default_stateカーネルパラメーターの現在の値を確認します。cat /sys/devices/system/memory/auto_online_blocks online_movable
# cat /sys/devices/system/memory/auto_online_blocks online_movableCopy to Clipboard Copied! Toggle word wrap Toggle overflow online_kernel設定が正しく設定されているかを確認するには、memhp_default_stateカーネルパラメーターの現在の値を確認します。cat /sys/devices/system/memory/auto_online_blocks online_kernel
# cat /sys/devices/system/memory/auto_online_blocks online_kernelCopy to Clipboard Copied! Toggle word wrap Toggle overflow auto-movable設定が正しく設定されているかを確認するには、以下のカーネルパラメーターを確認してください。memhp_default_state:cat /sys/devices/system/memory/auto_online_blocks online
# cat /sys/devices/system/memory/auto_online_blocks onlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow memory_hotplug.online_policy:cat /sys/module/memory_hotplug/parameters/online_policy auto-movable
# cat /sys/module/memory_hotplug/parameters/online_policy auto-movableCopy to Clipboard Copied! Toggle word wrap Toggle overflow memory_hotplug.auto_movable_ratio:cat /sys/module/memory_hotplug/parameters/auto_movable_ratio 301
# cat /sys/module/memory_hotplug/parameters/auto_movable_ratio 301Copy to Clipboard Copied! Toggle word wrap Toggle overflow memory_hotplug.auto_movable_numa_aware:cat /sys/module/memory_hotplug/parameters/auto_movable_numa_aware y
# cat /sys/module/memory_hotplug/parameters/auto_movable_numa_aware yCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.5.5.3. Attaching a virtio-mem device to virtual machines リンクのコピーリンクがクリップボードにコピーされました!
実行中の仮想マシンに追加のメモリーをアタッチ (メモリーのホットプラグとも呼ばれます) し、その後ホットプラグされたメモリーのサイズを変更できるようにするには、virtio-mem デバイスを使用できます。具体的には、libvirt XML 設定ファイルと virsh コマンドを使用し、virtio-mem デバイスを定義して仮想マシン (VM) に割り当てることができます。
前提条件
- ホストが、Intel 64、AMD64、または ARM 64 CPU アーキテクチャーを使用している。
- ホストがオペレーティングシステムとして RHEL 9.4 以降を使用している。
ホスト上で実行されている仮想マシンが、次のいずれかのオペレーティングシステムバージョンを使用している。
RHEL 8.10
重要RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。
- RHEL 9
- VM にメモリーオンライン化が設定されている。手順は、仮想マシンでのメモリーのオンライン化設定 を参照してください。
手順
ターゲット仮想マシンの XML 設定に
maxMemoryパラメーターが含まれるようにします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
testguest1仮想マシンの XML 設定で、128 ギビバイト (GiB) のmaxMemoryパラメーターが定義されています。maxMemoryサイズは、仮想マシンが使用できる最大メモリーを指定します。これには、初期メモリーとホットプラグされたメモリーの両方が含まれます。XML ファイルを作成して開き、ホスト上の
virtio-memデバイスを定義します。次に例を示します。vim virtio-mem-device.xml
# vim virtio-mem-device.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow virtio-memデバイスの XML 定義をファイルに追加し、保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つの
virtio-memデバイスが以下のパラメーターで定義されます。-
size: これは、デバイスの最大サイズです。この例では 48 GiB です。sizeはblockサイズの倍数である必要があります。 -
node: これは、virtio-memデバイスに割り当てられた vNUMA ノードです。 -
block: これはデバイスのブロックサイズです。これは、少なくとも transparent huge page (THP) のサイズである必要があります。THP は、Intel 64 および AMD64 CPU アーキテクチャーでは 2 MiB です。ARM64 アーキテクチャーでは、THP のサイズはベースページサイズに応じて 2 MiB または 512 MiB になります。通常、Intel 64 または AMD64 アーキテクチャーでは、2 MiB ブロックサイズが適切なデフォルトの選択となります。virtio-memを Virtual Function I/O (VFIO) または 仲介デバイス (mdev) で使用する場合、すべてのvirtio-memデバイスにまたがるブロックの合計数は 32768 を超えることはできません。超えると、RAM のプラグインに失敗する可能性があります。 -
requested: これは、virtio-memデバイスを使用して仮想マシンに割り当てるメモリー量です。ただし、これは VM に対する単なるリクエストであり、VM が適切に設定されていない場合など、正常に解決されない可能性があります。requestedサイズはblockサイズの倍数である必要があり、定義された最大sizeを超えることはできません。 -
current: これは、virtio-memデバイスが仮想マシンに提供する現在のサイズを表します。たとえば、リクエストを完了できない場合や VM を再起動する場合など、currentサイズは、requestedサイズとは異なる場合があります。 alias: これは、libvirt コマンドでデバイスを編集する場合など、目的のvirtio-memデバイスを指定するために使用できるオプションのユーザー定義のエイリアスです。libvirt のすべてのユーザー定義のエイリアスは、"ua-" 接頭辞で始まる必要があります。これらの特定のパラメーターとは別に、
libvirtは、virtio-memデバイスを他の PCI デバイスと同様に処理します。
-
XML ファイルを使用して、定義された
virtio-memデバイスを仮想マシンにアタッチします。たとえば、virtio-mem-device.xmlで定義された 2 つのデバイスを実行中の仮想マシンtestguest1に永続的にアタッチするには、次のコマンドを実行します。virsh attach-device testguest1 virtio-mem-device.xml --live --config
# virsh attach-device testguest1 virtio-mem-device.xml --live --configCopy to Clipboard Copied! Toggle word wrap Toggle overflow --liveオプションは、実行中の仮想マシンにのみデバイスを接続します。再起動後に永続性は維持されません。--configオプションは、設定の変更を永続化します。--liveオプションを指定せずに、デバイスをシャットダウンした仮想マシンに接続することもできます。オプション: 実行中の仮想マシンに接続されている
virtio-memデバイスのrequestedサイズを動的に変更するには、virsh update-memory-deviceコマンドを使用します。virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 4GiB
# virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 4GiBCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、以下が適用されます。
-
testguest1は、更新する仮想マシンです。 -
--alias ua-virtiomem0は、以前に定義されたエイリアスで指定されたvirtio-memデバイスです。 --requested-size 4GiBは、virtio-memデバイスのrequestedサイズを 4 GiB に変更します。警告requestedサイズを減らして実行中の仮想マシンからメモリーをアンプラグすると、信頼性が低下する可能性があります。このプロセスが成功するかどうかは、使用中のメモリーラインニングポリシーなど、さまざまな要因によって決まります。場合によっては、その時点でホットプラグされたメモリーの量を変更できないため、ゲストオペレーティングシステムが要求を正常に完了できないことがあります。
さらに、RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。
-
オプション: シャットダウンした仮想マシンから
virtio-memデバイスを取り外すには、virsh detach-deviceコマンドを使用します。virsh detach-device testguest1 virtio-mem-device.xml
# virsh detach-device testguest1 virtio-mem-device.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 実行中の仮想マシンから
virtio-memデバイスを取り外すには、以下を実行します。virtio-memデバイスのrequestedサイズを 0 に変更します。そうしないと、実行中の仮想マシンからvirtio-memデバイスを取り外す試行が失敗します。virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 0
# virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実行中の仮想マシンから
virtio-memデバイスを取り外します。virsh detach-device testguest1 virtio-mem-device.xml --config
# virsh detach-device testguest1 virtio-mem-device.xml --configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンで、利用可能な RAM を確認し、合計量にホットプラグされたメモリーが含まれているかを確認します。
free -h total used free shared buff/cache available Mem: 31Gi 5.5Gi 14Gi 1.3Gi 11Gi 23Gi Swap: 8.0Gi 0B 8.0Gi# free -h total used free shared buff/cache available Mem: 31Gi 5.5Gi 14Gi 1.3Gi 11Gi 23Gi Swap: 8.0Gi 0B 8.0GiCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実行中の仮想マシンの XML 設定を表示して、プラグイン RAM の現在の容量をホストで表示することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、以下が適用されます。
-
<currentMemory unit='GiB'>31</currentMemory>は、すべてのソースから VM で利用可能な合計 RAM を表します。 -
<current unit='GiB'>16</current>は、virtio-memデバイスが提供するプラグイン RAM の現在のサイズを表します。
-
14.5.5.4. メモリーのオンライン化設定の比較 リンクのコピーリンクがクリップボードにコピーされました!
実行中の RHEL 仮想マシンにメモリーをアタッチする場合 (メモリーのホットプラグとも呼ばれます)、仮想マシン (VM) のオペレーティングシステムでホットプラグされたメモリーをオンライン状態に設定する必要があります。そうしないと、システムはメモリーを使用できなくなります。
次の表は、利用可能なメモリーのオンライン化設定を選択する際の主な考慮事項をまとめたものです。
| 設定名 | 仮想マシンからのメモリーのアンプラグ | メモリーゾーンの不均等性が発生するリスク | 潜在的なユースケース | 目的のワークロードのメモリー要件 |
|---|---|---|---|---|
|
| ホットプラグされたメモリーを確実に取り外すことができます。 | あり | 比較的少量のメモリーのホットプラグ | ほとんどがユーザー空間のメモリー |
|
| ホットプラグされたメモリーの可動部分は確実に取り外すことができます。 | 最小 | 大量のメモリーのホットプラグ | ほとんどがユーザー空間のメモリー |
|
| ホットプラグされたメモリーは確実に取り外すことができません。 | なし | 信頼性の低いメモリーの取り外しは許容されます。 | ユーザー空間またはカーネル空間のメモリー |
ゾーン不均衡 とは、Linux メモリーゾーンの 1 つに、使用可能なメモリーページがないことです。ゾーン不均衡 になると、システムのパフォーマンスに悪影響を及ぼす可能性があります。たとえば、移動不可能な割り当てが原因で空きメモリーが不足すると、カーネルがクラッシュする可能性があります。通常、移動可能な割り当てには、主にユーザー空間のメモリーページが含まれ、移動不可能な割り当てには、主にカーネル空間のメモリーページが含まれています。
14.6. 仮想マシンの I/O パフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの入出力 (I/O) 機能は、仮想マシンの全体的な効率を大幅に制限する可能性があります。これに対処するために、ブロック I/O パラメーターを設定して、仮想マシンの I/O を最適化できます。
14.6.1. 仮想マシンにおけるブロック I/O のチューニング リンクのコピーリンクがクリップボードにコピーされました!
複数のブロックデバイスが、複数の仮想マシンで使用されている場合は、I/O ウェイト を変更して特定の仮想デバイスの I/O の優先度を調整することが重要になる場合があります。
デバイスの I/O ウェイトを上げると、I/O 帯域幅の優先度が高まるため、より多くのホストリソースが提供されます。同様に、デバイスのウェイトを下げると、ホストのリソースが少なくなります。
各デバイスの ウェイト の値は 100 から 1000 の範囲内でなければなりません。もしくは、値を 0 にすると、各デバイスのリストからそのデバイスを削除できます。
手順
仮想マシンのブロック I/O パラメーターを表示および設定するには、以下を行います。
仮想マシンの現在の
<blkio>パラメーターを表示します。# virsh dumpxml VM-nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 指定したデバイスの I/O ウェイトを編集します。
virsh blkiotune VM-name --device-weights device, I/O-weight
# virsh blkiotune VM-name --device-weights device, I/O-weightCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次の例では、testguest1 仮想マシンの /dev/sda デバイスの重みを 500 に変更します。
virsh blkiotune testguest1 --device-weights /dev/sda, 500
# virsh blkiotune testguest1 --device-weights /dev/sda, 500Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
仮想マシンのブロック I/O パラメーターが正しく設定されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要一部のカーネルは、特定のデバイスの I/O 重み設定をサポートしていません。前の手順で期待どおりに重みが表示されない場合は、この機能がホストカーネルと互換性がない可能性があります。
14.6.2. 仮想マシンのディスク I/O スロットリング リンクのコピーリンクがクリップボードにコピーされました!
複数の仮想マシンが同時に実行する場合は、過剰なディスク I/O により、システムパフォーマンスに影響が及ぶ可能性があります。KVM 仮想化のディスク I/O スロットリングでは、仮想マシンからホストマシンに送られるディスク I/O 要求に制限を設定する機能を利用できます。これにより、仮想マシンが共有リソースを過剰に使用し、その他の仮想マシンのパフォーマンスに影響を及ぼすことを防ぐことができます。
ディスク I/O スロットリングを有効にするには、仮想マシンに割り当てられた各ブロックデバイスからホストマシンに送られるディスク I/O 要求に制限を設定します。
手順
virsh domblklistコマンドを使用して、指定された仮想マシン上のすべてのディスクデバイスの名前をリスト表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow スロットルする仮想ディスクがマウントされているホストブロックデバイスを見つけます。
たとえば、前の手順の
sdb仮想ディスクをスロットリングする場合は、以下の出力では、ディスクが/dev/nvme0n1p3パーティションにマウントされていることを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow virsh blkiotuneコマンドを使用して、ブロックデバイスの I/O 制限を設定します。virsh blkiotune VM-name --parameter device,limit
# virsh blkiotune VM-name --parameter device,limitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例は、
rollin-coal仮想マシン上のsdbディスクを毎秒 1000 の読み書き操作にスロットリングし、毎秒 50 MB の読み書きスループットにスロットリングします。virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800
# virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
- ディスク I/O スロットリングは、異なる顧客に属する仮想マシンが同じホストで実行されている場合や、異なる仮想マシンに QoS 保証が提供されている場合など、さまざまな状況で役立ちます。ディスク I/O スロットリングは、低速なディスクをシミュレートするために使用することもできます。
- I/O スロットリングは、仮想マシンに割り当てられた各ブロックデバイスに個別に適用でき、スループットおよび I/O 操作の制限に対応します。
-
Red Hat は、
virsh blkdeviotuneコマンドを使用した仮想マシンでの I/O スロットリングの設定はサポートしていません。RHEL 9 を VM ホストとして使用する場合にサポートされていない機能の詳細は、RHEL 9 仮想化でサポートされていない機能 を参照してください。
14.6.3. ストレージデバイスでの multi-queue の有効化 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) で virtio-blk または virtio-scsi ストレージデバイスを使用する場合、multi-queue 機能によりストレージパフォーマンスとスケーラビリティーが向上します。このため、各仮想 CPU (vCPU) に別のキューを持たせることが可能になります。また仮想 CPU は、その他の vCPU に影響を及ぼすことなく使用するために、割り込みできるようになります。
multi-queue 機能は Q35 マシンタイプではデフォルトで有効になっていますが、i440FX マシンタイプでは手動で有効にする必要があります。キューの数をワークロードに最適になるように調整できます。ただし、最適な数はワークロードの種類ごとに異なるため、どのキュー数が最適かをテストする必要があります。
手順
ストレージデバイスで
multi-queueを有効にするために、仮想マシンの XML 設定を編集します。virsh edit <example_vm>
# virsh edit <example_vm>Copy to Clipboard Copied! Toggle word wrap Toggle overflow XML 設定で、目的のストレージデバイスを見つけて、複数の I/O キューを使用するように
queuesパラメーターを変更します。N を仮想マシン内の仮想 CPU の数 (最大 16 個) に置き換えます。virtio-blkの例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow virtio-scsiの例:<controller type='scsi' index='0' model='virtio-scsi'> <driver queues='N' /> </controller>
<controller type='scsi' index='0' model='virtio-scsi'> <driver queues='N' /> </controller>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 仮想マシンを再起動して変更を有効にします。
14.6.4. 専用の IOThreads の設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) 上のディスクの入出力 (IO) パフォーマンスを向上させるために、仮想マシンのディスクの IO 操作を管理するために使用される専用の IOThread を設定できます。
通常、ディスクの IO 操作はメインの QEMU スレッドの一部です。そのため、集中的な IO ワークロードの実行時に、仮想マシン全体の応答性が低下する可能性があります。IO 操作を専用の IOThread に分離することで、仮想マシンの応答性とパフォーマンスを大幅に向上させることができます。
手順
- 選択した仮想マシンが実行中の場合はシャットダウンします。
ホストで、仮想マシンの XML 設定に
<iothreads>タグを追加または編集します。たとえば、testguest1仮想マシンに 1 つのIOThreadを作成するには、次のようにします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記最適な結果を得るには、ホスト上の CPU ごとに 1 - 2 個の
IOThreadのみを使用してください。仮想マシンディスクに専用の
IOThreadを割り当てます。たとえば、ID が1のIOThreadをtestguest1仮想マシン上のディスクに割り当てるには、次のように指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記IOThreadの ID は 1 から始まります。ディスクごとに 1 つのIOThreadのみを割り当てる必要があります。通常、最適なパフォーマンスを得るには、仮想マシンごとに 1 つの専用
IOThreadで十分です。virtio-scsiストレージデバイスを使用する場合は、virtio-scsiコントローラーに専用のIOThreadを割り当てます。たとえば、ID が1のIOThreadをtestguest1仮想マシン上のコントローラーに割り当てるには、次のように指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- 仮想マシンのパフォーマンスに対する変更の効果を評価します。詳細は、仮想マシンのパフォーマンス監視ツール を参照してください。
14.6.5. 仮想ディスクキャッシュの設定 リンクのコピーリンクがクリップボードにコピーされました!
KVM にはいくつかの仮想ディスクキャッシュモードがあります。集中的な入出力 (IO) ワークロードがある場合は、最適なキャッシュモードを選択すると、仮想マシン (VM) のパフォーマンスが大幅に向上します。
+
仮想ディスクキャッシュモードの概要
writethrough- ホストのページキャッシュが読み取り専用として使用されます。データがストレージデバイスにコミットされた場合にのみ、書き込みが完了したと報告されます。このモードでは、持続的な IO パフォーマンスは低下しますが、書き込みが十分に保証されます。
writeback-
ホストのページキャッシュが読み取りと書き込みの両方に使用されます。データが物理ストレージではなくホストのメモリーキャッシュに到達したときに、書き込みが完了したと報告されます。このモードは
writethroughよりも IO パフォーマンスが高速ですが、ホスト障害時にデータが失われる可能性があります。 none- ホストのページキャッシュが完全に回避されます。このモードは物理ディスクの書き込みキューに直接依存します。そのため、予測可能な持続的な IO パフォーマンスが得られ、安定したゲスト上で書き込みが十分に保証されます。これは、仮想マシンライブマイグレーションのための安全なキャッシュモードでもあります。
手順
- 選択した仮想マシンが実行中の場合はシャットダウンします。
選択した仮想マシンの XML 設定を編集します。
virsh edit <vm_name>
# virsh edit <vm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディスクデバイスを見つけて、
driverタグのcacheオプションを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7. 仮想マシンの CPU パフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
vCPU は、ホストマシンの物理 CPU と同様、仮想マシンのパフォーマンスにおいて極めて重要です。したがって、vCPU を最適化すると、仮想マシンのリソース効率に大きな影響を及ぼす可能性があります。vCPU を最適化するには、以下を実行します。
- 仮想マシンに割り当てられているホスト CPU の数を調整します。これは、CLI または Web コンソール を使用して実行できます。
vCPU モデルが、ホストの CPU モデルに調整されていることを確認します。たとえば、仮想マシン testguest1 を、ホストの CPU モデルを使用するように設定するには、次のコマンドを実行します。
virt-xml testguest1 --edit --cpu host-model
# virt-xml testguest1 --edit --cpu host-modelCopy to Clipboard Copied! Toggle word wrap Toggle overflow ARM 64 システムでは、
--cpu host-passthroughを使用します。- Kernel Same-Page Merging (KSM) を管理します。
ホストマシンが Non-Uniform Memory Access (NUMA) を使用する場合は、その仮想マシンに対して NUMA を設定 することもできます。これにより、ホストの CPU およびメモリープロセスが、仮想マシンの CPU およびメモリープロセスにできるだけ近くにマッピングされます。事実上、NUMA チューニングにより、仮想マシンに割り当てられたシステムメモリーへのより効率的なアクセスが可能になります。これにより、vCPU 処理の効果が改善されます。
詳細は、仮想マシンでの NUMA の設定 および 特定のワークロードに合わせた仮想マシンのパフォーマンスの最適化 を参照してください。
14.7.1. 仮想 CPU のオーバーコミット リンクのコピーリンクがクリップボードにコピーされました!
仮想 CPU のオーバーコミットを使用すると、ホスト上で実行される仮想マシン (VM) 内の全仮想 CPU の合計数が、ホスト上の物理 CPU の数を超える設定が可能になります。ただし、ホスト上で物理的に使用可能なコア数よりも多くのコアを仮想マシンで同時に実行すると、パフォーマンスが低下する可能性があります。
最高のパフォーマンスを得るには、各仮想マシンで目的のワークロードを実行するのに必要な数の仮想 CPU だけを仮想マシンに割り当てます。
仮想 CPU のオーバーコミットに関する推奨事項を以下に示します。
- 最高のパフォーマンスを得るために、仮想マシンのワークロードに必要な最小限の仮想 CPU を割り当てます。
- 詳細なテストを行わずに実稼働環境で仮想 CPU をオーバーコミットすることは避けてください。
- 仮想 CPU をオーバーコミットする場合、負荷が 100% 未満のときは、通常、仮想 CPU と物理 CPU の比率を 5 対 1 にするのが安全です。
- 物理プロセッサーコアごとに合計 10 個を超える仮想 CPU を割り当てることは推奨されません。
- 高負荷時のパフォーマンス低下を防ぐために CPU 使用率を監視します。
オーバーコミットされた環境では、メモリーを 100% 使用するアプリケーションや処理リソースが不安定になる可能性があります。CPU のオーバーコミット率はワークロードに依存するため、詳細なテストを行わずに実稼働環境でメモリーや CPU をオーバーコミットしないでください。
14.7.2. コマンドラインを使用した仮想 CPU の追加と削除 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの CPU パフォーマンスを増減するには、仮想マシンに割り当てられた仮想 CPU (vCPU) を追加または削除します。
実行中の仮想マシンで実行する場合、これは vCPU ホットプラグおよびホットアンプラグとも呼ばれます。ただし、RHEL 9 では vCPU のホットアンプラグに対応しておらず、Red Hat ではその使用を強く推奨していません。
前提条件
オプション: ターゲット仮想マシン内の vCPU の現在の状態を表示します。たとえば、仮想マシン testguest 上の vCPU の数を表示するには、以下を実行します。
virsh vcpucount testguest maximum config 4 maximum live 2 current config 2 current live 1
# virsh vcpucount testguest maximum config 4 maximum live 2 current config 2 current live 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、testguest が現在 1 vCPU を使用していることを示し、1 つ以上の vCPU をホットプラグして仮想マシンのパフォーマンスを向上できることを示しています。ただし、再起動後に使用される vCPU の testguest 数は 2 に変更され、2 以上の vCPU のホットプラグが可能になります。
手順
仮想マシンに割り当てることができる vCPU の最大数を調整します。これは、仮想マシンの次回起動時に有効になります。
たとえば、仮想マシン testguest の vCPU の最大数を 8 に増やすには、次のコマンドを実行します。
virsh setvcpus testguest 8 --maximum --config
# virsh setvcpus testguest 8 --maximum --configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最大値は、CPU トポロジー、ホストハードウェア、ハイパーバイザー、およびその他の要素によって制限される可能性があることに注意してください。
仮想マシンに割り当てられている現在の vCPU の数を、前の手順で設定した最大値まで調整します。以下に例を示します。
実行中の仮想マシン testguest にアタッチされている vCPU を 4 に増やすには、以下を実行します。
virsh setvcpus testguest 4 --live
# virsh setvcpus testguest 4 --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、仮想マシンの次回の起動まで、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが高まります。
testguest 仮想マシンにアタッチされている vCPU の数を永続的に 1 に減らすには、次のコマンドを実行します。
virsh setvcpus testguest 1 --config
# virsh setvcpus testguest 1 --configCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、仮想マシンの次回の起動後に、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが低下します。ただし、必要に応じて、仮想マシンに追加の vCPU をホットプラグして、一時的にパフォーマンスを向上させることができます。
検証
仮想マシンの vCPU の現在の状態に変更が反映されていることを確認します。
virsh vcpucount testguest maximum config 8 maximum live 4 current config 1 current live 4
# virsh vcpucount testguest maximum config 8 maximum live 4 current config 1 current live 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.3. Web コンソールを使用した仮想 CPU の管理 リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 Web コンソールを使用して、Web コンソールが接続している仮想マシンが使用する仮想 CPU を確認し、設定できます。
前提条件
- RHEL 9 Web コンソールがインストールされている。
- cockpit サービスが有効になっている。
ユーザーアカウントが Web コンソールにログインできる。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
- Web コンソールの VM プラグインが システムにインストールされている。
手順
RHEL 9 Web コンソールにログインします。
詳細は、Web コンソールへのログイン を参照してください。
インターフェイスで、情報を表示する仮想マシンを選択します。
新しいページが開き、選択した仮想マシンに関する基本情報を含む Overview セクションと、仮想マシンのグラフィカルインターフェイスにアクセスするための Console セクションが表示されます。
概要ペインで、vCPU の数の横にある をクリックします。
vCPU の詳細ダイアログが表示されます。
選択した仮想マシンの仮想 CPU を設定します。
vCPU 数: 現在使用中の vCPU の数
注記vCPU 数は、vCPU 最大値以下にする必要があります。
- vCPU 最大値 - 仮想マシンに設定できる仮想 CPU の最大数を入力します。この値が vCPU 数 よりも大きい場合には、vCPU を追加で仮想マシンに割り当てることができます。
- ソケット - 仮想マシンに公開するソケットの数を選択します。
- ソケットごとのコア - 仮想マシンに公開する各ソケットのコア数を選択します。
コアあたりのスレッド - 仮想マシンに公開する各コアのスレッド数を選択します。
Sockets、Cores per socket、および Threads per core オプションは、仮想マシンの CPU トポロジーを調整することに注意してください。これは、vCPU のパフォーマンスにメリットがあり、ゲスト OS の特定のソフトウェアの機能に影響を与える可能性があります。デプロイメントで別の設定が必要ない場合は、デフォルト値のままにします。
をクリックします。
仮想マシンに仮想 CPU が設定されます。
注記仮想 CPU 設定の変更は、仮想マシンの再起動後にのみ有効になります。
14.7.4. 仮想マシンでの NUMA の設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の方法は、RHEL 9 ホストで、仮想マシンの Non-Uniform Memory Access (NUMA) 設定の設定に使用できます。
使いやすさのため、自動化ユーティリティーとサービスを使用して、仮想マシンの NUMA を設定できます。ただし、手動で NUMA を設定すると、パフォーマンスが大幅に向上する可能性が高くなります。
前提条件
ホストが NUMA 対応のマシンである。これを確認するには、
virsh nodeinfoコマンドを使用して、NUMA cell(2)の行を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 行の値が 2 以上であると、そのホストは NUMA に対応しています。
オプション: ホストに
numactlパッケージがインストールされている。dnf install numactl
# dnf install numactlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
自動方式
仮想マシンの NUMA ポリシーを
Preferredに設定します。たとえば、testguest5 仮想マシンを設定するには、次のコマンドを実行します。virt-xml testguest5 --edit --vcpus placement=auto virt-xml testguest5 --edit --numatune mode=preferred
# virt-xml testguest5 --edit --vcpus placement=auto # virt-xml testguest5 --edit --numatune mode=preferredCopy to Clipboard Copied! Toggle word wrap Toggle overflow numadサービスを使用して、メモリーリソースに合わせて仮想マシン CPU を自動的に調整します。echo 1 > /proc/sys/kernel/numa_balancing
# echo 1 > /proc/sys/kernel/numa_balancingCopy to Clipboard Copied! Toggle word wrap Toggle overflow umadサービスを起動して、メモリーリソースで仮想マシンの CPU を自動的に調整します。systemctl start numad
# systemctl start numadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手動方式
NUMA 設定を手動で調整する場合は、特定の仮想マシンにどのホスト NUMA ノードを割り当てるかを指定できます。これにより、仮想マシンの vCPU によるホストメモリーの使用率が向上します。
オプション:
numactlコマンドを使用して、ホスト上の NUMA トポロジーを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの XML 設定を編集して、特定の NUMA ノードに CPU およびメモリーリソースを割り当てます。たとえば、次の設定では、testguest6 が NUMA ノード
0の仮想 CPU 0 - 7 と NUMA ノード1の仮想 CPU 8 - 15 を使用するように指定します。両方のノードに 16 GiB の仮想マシンメモリーも割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 仮想マシンが実行中の場合は、再起動して設定を適用します。
最高のパフォーマンス結果を得るために、ホスト上の各 NUMA ノードの最大メモリーサイズに従うことを推奨します。
14.7.5. 仮想 CPU ピニングの設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシン (VM) の CPU パフォーマンスを向上させるために、ホスト上の特定の物理 CPU スレッドに仮想 CPU (vCPU) をピニングすることができます。これにより、仮想 CPU に専用の物理 CPU スレッドが確保され、仮想 CPU のパフォーマンスが大幅に向上します。
CPU パフォーマンスをさらに最適化するために、指定の仮想マシンに関連付けられた QEMU プロセススレッドを、特定のホスト CPU にピニングすることもできます。
手順
ホストの CPU トポロジーを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、NUMA ノードとホスト上の使用可能な物理 CPU スレッドが出力に含まれています。
仮想マシン内の仮想 CPU スレッドの数を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、NUMA ノードと仮想マシン内の使用可能な仮想 CPU スレッドが出力に含まれています。
仮想マシンの特定の仮想 CPU スレッドを、特定のホスト CPU または CPU の範囲にピニングします。これは、仮想 CPU のパフォーマンスを向上させる安全な方法として推奨されます。
たとえば、次のコマンドは、testguest6 仮想マシンの仮想 CPU スレッド 0 - 3 を、それぞれホスト CPU 1、3、5、7 にピニングします。
virsh vcpupin testguest6 0 1 virsh vcpupin testguest6 1 3 virsh vcpupin testguest6 2 5 virsh vcpupin testguest6 3 7
# virsh vcpupin testguest6 0 1 # virsh vcpupin testguest6 1 3 # virsh vcpupin testguest6 2 5 # virsh vcpupin testguest6 3 7Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 仮想 CPU スレッドが CPU に正常にピニングされているかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vCPU スレッドのピニング後に、指定の仮想マシンに関連付けられた QEMU プロセススレッドを、特定ホスト CPU、またはある範囲の CPU に固定することもできます。これにより、QEMU プロセスが物理 CPU 上でより効率的に実行されるようになります。
たとえば、次のコマンドは、testguest6 の QEMU プロセススレッドを CPU 2 および 4 にピニングし、これが成功したことを確認します。
virsh emulatorpin testguest6 2,4 virsh emulatorpin testguest6 emulator: CPU Affinity ---------------------------------- *: 2,4# virsh emulatorpin testguest6 2,4 # virsh emulatorpin testguest6 emulator: CPU Affinity ---------------------------------- *: 2,4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.6. 仮想 CPU キャッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
仮想 CPU (vCPU) キャッピングを使用すると、仮想マシン (VM) が使用できる CPU リソースの量を制限できます。1 台の仮想マシンによるホストの CPU リソースの過剰な使用を防ぎ、ハイパーバイザーによる CPU スケジューリングの管理を容易にすることで、全体的なパフォーマンスを向上させることができます。
手順
ホストの現在の仮想 CPU スケジューリング設定を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンの絶対的な仮想 CPU キャップを設定するには、
vcpu_periodおよびvcpu_quotaパラメーターを設定します。どちらのパラメーターも、マイクロ秒単位の時間の長さを表す数値を使用します。virsh schedinfoコマンドを使用してvcpu_periodパラメーターを設定します。以下に例を示します。virsh schedinfo <vm_name> --set vcpu_period=100000
# virsh schedinfo <vm_name> --set vcpu_period=100000Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
vcpu_periodは 100,000 マイクロ秒に設定されています。これは、スケジューラーがこの時間間隔中に仮想 CPU キャッピングを適用することを意味します。--live --configオプションを使用して、実行中の仮想マシンを再起動せずに設定することもできます。virsh schedinfoコマンドを使用してvcpu_quotaパラメーターを設定します。以下に例を示します。virsh schedinfo <vm_name> --set vcpu_quota=50000
# virsh schedinfo <vm_name> --set vcpu_quota=50000Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
vcpu_quotaは 50,000 マイクロ秒に設定されています。これは、vcpu_period時間間隔中に仮想マシンが使用できる CPU 時間の最大量を指定します。この場合、vcpu_quotaはvcpu_periodの半分に設定されているため、仮想マシンはその間隔中に CPU 時間の最大 50% を使用できます。--live --configオプションを使用して、実行中の仮想マシンを再起動せずに設定することもできます。
検証
仮想 CPU スケジューリングのパラメーターの値が正しいことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.7.7. CPU 重みの調整 リンクのコピーリンクがクリップボードにコピーされました!
CPU 重み (または CPU シェア) 設定は、実行中の他の仮想マシンと比較して、仮想マシン (VM) が受け取る CPU 時間を制御するものです。特定の仮想マシンの CPU 重み を増やすことで、この仮想マシンが他の仮想マシンよりも多くの CPU 時間を確保できるようになります。複数の仮想マシン間で CPU 時間の割り当ての優先度を設定するには、cpu_shares パラメーターを設定します。
指定可能な CPU 重み値の範囲は 0 から 262144 です。新しい KVM 仮想マシンのデフォルト値は 1024 です。
手順
仮想マシンの現在の CPU 重み を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CPU 重み を希望の値に調整します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
cpu_sharesは 2048 に設定されています。そのため、他のすべての仮想マシンの値が 1024 に設定されている場合、この仮想マシンには約 2 倍の CPU 時間が割り当てられます。--live --configオプションを使用して、実行中の仮想マシンを再起動せずに設定することもできます。
14.7.8. Kernel Same-Page Merging の有効化と無効化 リンクのコピーリンクがクリップボードにコピーされました!
Kernel Same-Page Merging (KSM) は、仮想マシン (VM) 間で同一のメモリーページを共有することにより、メモリー密度を向上させます。したがって、KSM を有効にすると、仮想マシンデプロイメントのメモリー効率が向上する可能性があります。
ただし、KSM を有効にすると、CPU 使用率も増加し、ワークロードによっては全体的なパフォーマンスに悪影響が生じる可能性があります。
RHEL 9 以降では、KSM はデフォルトで無効になっています。KSM を有効にして仮想マシンパフォーマンスへの影響をテストするには、次の手順を参照してください。
前提条件
- ホストシステムへのルートアクセス。
手順
KSM を有効にします。
警告KSM を有効にすると、CPU 使用率が増大し、CPU 全体のパフォーマンスに影響を及ぼします。
ksmtunedサービスをインストールします。{PackageManagerCommand} install ksmtuned# {PackageManagerCommand} install ksmtunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを起動します。
KSM を単一セッションの間だけ有効にするには、
systemctlユーティリティーを使用してksmおよびksmtunedサービスを開始します。systemctl start ksm systemctl start ksmtuned
# systemctl start ksm # systemctl start ksmtunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow KSM を永続的に有効にするには、
systemctlユーティリティーを使用してksmサービスおよびksmtunedサービスを有効にします。systemctl enable ksm Created symlink /etc/systemd/system/multi-user.target.wants/ksm.service → /usr/lib/systemd/system/ksm.service systemctl enable ksmtuned Created symlink /etc/systemd/system/multi-user.target.wants/ksmtuned.service → /usr/lib/systemd/system/ksmtuned.service
# systemctl enable ksm Created symlink /etc/systemd/system/multi-user.target.wants/ksm.service → /usr/lib/systemd/system/ksm.service # systemctl enable ksmtuned Created symlink /etc/systemd/system/multi-user.target.wants/ksmtuned.service → /usr/lib/systemd/system/ksmtuned.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- ホスト上の仮想マシンのパフォーマンスとリソース消費を監視して、KSM を有効にすることによる利点を評価します。具体的には、KSM による CPU 使用率の増加によってメモリーの改善が相殺されないこと、および別のパフォーマンスの問題が発生しないことを確認します。レイテンシーの影響を受けやすいワークロードでは、NUMA 間のページマージにも注意してください。
オプション: KSM によって仮想マシンのパフォーマンスが向上しない場合は、無効にします。
KSM を単一セッションの間だけ無効にするには、
systemctlユーティリティーを使用してksmおよびksmtunedサービスを停止します。systemctl stop ksm systemctl stop ksmtuned
# systemctl stop ksm # systemctl stop ksmtunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow KSM を永続的に無効にするには、
systemctlユーティリティーを使用してksmおよびksmtunedサービスを無効にします。systemctl disable ksm Removed /etc/systemd/system/multi-user.target.wants/ksm.service. systemctl disable ksmtuned Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.
# systemctl disable ksm Removed /etc/systemd/system/multi-user.target.wants/ksm.service. # systemctl disable ksmtuned Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
KSM を無効にする前に仮想マシン間で共有されていたメモリーページは、そのまま共有されます。共有を停止するには、以下のコマンドを使用して、システムの PageKSM ページをすべて削除します。
echo 2 > /sys/kernel/mm/ksm/run
# echo 2 > /sys/kernel/mm/ksm/run
ただし、このコマンドはメモリー使用量を増加させ、ホストまたは仮想マシンでパフォーマンスの問題を引き起こす可能性があります。
14.8. 仮想マシンのネットワークパフォーマンスの最適化 リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのネットワークインターフェイスコントローラー (NIC) の性質上、仮想マシンは、割り当てられているホストネットワークの帯域幅の一部を失います。これにより、仮想マシンの全体的なワークロード効率が低下することがあります。以下のヒントは、仮想 NIC (vNIC) のスループットで仮想化の影響を最小限に抑えることができます。
手順
以下の方法のいずれかを使用し、仮想マシンのネットワークパフォーマンスにメリットがあるかどうかを調べます。
- vhost_net モジュールの有効化
ホストで
vhost_netカーネル機能が有効になっていることを確認します。lsmod | grep vhost vhost_net 32768 1 vhost 53248 1 vhost_net tap 24576 1 vhost_net tun 57344 6 vhost_net
# lsmod | grep vhost vhost_net 32768 1 vhost 53248 1 vhost_net tap 24576 1 vhost_net tun 57344 6 vhost_netCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドの出力が空白である場合は、
vhost_netカーネルモジュールを有効にします。modprobe vhost_net
# modprobe vhost_netCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- マルチキュー virtio-net の設定
仮想マシンに マルチキュー virtio-net 機能を設定するには、
virsh editコマンドを使用して、仮想マシンの XML 設定を編集します。XML で、以下を<devices>セクションに追加し、Nを、仮想マシンの vCPU 数 (最大 16) に変更します。<interface type='network'> <source network='default'/> <model type='virtio'/> <driver name='vhost' queues='N'/> </interface><interface type='network'> <source network='default'/> <model type='virtio'/> <driver name='vhost' queues='N'/> </interface>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想マシンが実行中の場合は、再起動して変更を適用します。
- ネットワークパケットのバッチ処理
転送パスが長い Linux の仮想マシン設定では、パケットをバッチ処理してからカーネルに送信することで、キャッシュが有効に活用される場合があります。パケットバッチ機能を設定するには、ホストで次のコマンドを実行し、tap0 を、仮想マシンが使用するネットワークインターフェイスの名前に置き換えます。
ethtool -C tap0 rx-frames 64
# ethtool -C tap0 rx-frames 64Copy to Clipboard Copied! Toggle word wrap Toggle overflow - SR-IOV
- ホスト NIC が SR-IOV に対応している場合は、vNIC に SR-IOV デバイス割り当てを使用します。詳細は、SR-IOV デバイスの管理 を参照してください。
14.9. 仮想マシンのパフォーマンス監視ツール リンクのコピーリンクがクリップボードにコピーされました!
最も多くの仮想マシンリソースを消費するものと、仮想マシンで最適化を必要とする部分を認識するために、一般的なパフォーマンス診断ツールや仮想マシン固有のパフォーマンス診断ツールを使用できます。
デフォルトの OS パフォーマンス監視ツール
標準のパフォーマンス評価には、ホストおよびゲストのオペレーティングシステムでデフォルトで提供されるユーティリティーを使用できます。
RHEL 9 ホストで、root として
topユーティリティーまたは システムモニター アプリケーションを使用し、出力結果からqemuとvirtを見つけます。これは、仮想マシンが消費しているホストシステムのリソースのサイズを示します。-
監視ツールにおいて、
qemuプロセスまたはvirtプロセスのいずれかで、ホストの CPU またはメモリーの容量を大幅に消費していることが示されている場合は、perfユーティリティーを使用して調査を行います。詳細は以下を参照してください。 -
また、
vhost_netスレッドプロセス (例: vhost_net-1234) が、ホストの CPU 容量を過剰に消費する際に表示される場合は、multi-queue virtio-netなどの 仮想ネットワークの最適化機能 を使用することを検討してください。
-
監視ツールにおいて、
ゲストオペレーティングシステムでは、システムで利用可能なパフォーマンスユーティリティーとアプリケーションを使用して、どのプロセスが最も多くのシステムリソースを消費するかを評価します。
-
Linux システムでは、
topユーティリティーを使用できます。 - Windows システムでは、Task Manager アプリケーションを使用できます。
-
Linux システムでは、
perf kvm
perf ユーティリティーを使用して、RHEL 9 ホストのパフォーマンスに関する仮想化固有の統計を収集および分析できます。これを行うには、以下を行います。
ホストに、perf パッケージをインストールします。
dnf install perf
# dnf install perfCopy to Clipboard Copied! Toggle word wrap Toggle overflow perf kvm statコマンドの 1 つを使用して、仮想化ホストの perf 統計を表示します。-
お使いのハイパーバイザーのリアルタイム監視には、
perf kvm stat liveコマンドを使用します。 -
一定期間でハイパーバイザーの perf データをログに記録するには、
perf kvm stat recordコマンドを使用してロギングを有効にします。コマンドをキャンセルまたは中断した後、データはperf.data.guestファイルに保存されます。これは、perf kvm stat reportコマンドを使用して分析できます。
-
お使いのハイパーバイザーのリアルタイム監視には、
VM-EXITイベントとそのディストリビューションのタイプについてperf出力を分析します。たとえば、PAUSE_INSTRUCTIONイベントは頻繁に存在すべきではありませんが、以下の出力では、このイベントが頻繁に現れ、ホスト CPU が vCPU を適切に処理していないことを示しています。このようなシナリオでは、アクティブな一部の仮想マシンの電源オフ、その仮想マシンからの vCPU の削除、または vCPU のパフォーマンスの調整 を検討してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow perf kvm statの出力で問題を知らせる他のイベントタイプには、以下が含まれます。-
INSN_EMULATION- 準最適な 仮想マシンの I/O 設定 を示します。
-
perf を使用して仮想化パフォーマンスを監視する方法の詳細は、システム上の perf-kvm man ページを参照してください。
numastat
システムの現在の NUMA 設定を表示するには、numastat ユーティリティーを使用できます。これは numactl パッケージをインストールすることで利用できます。
以下は、4 つの実行中の仮想マシンが含まれるホストを示しています。それぞれは、複数の NUMA ノードからメモリーを取得しています。これは、vCPU のパフォーマンスに対して最適なのではなく、保証調整 です。
一方、以下では、1 つのノードで各仮想マシンに提供されているメモリーを示しています。これは、より一層効率的です。
第15章 電源管理の重要性 リンクのコピーリンクがクリップボードにコピーされました!
コンピューターシステム全体の消費電力を削減することで、コストを削減できます。各システムコンポーネントのエネルギー消費を効果的に最適化するには、システムが実行するさまざまなタスクを検討し、各コンポーネントのパフォーマンスがそのジョブに対して正しいことを確認するように設定します。特定コンポーネントやシステム全体の消費電力を下げると、熱およびパフォーマンスが低下します。
適切な電源管理を行うと、以下のような結果になります
- サーバーやコンピューティングセンターにおける熱の削減
- 冷却、空間、ケーブル、ジェネレーター、無停電電源装置 (UPS) などの二次コストの削減
- ノートパソコンのバッテリー寿命の延長
- 二酸化炭素排出量の削減
- 政府の規制や Green IT (Energy Star など) に関する法的要件に合致する
- 新システムに関する企業ガイドラインの遵守
このセクションでは、Red Hat Enterprise Linux システムの電源管理に関する情報を説明します。
15.1. 電源管理の基本 リンクのコピーリンクがクリップボードにコピーされました!
効果的な電源管理は、以下の原則に基づいて行われます。
An idle CPU should only wake up when neededRed Hat Enterprise Linux 6 以降では、カーネルが
ticklessを実行しています。つまり、以前の定期的なタイマー割り込みが、オンデマンド割り込みに置き換えられたことを意味します。そのため、新しいタスクが処理のキューに追加されるまで、アイドル状態の CPU はアイドル状態を維持できます。低電力状態にある CPU は、この状態を持続できます。ただし、システムに、不要なタイマーイベントを作成するアプリケーションが存在する場合は、この機能の利点が相殺される可能性があります。ボリュームの変更やマウスの動きの確認などのポーリングイベントは、このようなイベントの例です。Red Hat Enterprise Linux には、CPU 使用率に基づいてアプリケーションを識別し、監査するツールが同梱されています。詳細は、Audit and analysis overview および Tools for auditing を参照してください。
Unused hardware and devices should be disabled completely- これは、ハードディスクなど、動作する部品があるデバイスに当てはまります。また、一部のアプリケーションでは、使用されていない有効なデバイスが "open" 状態のままにすることがあります。これが発生すると、カーネルは、そのデバイスが使用中であることを想定します。これにより、そのデバイスが省電力状態にならないようにできます。
Low activity should translate to low wattageただし、多くの場合、これは最新のハードウェアと、x86 以外のアーキテクチャーを含む最新のシステムの正しい BIOS 設定または UEFI に依存します。システムに最新の公式ファームウェアを使用していること、および BIOS の電源管理またはデバイス設定セクションで電源管理機能が有効になっていることを確認してください。以下のような機能を確認してください。
- ARM64 用の CPPC (Collaborative Processor Performance Controls) のサポート
- IBM Power Systems の PowerNV サポート
- SpeedStep
- PowerNow!
- Cool'n'Quiet
- ACPI (C-state)
Smart
ハードウェアでこの機能に対応し、BIOS で有効になっている場合は、Red Hat Enterprise Linux がデフォルトで使用します。
Different forms of CPU states and their effects最新の CPU は、ACPI (Advanced Configuration and Power Interface) とともに、さまざまな電源状態を提供します。3 つの異なる状態は以下のとおりです。
- スリープ (C-state)
- 周波数と電圧 (P-state)
熱の出力 (T-states または thermal state)
最小のスリープ状態で実行している CPU は、最小のワット数を消費しますが、必要に応じてその状態からウェイクアップするのにかかる時間も大幅に長くなります。まれに、スリープ状態に切り替わるたびに CPU が即座にウェイクアップしなければならなくなることがあります。この状況は、実質的に永続的に CPU がビジー状態になり、別の状態を使用すると潜在的な省電力の一部が失われます。
A turned off machine uses the least amount of power- 電力を節約する最善の方法の 1 つは、システムの電源を切ることです。たとえば、会社では、昼休みや帰宅時にマシンをオフにするガイドラインを使用して、"green IT" を意識することに焦点をあてた企業文化を育成できます。また、複数の物理サーバーを 1 つの大きなサーバーに統合し、Red Hat Enterprise Linux に同梱される仮想化技術を使用して仮想化することもできます。
15.2. 監査および分析の概要 リンクのコピーリンクがクリップボードにコピーされました!
通常、1 つのシステムで詳細な手動の監査、分析、およびチューニングを行う場合は例外となります。これは、このようなシステム調整の最後の部分から得られる利点よりも、その実行にかかる時間とコストの方が長いためです。
ただし、すべてのシステムで同じ設定を再利用できるほぼ同一のシステムでこれらのタスクを 1 回実行することは、非常に便利です。たとえば、数千ものデスクトップシステムや、マシンがほぼ同一の HPC クラスターをデプロイメントする場合を考えてください。監査と分析を行うもう 1 つの理由は、将来のシステム動作のリグレッションまたは変更を特定できる比較の基礎を提供することです。この分析の結果は、ハードウェア、BIOS、またはソフトウェアの更新が定期的に行われ、消費電力に関する予期しない事態を回避したい場合に非常に役立ちます。通常、徹底的な監査と分析により、特定システムで実際に起こっていることをより的確に把握できます。
利用可能な最新のシステムを使用しても、消費電力に関するシステムの監査と分析は比較的困難です。ほとんどのシステムは、ソフトウェアを介して電力使用量を測定するために必要な手段を提供していません。ただし、例外があります。
- Hewlett Packard サーバーシステムの iLO 管理コンソールには、Web からアクセスできる電源管理モジュールがあります。
- IBM は、BladeCenter 電源管理モジュールで同様のソリューションを提供します。
- 一部の Dell システムでは、IT Assistant は電力監視機能も提供します。
他のベンダーは、サーバープラットフォームで同様の機能を提供する可能性が高くなりますが、すべてのベンダーで対応している唯一のソリューションは存在しません。多くの場合、消費電力を直接測定する必要があるのは、可能な限り節約を最大化するためだけです。
15.3. 監査用ツール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 8 には、システムの監査および分析を実行できるツールが同梱されています。これらのほとんどは、すでに発見したものを確認したい場合、または特定の部分についてさらに詳細な情報が必要な場合の補助情報源として使用できます。
このツールの多くは、パフォーマンスの調整にも使用されます。以下に例を示します。
PowerTOP-
これは、CPU を頻繁にウェイクアップするカーネルおよびユーザー空間アプリケーションの特定のコンポーネントを識別します。root で
powertopコマンドを使用して PowerTop ツールを起動し、powertop --calibrateで電力見積もりエンジンを調整します。PowerTop の詳細は、PowerTOP を使用した電力消費の管理 を参照してください。 Diskdevstat and netdevstatこれは、システムで実行しているすべてのアプリケーションのディスクアクティビティーとネットワークアクティビティーに関する詳細情報を収集する SystemTap ツールです。これらのツールによって収集された統計を使用すると、少数の大規模な操作ではなく、多くの小規模な I / O 操作で電力を浪費するアプリケーションを特定できます。root で
dnf install tuned-utils-systemtap kernel-debuginfoコマンドを使用し、diskdevstatおよびnetdevstatをインストールします。ディスクとネットワークのアクティビティーの詳細情報を表示するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドでは、
update_interval、total_duration、およびdisplay_histogramの 3 つのパラメーターを指定できます。TuneD-
これは、
udevデバイスマネージャーを使用して、接続されたデバイスを監視し、システム設定の静的チューニングおよび動的チューニングの両方を有効にするプロファイルベースのシステムチューニングツールです。tuned-adm recommendコマンドを使用すると、Red Hat が特定の製品に最も適したプロファイルを判別できます。TuneD の詳細は、TuneD を使い始める および TuneD プロファイルのカスタマイズ を参照してください。powertop2tuned utilityを使用して、PowerTOPの提案からカスタムの TuneD プロファイルを作成できます。powertop2tunedユーティリティーの詳細は、電力消費の最適化 を参照してください。 Virtual memory statistics (vmstat)これは、
procps-ngパッケージにより提供されます。このツールを使用すると、プロセス、メモリー、ページング、ブロック I/O、トラップ、および CPU アクティビティーの詳細情報を表示できます。この情報を表示するには、次を使用します。
vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 5805576 380856 4852848 0 0 119 73 814 640 2 2 96 0 0
$ vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 5805576 380856 4852848 0 0 119 73 814 640 2 2 96 0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow vmstat -aコマンドを使用すると、アクティブメモリーと非アクティブメモリーを表示できます。その他のvmstatオプションの詳細は、システム上のvmstatman ページを参照してください。iostatこのツールは
sysstatパッケージで提供されます。このツールはvmstatと似ていますが、ブロックデバイスの I/O を監視する目的でのみ使用されます。また、より詳細な出力と統計も提供します。システム I/O を監視するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow blktraceこれは、I/O サブシステム内で費やされた時間配分に関する詳細情報を提供します。
この情報を人間が判読できる形式で表示するには、以下のコマンドを実行します。
blktrace -d /dev/dm-0 -o - | blkparse -i - 253,0 1 1 0.000000000 17694 Q W 76423384 + 8 [kworker/u16:1] 253,0 2 1 0.001926913 0 C W 76423384 + 8 [0] [...]
# blktrace -d /dev/dm-0 -o - | blkparse -i - 253,0 1 1 0.000000000 17694 Q W 76423384 + 8 [kworker/u16:1] 253,0 2 1 0.001926913 0 C W 76423384 + 8 [0] [...]Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、最初の列の 253,0 は、デバイスのメジャータプルおよびマイナータプルになります。2 番目の列 (1) には、CPU に関する情報が記載されています。次に、IO プロセスを実行するプロセスのタイムスタンプと PID の列が記載されています。
6 番目の列 Q はイベントタイプを示し、7 番目の列 W は書き込み操作を示し、8 番目の列 76423384 はブロック番号であり、+ 8は要求されたブロックの数になります。
最後のフィールドの [kworker/u16:1] はプロセスの名前です。
初期設定では、プロセスが明示的に強制終了されるまで、
blktraceは永続的に実行されます。-wオプションを使用して、ランタイム期間を指定します。turbostatこれは、
kernel-toolsにより提供されます。x86-64 プロセッサーで、プロセッサーのトポロジー、周波数、アイドル電力状態の統計、温度、および電力使用量を報告します。この概要を表示するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは、
turbostatは、画面全体のカウンター結果の概要を出力し、その後に 5 秒間隔でカウンター結果を出力します。-iオプションでカウンター結果の間隔を指定します。たとえば、turbostat -i 10を実行して、10 秒間隔で結果を出力します。Turbostat は、電力使用率またはアイドル時間に関して非効率的なサーバーを識別するのにも役立ちます。また、発生しているシステム管理割り込み (SMI) の比率を特定する場合にも便利です。また、これを使用して、電源管理の調整の効果を検証することもできます。
cpupowerIT は、プロセッサーの省電力関連機能を検証および調整するツール群です。
frequency-info、frequency-set、idle-info、idle-set、set、info、およびmonitorオプションを指定してcpupowerコマンドを使用し、プロセッサー関連の値を表示および設定します。たとえば、利用可能な cpufreq ガバナーを表示するには、次のコマンドを実行します。
cpupower frequency-info --governors analyzing CPU 0: available cpufreq governors: performance powersave
$ cpupower frequency-info --governors analyzing CPU 0: available cpufreq governors: performance powersaveCopy to Clipboard Copied! Toggle word wrap Toggle overflow cpupowerの詳細は、Viewing CPU related information を参照してください。GNOME Power Manager- これは、GNOME デスクトップ環境にインストールされるデーモンです。GNOME Power Manager は、システムの電源ステータスの変更 (バッテリーから AC 電源への変更など) を通知します。また、バッテリーのステータスを報告し、バッテリー残量が少なくなると警告を表示します。
第16章 PowerTOP を使用した電力消費の管理 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者であれば、PowerTOP ツールを使用して、消費電力を解析および管理できます。
16.1. PowerTOP の目的 リンクのコピーリンクがクリップボードにコピーされました!
PowerTOP は、消費電力に関連する問題を診断し、バッテリーの寿命を延ばす方法に関する提案を示すプログラムです。
PowerTOP ツールは、システムの総電力使用量の想定と、各プロセス、デバイス、カーネルワーカー、タイマー、および割り込みハンドラーの個々の電力使用量の想定を示すことができます。このツールは、CPU を頻繁にウェイクアップするカーネルおよびユーザー空間アプリケーションの特定のコンポーネントを識別することもできます。
Red Hat Enterprise Linux 9 は、PowerTOP のバージョン 2.x を使用します。
16.2. PowerTOP の使用 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
PowerTOP を使用できるようにするには、
powertopパッケージがシステムにインストールされていることを確認してください。dnf install powertop
# dnf install powertopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.2.1. PowerTOP の起動 リンクのコピーリンクがクリップボードにコピーされました!
手順
PowerTOP を実行するには、次のコマンドを使用します。
powertop
# powertopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
powertop コマンドの実行時には、ラップトップはバッテリー電源で動作します。
16.2.2. PowerTOP の調整 リンクのコピーリンクがクリップボードにコピーされました!
手順
ラップトップでは、次のコマンドを実行して電力予測エンジンを調整することができます。
powertop --calibrate
# powertop --calibrateCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロセス中にマシンと対話せずに、調整を終了させます。
プロセスがさまざまなテストを実行し、輝度を切り替え、デバイスのオンとオフを切り替える操作を繰り返すため、調整には時間がかかります。
調整プロセスが完了すると、PowerTOP が通常どおり起動します。データを収集するために約 1 時間実行します。
十分なデータが収集されると、出力テーブルの最初の列に電力予測マークが表示されます。
powertop --calibrate は、ノートパソコンでのみ使用できることに注意してください。
16.2.3. 測定間隔の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、PowerTOP は、20 秒間隔で測定します。
この測定頻度を変更する場合は、以下の手順に従います。
手順
--timeオプションを指定してpowertopコマンドを実行します。powertop --time=time in seconds
# powertop --time=time in secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3. PowerTOP の統計 リンクのコピーリンクがクリップボードにコピーされました!
PowerTOP は、実行中に、システムから統計を収集します。
PowerTOP の出力には、複数のタブがあります。
-
Overview -
idle stats -
Frequency stats -
Device stats -
Tunables -
WakeUp
Tab キーおよび Shift+ Tab キーを使用して、このタブを順番に切り替えることができます。
16.3.1. Overview タブ リンクのコピーリンクがクリップボードにコピーされました!
Overview タブでは、ウェイクアップを最も頻繁に CPU に送信するか、最も電力を消費するコンポーネントのリストを表示できます。プロセス、割り込み、デバイス、その他のリソースなど、Overview タブの項目は、使用率に従って並べ替えられます。
Overview タブで隣接する列は、以下の情報を提供します。
- Usage
- リソース使用の電力想定。
- Events/s
- 1 秒あたりウェイクアップ。1 秒あたりのウェイクアップ数は、サービスまたはデバイス、ならびにカーネルのドライバーがいかに効率的に実行しているかを示します。ウェイクアップが少ないほど、消費電力が少なくなります。コンポーネントは、電力使用率をどの程度まで最適化できるかによって順序付けられます。
- Category
- プロセス、デバイス、タイマーなどのコンポーネントの分類。
- 説明
- コンポーネントの説明。
適切に調整すると、最初の列にリストされているすべての項目に対する電力消費予測も表示されます。
これとは別に、Overview タブには、次のようなサマリー統計の行が含まれます。
- 合計電力消費
- バッテリーの残り寿命 (該当する場合)
- 1 秒あたりの合計ウェイクアップ数、1 秒あたり GPU 操作数、および 1 秒あたりの仮想ファイルシステム操作数の概要
16.3.2. Idle stats タブ リンクのコピーリンクがクリップボードにコピーされました!
Idle stats タブには、すべてのプロセッサーおよびコアに対する C 状態の使用率が表示されます。Frequency stats タブには、(該当する場合は) すべてのプロセッサーおよびコアに対する Turbo モードを含む P 状態の使用率が表示されます。C または P 状態の長さは、CPU 使用率がどの程度最適化されているかを示します。CPU の C 状態または P 状態が高いままになるほど (C4 が C3 よりも高くなるなど)、CPU 使用率がより最適化されます。システムがアイドル状態の時に、最高の C 状態または P 状態の常駐が 90% 以上になることが理想的と言えます。
16.3.3. Device stats タブ リンクのコピーリンクがクリップボードにコピーされました!
Device stats タブは Overview タブと同様の情報を提供しますが、デバイス専用です。
16.3.4. Tunables タブ リンクのコピーリンクがクリップボードにコピーされました!
Tunables タブには、低消費電力にシステムを最適化するための、PowerTOP の推奨事項が含まれます。
up キーおよび down キーを使用して提案を移動し、enter キーを使用して提案をオンまたはオフにします。
16.3.5. WakeUp タブ リンクのコピーリンクがクリップボードにコピーされました!
WakeUp タブには、ユーザーが必要に応じて変更できるデバイスウェイクアップ設定が表示されます。
up キーおよび down キーを使用して利用可能な設定を移動し、enter キーを使用して設定を有効または無効にします。
図16.1 PowerTOP 出力
16.4. Powertop で Frequency stats に値が表示されない場合がある理由 リンクのコピーリンクがクリップボードにコピーされました!
Intel P-State ドライバーを使用している場合、PowerTOP はドライバーがパッシブモードの場合にのみ Frequency Stats タブに値を表示します。しかし、この場合でも、値が不完全な場合があります。
Intel P-State ドライバーには、全部で 3 つのモードがあります。
- ハードウェア P-State(HWP) によるアクティブモード
- HWP なしのアクティブモード
- パッシブモード
ACPI CPUfreq ドライバーに切り替えると、PowerTOP で完全な情報が表示されます。ただし、システムをデフォルト設定にしておくことを推奨します。
どのドライバーがどのようなモードで読み込まれているかを確認するには、次のコマンドを実行します。
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
-
intel_pstateは、Intel P-State ドライバーが読み込まれ、アクティブモードになっている場合に返されます。 -
intel_cpufreqは、インテル P-State ドライバーが読み込まれ、パッシブモードになっている場合に返されます。 -
ACPI CPUfreq ドライバーが読み込まれている場合は、
acpi-cpufreqが返されます。
Intel P-State ドライバーを使用している場合は、カーネルブートコマンドラインに以下の引数を追加して、ドライバーをパッシブモードで実行するようにします。
intel_pstate=passive
intel_pstate=passive
Intel P-State ドライバーを無効にして、代わりに ACPI CPUfreq ドライバーを使用するには、カーネルブートコマンドラインに次の引数を追加します。
intel_pstate=disable
intel_pstate=disable
16.5. HTML 出力の生成 リンクのコピーリンクがクリップボードにコピーされました!
端末の powertop の出力結果以外にも、HTML レポートを生成することもできます。
手順
--htmlオプションを指定してpowertopコマンドを実行します。powertop --html=htmlfile.html
# powertop --html=htmlfile.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow htmlfile.htmlパラメーターを、出力ファイルに必要な名前に置き換えます。
16.6. 電力消費の最適化 リンクのコピーリンクがクリップボードにコピーされました!
電力消費を最適化するには、powertop サービスまたは powertop2tuned ユーティリティーを使用できます。
16.6.1. powertop サービスで消費電力の最適化 リンクのコピーリンクがクリップボードにコピーされました!
powertop サービスを使用すると、システムの起動の Tunables タブから、すべての PowerTOP の提案を自動的に有効にできます。
手順
powertopサービスを有効にします。systemctl enable powertop
# systemctl enable powertopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.6.2. powertop2tuned ユーティリティー リンクのコピーリンクがクリップボードにコピーされました!
powertop2tuned ユーティリティーを使用すると、PowerTOPの提案からカスタムTuneDプロファイルを作成できます。
デフォルトでは、powertop2tuned は、/etc/tuned/ ディレクトリーにプロファイルを作成し、現在選択している TuneD プロファイルを基にしてカスタムプロファイルを作成します。安全上の理由から、すべての PowerTOP チューニングは最初に新しいプロファイルで無効になっています。
チューニングを有効にするには、以下を行います。
-
/etc/tuned/profile_name/tuned.confファイルでコメントを解除します。 --enableオプションまたは-eオプションを使用して、PowerTOP により提案されたチューニングのほとんどを可能にする新しいプロファイルを生成します。USB 自動サスペンドなど、既知の問題のある特定のチューニングはデフォルトで無効になっているため、手動でコメントを解除する必要があります。
16.6.3. powertop2tuned ユーティリティーで電力消費の最適化 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
powertop2tunedユーティリティーがシステムにインストールされている場合は、次のコマンドを実行します。dnf install tuned-utils
# dnf install tuned-utilsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
カスタムプロファイルを作成するには、次のコマンドを使用します。
powertop2tuned new_profile_name
# powertop2tuned new_profile_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいプロファイルをアクティベートします。
tuned-adm profile new_profile_name
# tuned-adm profile new_profile_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
powertop2tunedに対応しているオプションの完全リストを表示するには、以下を使用します。powertop2tuned --help
$ powertop2tuned --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.6.4. powertop.service と powertop2tuned の比較 リンクのコピーリンクがクリップボードにコピーされました!
以下の理由により、powertop2tuned を使用した電力消費の最適化は、powertop.service よりも推奨されます。
-
powertop2tunedユーティリティーは、PowerTOP を TuneD に統合したものです。これにより、両方のツールの利点を活かすことができます。 -
powertop2tunedユーティリティーを使用すると、有効になっているチューニングをきめ細かく制御できます。 -
powertop2tunedを使用すると、潜在的に危険なチューニングは自動的に有効になりません。 -
powertop2tunedを使用すると、再起動せずにロールバックを行うことができます。
第17章 perf の使用 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、perf ツールを使用して、システムのパフォーマンスデータを収集および分析できます。
17.1. perf の概要 リンクのコピーリンクがクリップボードにコピーされました!
perf ユーザー空間ツールは、カーネルベースのサブシステム Performance Counters for Linux (PCL) とインターフェイスします。perf は、PMU (Performance Monitoring Unit) を使用してさまざまなハードウェアおよびソフトウェアイベントを測定、記録、監視する強力なツールです。perf は tracepoint、kprobes、および uprobes にも対応しています。
17.2. perf のインストール リンクのコピーリンクがクリップボードにコピーされました!
この手順では、perf ユーザー空間ツールをインストールします。
手順
perfツールをインストールします。dnf install perf
# dnf install perfCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3. 一般的な perf コマンド リンクのコピーリンクがクリップボードにコピーされました!
perf stat- このコマンドは、実行された命令や消費したクロックサイクルなど、一般的なパフォーマンスイベントに関する全体的な統計を提供します。オプションを指定すると、デフォルトの測定イベント以外のイベントを選択できます。
perf record-
このコマンドは、パフォーマンスデータをファイル
perf.dataに記録します。このファイルは後でperf reportコマンドを使用して分析できます。 perf report-
このコマンドは、
perf recordで作成されたperf.dataファイルからパフォーマンスデータを読み取り、表示します。 perf list- このコマンドは、特定のマシンで利用可能なイベントをリスト表示します。これらのイベントは、パフォーマンス監視ハードウェアや、システムのソフトウェア設定によって異なります。
perf top-
このコマンドは、
topユーティリティーと同様の機能を実行します。リアルタイムでパフォーマンスカウンタープロファイルを生成および表示します。 perf trace-
このコマンドは、
straceツールと同様の機能を実行します。指定されたスレッドまたはプロセスによって使用されるシステムコールとそのアプリケーションが受信するすべてのシグナルを監視します。 perf help-
このコマンドは、
perfコマンドのリストを表示します。
第18章 perf top を使用した、リアルタイムでの CPU 使用率のプロファイリング リンクのコピーリンクがクリップボードにコピーされました!
perf top コマンドを使用して、さまざまな機能の CPU 使用率をリアルタイムで測定できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
18.1. perf top の目的 リンクのコピーリンクがクリップボードにコピーされました!
perf top コマンドは、top ユーティリティーと同様に、リアルタイムシステムのプロファイリングおよび機能に使用されます。ただし、top ユーティリティーは、通常、指定のプロセスまたはスレッドが使用している CPU 時間を示しており、perf top は各関数が使用する CPU 時間を表示します。デフォルトの状態では、perf top はユーザー空間とカーネル空間のすべての CPU で使用される関数を通知します。perf top を使用するには、root アクセスが必要です。
18.2. perf top を使用した CPU 使用率のプロファイリング リンクのコピーリンクがクリップボードにコピーされました!
この手順では、perf top をアクティブにし、CPU 使用率をリアルタイムでプロファイルします。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 - root アクセスがある。
手順
perf topモニタリングインターフェイスを起動します。perf top
# perf topCopy to Clipboard Copied! Toggle word wrap Toggle overflow 監視インターフェイスは、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、カーネル機能の
do_syscall_64が最も多くの CPU 時間を使用しています。
18.3. perf top 出力の解釈 リンクのコピーリンクがクリップボードにコピーされました!
perf top 監視インターフェイスでは、データが以下のようなさまざまな列で表示されます。
- "Overhead" 列
- 指定された関数が使用している CPU のパーセントを表示します。
- "Shared Object" 列
- 機能を使用しているプログラムまたはライブラリー名を表示します。
- "Symbol" 列
-
関数名またはシンボルを表示します。カーネル空間で実行される関数は
[k]によって識別され、ユーザースペースで実行される関数は[.]によって識別されます。
18.4. perf が一部の関数名を raw 関数アドレスとして表示する理由 リンクのコピーリンクがクリップボードにコピーされました!
カーネル関数の場合は、perf が /proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数は、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。
実行ファイルの debuginfo パッケージがインストールされているか、実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。
実行ファイルに関連付けられた debuginfo をインストールした後に、perf record コマンドを再実行する必要はありません。単に perf report を再実行してください。
18.5. デバッグおよびソースのリポジトリーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。
手順
ソースおよびデバッグの情報パッケージチャンネルを有効にします。
subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-debug-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-source-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-debug-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-source-rpms
# subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-debug-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-source-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-debug-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-source-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow $(uname -i)の部分は、システムのアーキテクチャーで一致する値に自動的に置き換えられます。Expand アーキテクチャー名 値 64 ビット Intel および AMD
x86_64
64 ビット ARM
aarch64
IBM POWER
ppc64le
64 ビット IBM Z
s390x
18.6. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得 リンクのコピーリンクがクリップボードにコピーされました!
デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。
前提条件
- デバッグするアプリケーションまたはライブラリーがシステムにインストールされている。
-
GDB と
debuginfo-installツールがシステムにインストールされている。詳細は、アプリケーションをデバッグするための設定 を参照してください。 -
debuginfoおよびdebugsourceパッケージを提供するリポジトリーを設定し、システムで有効にしている。詳細は、デバッグおよびソースリポジトリーの有効化 を参照してください。
手順
デバッグするアプリケーションまたはライブラリーに割り当てられた GDB を起動します。GDB は、足りないデバッグ情報を自動的に認識し、実行するコマンドを提案します。
gdb -q /bin/ls Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64 (gdb)
$ gdb -q /bin/ls Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64 (gdb)Copy to Clipboard Copied! Toggle word wrap Toggle overflow GDB を終了します。q と入力して、Enter で確認します。
(gdb) q
(gdb) qCopy to Clipboard Copied! Toggle word wrap Toggle overflow GDB が提案するコマンドを実行して、必要な
debuginfoパッケージをインストールします。dnf debuginfo-install coreutils-8.30-6.el8.x86_64
# dnf debuginfo-install coreutils-8.30-6.el8.x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow dnfパッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。-
GDB が
debuginfoパッケージを提案できない場合は、手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得 で説明されている手順に従います。
第19章 perf stat を使用したプロセス実行中のイベントのカウント リンクのコピーリンクがクリップボードにコピーされました!
perf stat コマンドを使用すると、プロセスの実行中にハードウェアおよびソフトウェアのイベントをカウントできます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
19.1. perf stat の目的 リンクのコピーリンクがクリップボードにコピーされました!
perf stat コマンドは指定されたコマンドを実行し、コマンドの実行中にハードウェアおよびソフトウェアのイベントの発生回数を維持し、これらのカウントの統計を生成します。イベントを指定しないと、perf stat は共通のハードウェアおよびソフトウェアのイベントセットをカウントします。
19.2. perf stat を使用したイベントのカウント リンクのコピーリンクがクリップボードにコピーされました!
perf stat を使用すると、コマンドの実行中に発生したハードウェアおよびソフトウェアのイベントをカウントし、これらのカウントの統計を生成できます。デフォルトでは、perf stat はスレッドごとのモードで動作します。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
イベントをカウントします。
root アクセスなしで
perf statコマンドを実行すると、ユーザー空間で発生したイベントのみをカウントします。perf stat ls
$ perf stat lsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例19.1 perf stat の出力が root アクセスなしで実行
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以前の例で分かるように、
perf statを root アクセスなしで実行すると、イベント名の後に:uが付けられ、これらのイベントがユーザー空間でのみカウントされていることが分かります。ユーザー空間およびカーネルスペースの両方のイベントをカウントするには、
perf statの実行時に root アクセスが必要になります。perf stat ls
# perf stat lsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例19.2 root アクセスで実行された perf stat の出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトでは、
perf statはスレッドごとのモードで動作します。CPU 全体のイベントカウントに変更するには、-aオプションをperf statに渡します。CPU 全体のイベントをカウントするには、root アクセスが必要です。perf stat -a ls
# perf stat -a lsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3. perf stat 出力の解釈 リンクのコピーリンクがクリップボードにコピーされました!
perf stat は指定されたコマンドを実行し、コマンドの実行中にイベントの発生をカウントし、これらのカウントの統計を 3 列で表示します。
- 指定されたイベントでカウントされた発生数
- カウントされたイベントの名前。
関連するメトリックが利用可能な場合、右側のコラムのハッシュ記号 (
#) の後に比率またはパーセンテージが表示されます。たとえば、デフォルトモードで実行している場合、
perf statはサイクルと命令の両方をカウントします。したがって、右端のコラムのサイクルごとの命令を計算して表示します。デフォルトでは両方のイベントがカウントされるため、分岐ミスに関して同様の動作がすべてのブランチのパーセントとして表示されます。
19.4. 実行中のプロセスに perf stat を割り当てる リンクのコピーリンクがクリップボードにコピーされました!
perf stat を実行中のプロセスに割り当てることができます。これにより、コマンドの実行中に、指定したプロセスでのみ発生するイベントをカウントするように perf stat に指示します。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
perf statを実行中のプロセスに割り当てます。perf stat -p ID1,ID2 sleep seconds
$ perf stat -p ID1,ID2 sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 前の例では、ID が
ID1andID2のプロセス内のイベントを、sleepコマンドで指定したsecondsの秒数だけカウントします。
第20章 perf によるパフォーマンスプロファイルの記録および分析 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用すると、パフォーマンスデータを記録し、後で分析することができます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
20.1. perf record の目的 リンクのコピーリンクがクリップボードにコピーされました!
perf record コマンドはパフォーマンスデータのサンプルを収集し、perf.data ファイルに保存して、他の perf コマンドで読み込み、視覚化できるようにします。perf.data は現在のディレクトリーに生成され、後で別のマシンからアクセスできます。
perf record を記録するコマンドを指定しないと、Ctrl+C を押して手動でプロセスを停止するまで記録されます。-p オプションに続いてプロセス ID を 1 つ以上渡すと、perf record を特定のプロセスに割り当てることができます。root アクセスなしで perf record レコードを実行できますが、実行するとユーザー領域のパフォーマンスデータのサンプルのみとなります。デフォルトモードでは、perf record レコードは CPU サイクルをサンプルイベントとして使用し、継承モードが有効な状態でスレッドごとのモードで動作します。
20.2. root アクセスなしのパフォーマンスプロファイルの記録 リンクのコピーリンクがクリップボードにコピーされました!
root アクセスなしで perf record を使用すると、ユーザー空間のみのパフォーマンスデータのサンプリングおよび記録を行うことができます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
パフォーマンスデータのサンプルと記録:
perf record command
$ perf record commandCopy to Clipboard Copied! Toggle word wrap Toggle overflow commandを、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまでperf recordがデータのサンプリングを行います。
20.3. root アクセスによるパフォーマンスプロファイルの記録 リンクのコピーリンクがクリップボードにコピーされました!
root アクセスで perf record を使用して、ユーザー空間とカーネル空間の両方でパフォーマンスデータをサンプリングおよび記録できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 - root アクセスがある。
手順
パフォーマンスデータのサンプルと記録:
perf record command
# perf record commandCopy to Clipboard Copied! Toggle word wrap Toggle overflow commandを、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまでperf recordがデータのサンプリングを行います。
20.4. CPU ごとのモードでのパフォーマンスプロファイルの記録 リンクのコピーリンクがクリップボードにコピーされました!
CPU ごとのモードで perf record を使用すると、監視対象の CPU のすべてのスレッドにわたって、ユーザー空間とカーネル空間の両方で同時にパフォーマンスデータをサンプリングして記録できます。デフォルトでは、CPU ごとのモードはすべてのオンライン CPU を監視します。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
パフォーマンスデータのサンプルと記録:
perf record -a command
# perf record -a commandCopy to Clipboard Copied! Toggle word wrap Toggle overflow commandを、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまでperf recordがデータのサンプリングを行います。
20.5. perf レコードで呼び出し先のデータを取得する リンクのコピーリンクがクリップボードにコピーされました!
perf record ツールを設定して、どの関数がパフォーマンスプロファイル内の他の関数を呼び出しているかを記録することができます。これは、複数のプロセスが同じ関数を呼び出す場合にボトルネックを特定するのに役立ちます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
--call-graphオプションを使用して、パフォーマンスデータのサンプルと記録を行います。perf record --call-graph method command
$ perf record --call-graph method commandCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
commandを、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまでperf recordがデータのサンプリングを行います。 method を、以下のアンワインドメソッドのいずれかに置き換えます。
fp-
フレームポインターメソッドを使用します。GCC オプション
--fomit-frame-pointerでビルドされたバイナリーの場合など、コンパイラーの最適化により、スタックをアンワインドできない可能性があります。 dwarf- DWARF 呼び出し情報を使用してスタックのアンワインドを行います。
lbr- Intel プロセッサーで最後のブランチレコードハードウェアを使用します。
-
20.6. perf レポートを使用した perf.data の分析 リンクのコピーリンクがクリップボードにコピーされました!
perf report を使用して perf.data ファイルを表示し、分析できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
現行ディレクトリーに
perf.dataファイルがある。 -
perf.dataファイルが root アクセスで作成された場合は、root アクセスでperf reportを実行する必要もあります。
手順
詳細な分析のために
perf.dataファイルの内容を表示します。perf report
# perf reportCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、以下のような出力を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.7. perf report 出力の解釈 リンクのコピーリンクがクリップボードにコピーされました!
perf report コマンドを実行して表示されるテーブルは、データを複数のコラムに分類します。
- 'Overhead' 列
- その特定の関数で収集されたサンプル全体の割合を示します。
- 'Command' 列
- サンプルが収集されたプロセスを通知します。
- 'Shared Object' 列
- サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからのものである場合に [kernel.kallsyms] という名前が使用されます)。
- 'Symbol' 列
- 関数名またはシンボルを表示します。
デフォルトモードでは、関数は、オーバーヘッドの最も高いものが最初に表示される順に降順でソートされます。
20.8. 別のデバイスで読み取り可能な perf.data ファイルの生成 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用してパフォーマンスデータを perf.data ファイルに記録し、異なるデバイスで分析することができます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
カーネル
debuginfoパッケージがインストールされている。詳細は GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得 を参照してください。
手順
さらに調査する予定のパフォーマンスデータを取得します。
perf record -a --call-graph fp sleep seconds
# perf record -a --call-graph fp sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
sleepコマンドの使用によって指定される秒数でシステム全体のperf.dataを生成します。また、フレームポインターの方法を使用して呼び出しグラフデータを取得します。記録されたデータのデバッグシンボルを含むアーカイブファイルを生成します。
perf archive
# perf archiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
アーカイブファイルが現在のアクティブなディレクトリーで生成されたことを確認します。
ls perf.data*
# ls perf.data*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、
perf.dataで始まる現在のディレクトリーのすべてのファイルが表示されます。アーカイブファイルの名前は以下のいずれかになります。perf.data.tar.gz
perf.data.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow または
perf.data.tar.bz2
perf.data.tar.bz2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.9. 別のデバイスで作成された perf.data ファイルの分析 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用して、別のデバイスで生成された perf.data ファイルを分析することができます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
使用中の現在のデバイスに、別のデバイスで生成された
perf.dataファイルと関連アーカイブファイルが存在する。
手順
-
perf.dataファイルとアーカイブファイルの両方を現在のアクティブなディレクトリーにコピーします。 アーカイブファイルを
~/.debugにデプロイメントします。mkdir -p ~/.debug tar xf perf.data.tar.bz2 -C ~/.debug
# mkdir -p ~/.debug # tar xf perf.data.tar.bz2 -C ~/.debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記アーカイブファイルの名前は
perf.data.tar.gzでも構いません。perf.dataファイルを開いて詳細な分析を行います。perf report
# perf reportCopy to Clipboard Copied! Toggle word wrap Toggle overflow
20.10. perf が一部の関数名を raw 関数アドレスとして表示する理由 リンクのコピーリンクがクリップボードにコピーされました!
カーネル関数の場合は、perf が /proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数は、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。
実行ファイルの debuginfo パッケージがインストールされているか、実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。
実行ファイルに関連付けられた debuginfo をインストールした後に、perf record コマンドを再実行する必要はありません。単に perf report を再実行してください。
20.11. デバッグおよびソースのリポジトリーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。
手順
ソースおよびデバッグの情報パッケージチャンネルを有効にします。
subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-debug-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-source-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-debug-rpms subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-source-rpms
# subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-debug-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-baseos-source-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-debug-rpms # subscription-manager repos --enable rhel-9-for-$(uname -i)-appstream-source-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow $(uname -i)の部分は、システムのアーキテクチャーで一致する値に自動的に置き換えられます。Expand アーキテクチャー名 値 64 ビット Intel および AMD
x86_64
64 ビット ARM
aarch64
IBM POWER
ppc64le
64 ビット IBM Z
s390x
20.12. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得 リンクのコピーリンクがクリップボードにコピーされました!
デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。
前提条件
- デバッグするアプリケーションまたはライブラリーがシステムにインストールされている。
-
GDB と
debuginfo-installツールがシステムにインストールされている。詳細は、アプリケーションをデバッグするための設定 を参照してください。 -
debuginfoおよびdebugsourceパッケージを提供するリポジトリーを設定し、システムで有効にしている。詳細は、デバッグおよびソースリポジトリーの有効化 を参照してください。
手順
デバッグするアプリケーションまたはライブラリーに割り当てられた GDB を起動します。GDB は、足りないデバッグ情報を自動的に認識し、実行するコマンドを提案します。
gdb -q /bin/ls Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64 (gdb)
$ gdb -q /bin/ls Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64 (gdb)Copy to Clipboard Copied! Toggle word wrap Toggle overflow GDB を終了します。q と入力して、Enter で確認します。
(gdb) q
(gdb) qCopy to Clipboard Copied! Toggle word wrap Toggle overflow GDB が提案するコマンドを実行して、必要な
debuginfoパッケージをインストールします。dnf debuginfo-install coreutils-8.30-6.el8.x86_64
# dnf debuginfo-install coreutils-8.30-6.el8.x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow dnfパッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。-
GDB が
debuginfoパッケージを提案できない場合は、手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得 で説明されている手順に従います。
第21章 perf を使用したビジーな CPU の調査 リンクのコピーリンクがクリップボードにコピーされました!
システムでパフォーマンスの問題を調査する際には、perf ツールを使用して最もビジー状態の CPU を特定し、監視することで、作業に集中することができます。
21.1. perf stat でカウントされた CPU イベントの表示 リンクのコピーリンクがクリップボードにコピーされました!
perf stat を使用すると、CPU カウントアグリゲーションを無効にすることで、どの CPU イベントがカウントされたかを表示できます。この機能を使用するには、-a フラグを使用してシステム全体のモードでイベントをカウントする必要があります。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
CPU カウントアグリゲーションが無効になっているイベントをカウントします。
perf stat -a -A sleep seconds
# perf stat -a -A sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
CPU0以降の各 CPU に対してsleepコマンドを使用し、一定時間 (秒単位) に記録された一般的なハードウェアおよびソフトウェアイベントのデフォルトセット数が表示されます。そのため、cycle などのイベントを指定すると便利です。perf stat -a -A -e cycles sleep seconds
# perf stat -a -A -e cycles sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.2. perf レポートを使用して実行した CPU サンプルの表示 リンクのコピーリンクがクリップボードにコピーされました!
perf record コマンドはパフォーマンスデータをサンプルし、このデータを perf.data ファイルに保存します。このファイルは perf report コマンドで読み取ることができます。perf record コマンドは、どの CPU サンプルが発生したかを常に記録します。perf report を設定して、この情報を表示することができます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
現行ディレクトリーに
perf recordでperf.dataファイルが作成されている。perf.dataファイルが root アクセスで作成された場合は、root アクセスでperf reportを実行する必要もあります。
手順
CPU でソートしながら、詳細な分析のために
perf.dataファイルの内容を表示します。perf report --sort cpu
# perf report --sort cpuCopy to Clipboard Copied! Toggle word wrap Toggle overflow CPU およびコマンドでソートすると、CPU 時間が費やされている場所に関する詳細情報を表示できます。
perf report --sort cpu,comm
# perf report --sort cpu,commCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、すべての監視 CPU からのコマンドを、オーバーヘッド使用量の降順で合計オーバーヘッドでリスト表示し、コマンドが実行された CPU を特定します。
21.3. perf top を使用したプロファイリング中の特定の CPU の表示 リンクのコピーリンクがクリップボードにコピーされました!
perf top を設定して、システムのリアルタイムプロファイリング中に特定の CPU および相対使用率を表示できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
CPU でソートしながら
perf topインターフェイスを起動します。perf top --sort cpu
# perf top --sort cpuCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、CPU とその各オーバーヘッドを、オーバーヘッド使用量の降順にリアルタイムでリスト表示します。
CPU およびコマンドでソートして、CPU 時間が費やされている場所の詳細を確認できます。
perf top --sort cpu,comm
# perf top --sort cpu,commCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、オーバーヘッド使用量の降順で合計オーバーヘッドでコマンドをリスト表示し、そのコマンドがリアルタイムに実行された CPU を特定します。
21.4. perf レコードと perf レポートを使用した特定 CPU の監視 リンクのコピーリンクがクリップボードにコピーされました!
perf record は、対象の特定の CPU のみのサンプルを設定し、詳細な分析のために perf report で生成された perf.data ファイルを分析できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
perf.dataファイルを生成して、特定の CPU のパフォーマンスデータをサンプルし、記録します。CPU のコンマ区切りリストを使用します。
perf record -C 0,1 sleep seconds
# perf record -C 0,1 sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例は、
sleepコマンドの使用によって決定される秒数で CPU 0 と 1 にデータをサンプルし、記録します。さまざまな CPU を使用:
perf record -C 0-2 sleep seconds
# perf record -C 0-2 sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例は、
sleepコマンドの使用によって決定される秒数で、CPU 0 から 2 までのすべての CPU にデータをサンプルし、記録します。
詳細な分析のために
perf.dataファイルの内容を表示します。perf report
# perf reportCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
perf.dataの内容を表示します。複数の CPU を監視しており、どの CPU データがサンプリングされたかを把握する場合は、Displaying which CPU samples were taken on with perf report を参照してください。
第22章 perf でアプリケーションパフォーマンスの監視 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用して、アプリケーションのパフォーマンスを監視および分析できます。
22.1. 実行中のプロセスに perf レコードを割り当てる リンクのコピーリンクがクリップボードにコピーされました!
実行中のプロセスに perf レコード をアタッチできます。これにより、perf record が、指定されたプロセスでパフォーマンスデータのサンプルデータと記録のみを行うように指示されます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
実行中のプロセスに
perf レコードをアタッチします。perf record -p ID1,ID2 sleep seconds
$ perf record -p ID1,ID2 sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、
sleepコマンドを使用して、プロセス ID のID1とID2のプロセスのパフォーマンスデータを秒数でサンプルし、記録します。perfを設定して、イベントを特定のスレッドに記録することもできます。perf record -t ID1,ID2 sleep seconds
$ perf record -t ID1,ID2 sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記-tフラグを使用し、スレッド ID をログに記録する場合、perfはデフォルトで継承を無効にします。--inheritオプションを追加して継承を有効にできます。
22.2. perf レコードで呼び出し先のデータを取得する リンクのコピーリンクがクリップボードにコピーされました!
perf record ツールを設定して、どの関数がパフォーマンスプロファイル内の他の関数を呼び出しているかを記録することができます。これは、複数のプロセスが同じ関数を呼び出す場合にボトルネックを特定するのに役立ちます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
--call-graphオプションを使用して、パフォーマンスデータのサンプルと記録を行います。perf record --call-graph method command
$ perf record --call-graph method commandCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
commandを、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまでperf recordがデータのサンプリングを行います。 method を、以下のアンワインドメソッドのいずれかに置き換えます。
fp-
フレームポインターメソッドを使用します。GCC オプション
--fomit-frame-pointerでビルドされたバイナリーの場合など、コンパイラーの最適化により、スタックをアンワインドできない可能性があります。 dwarf- DWARF 呼び出し情報を使用してスタックのアンワインドを行います。
lbr- Intel プロセッサーで最後のブランチレコードハードウェアを使用します。
-
22.3. perf レポートを使用した perf.data の分析 リンクのコピーリンクがクリップボードにコピーされました!
perf report を使用して perf.data ファイルを表示し、分析できます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
現行ディレクトリーに
perf.dataファイルがある。 -
perf.dataファイルが root アクセスで作成された場合は、root アクセスでperf reportを実行する必要もあります。
手順
詳細な分析のために
perf.dataファイルの内容を表示します。perf report
# perf reportCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、以下のような出力を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第23章 perf を使用した uprobe の作成 リンクのコピーリンクがクリップボードにコピーされました!
23.1. perf を使用した関数レベルでのプローブの作成 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用すると、プロセスまたはアプリケーション内の任意の点に動的なトレースポイントを作成できます。その後、このトレースポイントを perf stat や perf record などの他の perf ツールと併用すると、プロセスやアプリケーションの動作をよりよく理解できるようになります。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
プロセスまたはアプリケーション内の対象の場所で、監視対象のプロセスまたはアプリケーションに uprobe を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.2. perf を使用した関数内の行でのアップローブの作成 リンクのコピーリンクがクリップボードにコピーされました!
その後、このトレースポイントを perf stat や perf record などの他の perf ツールと併用すると、プロセスやアプリケーションの動作をよりよく理解できるようになります。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 実行ファイルのデバッグシンボルを取得している。
objdump -t ./your_executable | head
# objdump -t ./your_executable | headCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記これを行うには、実行ファイルの
debuginfoパッケージをインストールする必要があります。または、実行ファイルがローカルで開発したアプリケーションの場合は、デバッグ情報 (GCC の-gオプション) を使用してアプリケーションをコンパイルする必要があります。
手順
プローブを配置できる関数行を表示します。
perf probe -x ./your_executable -L main
$ perf probe -x ./your_executable -L mainCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドの出力は、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 目的の関数行の uprobe を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.3. uprobe に記録されたデータのスクリプト出力を実行する リンクのコピーリンクがクリップボードにコピーされました!
uprobe を使用して収集したデータを分析する一般的な方法は、perf script コマンドを使用して perf.data ファイルを読み込み、記録されたワークロードの詳細なトレースを表示することです。
perf スクリプトの出力例では、以下のようになります。
- my_progと呼ばれるプログラムの関数 isprime() に uprobe が追加されます。
- a は、uprobe に追加された関数引数です。または、a を、uprobe を追加するコードスコープで表示される任意の変数にすることもできます。
第24章 perf mem によるメモリーアクセスのプロファイリング リンクのコピーリンクがクリップボードにコピーされました!
perf mem コマンドを使用して、システム上でメモリーアクセスのサンプリングを行うことができます。
24.1. perf mem の目的 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールの mem サブコマンドは、メモリーアクセスのサンプリング (読み込みおよ格納) を可能にします。perf mem コマンドは、メモリーのレイテンシーに関する情報、メモリーアクセスの種類、キャッシュヒットおよびミスを引き起こした機能、データシンボルの記録、これらのヒットおよびミスが発生するメモリーの場所に関する情報を提供します。
24.2. perf mem によるメモリーアクセスのサンプリング リンクのコピーリンクがクリップボードにコピーされました!
この手順では、perf mem コマンドを使用して、システム上でメモリーアクセスのサンプリングを行う方法を説明します。このコマンドは、perf record および perf report と同じオプションと、mem サブコマンドに制限される一部のオプションをすべて取ります。記録されたデータは、後で分析するために、現在のディレクトリーの perf.data ファイルに保存されます。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
メモリーアクセスの例:
perf mem record -a sleep seconds
# perf mem record -a sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
sleepコマンドで指示されるように、秒単位の期間にわたる、すべての CPU でのメモリーアクセスを例に挙げています。sleepコマンドは、メモリーアクセスデータをサンプルしたいコマンドに置き換えることができます。デフォルトでは、perf memは、メモリーロードおよびストアの両方をサンプルします。-tオプションを使用して、perf memとrecord間に "load" または "store" のいずれかを指定します。ロードすると、メモリー階層レベルに関する情報、TLB メモリーアクセス、バススヌーピング、およびメモリーロックがキャプチャーされます。分析用に
perf.dataファイルを開きます。perf mem report
# perf mem reportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンド例を使用すると、以下のような出力になります。
Available samples 35k cpu/mem-loads,ldlat=30/P 54k cpu/mem-stores/P
Available samples 35k cpu/mem-loads,ldlat=30/P 54k cpu/mem-stores/PCopy to Clipboard Copied! Toggle word wrap Toggle overflow cpu/mem-loads,ldlat=30/Pの行は、メモリーロードで収集されるデータを示し、cpu/mem-stores/Pの行はメモリーストアで収集されるデータを示します。対象のカテゴリーを強調表示し、Enter を押してデータを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow データを表示するときに、結果をソートして、対象の異なる側面を調査できます。たとえば、サンプリング期間中に発生したメモリーアクセスの種類ごとに、主な原因となるオーバーヘッドの降順で、メモリー負荷でデータを分類するには、以下を行います。
perf mem -t load report --sort=mem
# perf mem -t load report --sort=memCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下のような出力になります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
24.3. perf mem 出力の解釈 リンクのコピーリンクがクリップボードにコピーされました!
修飾子なしで perf mem report コマンドを実行すると表示される表では、データが複数の列に分類されます。
- 'Overhead' 列
- その特定の機能で収集された全体のサンプルのパーセンテージを示します。
- 'Samples' 列
- その行でアカウントを指定したサンプル数を表示します。
- 'Local Weight' 列
- プロセッサーのコアサイクルでアクセスレイテンシーを表示します。
- 'Memory Access' 列
- 発生したメモリーアクセスのタイプを表示します。
- 'Symbol' 列
- 関数名またはシンボルを表示します。
- 'Shared Object' 列
- サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからのものである場合に [kernel.kallsyms] という名前が使用されます)。
- 'Data Symbol' 列
- 行がターゲットとしていたメモリーの場所のアドレスを表示します。
多くの場合、アクセスされるメモリーまたはスタックメモリーの動的割り当てにより、'Data Symbol' の列は raw アドレスを表示します。
- "Snoop" 列
- バストランザクションを表示します。
- 'TLB Access' 列
- TLB メモリーアクセスを表示します。
- 'Locked' 列
- 関数がメモリーがロックされたか否かを示します。
デフォルトモードでは、関数は、オーバーヘッドの最も高いものが最初に表示される順に降順でソートされます。
第25章 偽共有の検出 リンクのコピーリンクがクリップボードにコピーされました!
偽共有は、対称型マルチプロセッシング (SMP) システムのプロセッサーコアが、プロセッサー間で共有されていない他のデータアイテムにアクセスするために、他のプロセッサーによって使用されている同じキャッシュラインのデータアイテムを変更すると発生します。
この初期修正では、キャッシュラインを使用する他のプロセッサーがコピーを無効にし、変更されたデータアイテムの更新バージョンをプロセッサーが必要としないにもかかわらず、または必然的にアクセスできる場合でも、更新されたコピーを要求する必要があります。
perf c2c コマンドを使用して、偽共有を検出できます。
25.1. perf c2c の目的 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールの c2c サブコマンドは、Shared Data Cache-to-Cache (C2C) 分析を有効にします。perf c2c コマンドを使用して、キャッシュライン競合を検査し、true と false の両方の共有を検出できます。
キャッシュラインの競合は、対称型マルチプロセッシング (SMP) システムのプロセッサーコアが、他のプロセッサーによって使用されている同じキャッシュラインにあるデータオブジェクトを修正すると発生します。このキャッシュラインを使用する他のプロセッサーはすべて、コピーを無効にして更新されたものを要求します。これにより、パフォーマンスが低下する可能性があります。
perf c2c コマンドは、以下の情報を提供します。
- 競合が検出されたキャッシュライン
- データの読み取りおよび書き込みのプロセス
- 競合の原因となった命令
- 競合に関連する NUMA (Non-Uniform Memory Access) ノード
25.2. perf c2c でキャッシュライン競合の検出 リンクのコピーリンクがクリップボードにコピーされました!
perf c2c コマンドを使用して、システム内のキャッシュライン競合を検出します。
perf c2c コマンドは、perf record と同じオプションと、c2c サブコマンドに排他的なオプションに対応します。記録されたデータは、後で分析するために、現在のディレクトリーの perf.data ファイルに保存されます。
前提条件
-
perfユーザー空間ツールがインストールされている。詳細は perf のインストール を参照してください。
手順
perf c2cを使用してキャッシュラインの競合を検出します。perf c2c record -a sleep seconds
# perf c2c record -a sleep secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
sleepコマンドによって指示される期間 (seconds) に対し、すべての CPU でキャッシュライン競合データをサンプルおよび記録します。sleepコマンドは、キャッシュライン競合データを収集するコマンドに置き換えることができます。
25.3. perf c2c レコードで記録された perf.data ファイルの可視化 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、perf c2c コマンドを使用して記録された perf.data ファイルを視覚化する方法を説明します。
前提条件
-
perfユーザー空間ツールがインストールされている。詳細は perf のインストール を参照してください。 -
perf c2cコマンドを使用して記録されたperf.dataファイルは、現在のディレクトリーで利用できます。詳細は、perf c2c でキャッシュライン競合の検出 を参照してください。
手順
perf.dataファイルを開いて詳細な分析を行います。perf c2c report --stdio
# perf c2c report --stdioCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、
perf.dataファイルを端末内の複数のグラフに可視化します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
25.4. perf c2c 出力の解釈 リンクのコピーリンクがクリップボードにコピーされました!
perf c2c report --stdio コマンドを実行して表示される視覚化は、データを複数のテーブルに分類します。
Trace Events Information-
この表は、
perf c2c recordコマンドで収集された負荷およびストアサンプルの大まかな概要を示しています。 Global Shared Cache Line Event Information- この表は、共有キャッシュラインに関する統計を提供します。
c2c Details-
この表は、サンプルされたイベントと、
perf c2c reportデータを視覚化で編成する方法の情報を提供します。 Shared Data Cache Line Table- この表は、デフォルトでキャッシュラインごとに検出されるリモート Hitm の量によって、偽共有が検出され、降順に並び替えられるホットテストキャッシュラインの 1 行の概要を提供します。
Shared Cache Line Distribution Pareto以下の表には、競合が発生している各キャッシュラインに関するさまざまな情報が記載されています。
-
キャッシュラインは NUM 列で番号
0から始まる番号です。 - 各キャッシュラインの仮想アドレスは Data address Offset の列に含まれます。また、その後に異なるアクセスが発生したキャッシュラインにオフセットが続きます。
- Pid 列にはプロセス ID が含まれます。
- Code Address 列には、インストラクションポインターコードアドレスが含まれます。
- cycles ラベル下の列には、平均負荷のレイテンシーが表示されます。
- cpu cnt 列には、生成された CPU の各種サンプルの数を表示します (特定の場所でインデックス化したデータを待つさまざまな CPU の数)。
- Symbol 列には関数名またはシンボルが表示されます。
-
Shared Object 列は、サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからの場合は [
kernel.kallsyms] という名前が使用されます)。 - Source:Line 列には、ソースファイルと行番号が表示されます。
- Node{cpu list} 列には、各ノードに対して、どの特定の CPU サンプルが生成されたかが表示されます。
-
キャッシュラインは NUM 列で番号
25.5. perf c2c を使用した偽共有の検出 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、perf c2c コマンドを使用して偽共有を検出する方法を説明します。
前提条件
-
perfユーザー空間ツールがインストールされている。詳細は perf のインストール を参照してください。 -
perf c2cコマンドを使用して記録されたperf.dataファイルは、現在のディレクトリーで利用できます。詳細は、perf c2c でキャッシュライン競合の検出 を参照してください。
手順
perf.dataファイルを開いて詳細な分析を行います。perf c2c report --stdio
# perf c2c report --stdioCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、端末で
perf.dataファイルが開きます。"Trace Event Information" テーブルで、LLC Misses to Remote Cache (HITM)の値が含まれる行を見つけます。
LLC Misses to Remote Cache (HITM) の行の値コラムの割合は、変更したキャッシュラインの NUMA ノード全体で発生していた LLC ミスの割合を表し、偽共有が発生したことを示す主要な指標です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Shared Data Cache Line Table の LLC Load Hitm フィールドの Rmt 列を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この表は、キャッシュ行ごとに検出されるリモート Hitm の量によって降順で並び替えられます。LLC Load Hitm セクションの Rmt 列の数値が大きい場合は、偽共有を示しており、偽共有アクティビティーをデバッグするには、それが発生したキャッシュラインをさらに検査する必要があります。
第26章 flamegraphs の使用 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、flamegraphs を使用して、perf ツールで記録されたシステムパフォーマンスデータの視覚化を作成できます。ソフトウェア開発者は、flamegraphs を使用して、perf ツールで記録されたアプリケーションパフォーマンスデータの視覚化を作成できます。
スタックトレースのサンプリングは、perf ツールを使用して CPU パフォーマンスをプロファイリングするための一般的な方法です。ただし、perf を使用したプロファイリングスタックトレースの結果は、極めて詳細にわたるので、分析の工数がかなりかかる可能性があります。flamegraphs は、perf で記録されたデータから作成された視覚化で、より早く、簡単にホットコードパスを特定できるようにします。
26.1. flamegraphs のインストール リンクのコピーリンクがクリップボードにコピーされました!
flamegraphs の使用を開始するには、必要なパッケージをインストールします。
手順
flamegraphsパッケージをインストールします。dnf install js-d3-flame-graph
# dnf install js-d3-flame-graphCopy to Clipboard Copied! Toggle word wrap Toggle overflow
26.2. システム全体でのフレームグラフの作成 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、flamegraphs を使用して、システム全体で記録されたパフォーマンスデータを視覚化する方法を説明します。
前提条件
-
flamegraphsが、flamegraphs のインストール の説明どおりにインストールされている。 -
perfツールが perf のインストール の説明どおりにインストールされている。
手順
データを記録し、視覚化を作成します。
perf script flamegraph -a -F 99 sleep 60
# perf script flamegraph -a -F 99 sleep 60Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、
sleepコマンドを使用して調整されるように、60 秒にわたりシステム全体でパフォーマンスデータをサンプルおよび記録し、現在のアクティブなディレクトリーにflamegraph.htmlとして保存される視覚化を構築します。このコマンドは、デフォルトで呼び出しグラフデータをサンプルし、perfツールと同じ引数を取ります。この例では、以下のようになります。-a- システム全体でデータを記録するように調整します。
-F- 1 秒あたりのサンプリング頻度を設定します。
検証
分析するには、生成された視覚化を表示します。
xdg-open flamegraph.html
# xdg-open flamegraph.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、デフォルトのブラウザーで視覚化が開きます。
26.3. 特定プロセスにおけるフレームグラフの作成 リンクのコピーリンクがクリップボードにコピーされました!
flamegraphs を使用して、特定の実行中のプロセスで記録されたパフォーマンスデータを視覚化できます。
前提条件
-
flamegraphsが、flamegraphs のインストール の説明どおりにインストールされている。 -
perfツールが perf のインストール の説明どおりにインストールされている。
手順
データを記録し、視覚化を作成します。
perf script flamegraph -a -F 99 -p ID1,ID2 sleep 60
# perf script flamegraph -a -F 99 -p ID1,ID2 sleep 60Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、
sleepコマンドの使用で規定されているようにプロセス ID がID1およびID2のプロセスのパフォーマンスデータを 60 秒間にわたりサンプルして記録します。次に、flamegraph.htmlとして現在のアクティブディレクトリーに保存される視覚化を構築します。このコマンドは、デフォルトで呼び出しグラフデータをサンプルし、perfツールと同じ引数を取ります。この例では、以下のようになります。-a- システム全体でデータを記録するように調整します。
-F- 1 秒あたりのサンプリング頻度を設定します。
-p- 特定のプロセス ID をシュミュレートし、データをサンプリングして記録します。
検証
分析するには、生成された視覚化を表示します。
xdg-open flamegraph.html
# xdg-open flamegraph.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、デフォルトのブラウザーで視覚化が開きます。
26.4. flamegraphs の解釈 リンクのコピーリンクがクリップボードにコピーされました!
フレームグラフの各ボックスは、スタック内の異なる関数を示しています。スタックの深さは、x 軸で示されています。CPU でサンプルされた実際の関数は、最も上のボックスで、その他下のものは、その上位となります。X 軸は、サンプルの呼び出しグラフデータの近接性を表示します。
特定の行のスタックの子は、x 軸に沿って降順でそれぞれの関数から取得されたサンプルの数に基づいて表示されます。x 軸は時間の経過を表すものではありません。ボックスが広いほど、データがサンプリングされていたときに、CPU 上または CPU 上の一部での頻度が高いことを意味します。
手順
以前表示されていない可能性のある関数の名前を確認するには、フレームグラフ内のボックスをクリックしてその特定の場所のスタックに拡大します。
- フレームグラフのデフォルトビューに戻るには、 をクリックします。
ユーザー空間関数を表すボックスには、関数のバイナリーが取り除かれているため、flamegraphs で Unknown とラベルが付けられる場合があります。実行可能ファイルの debuginfo パッケージがインストールされているか、実行可能ファイルがローカルで開発したアプリケーションである場合は、アプリケーションはデバッグ情報と共にコンパイルされる必要があります。GCC で -g オプションを使用して、このような状況で関数名またはシンボルを表示します。
第27章 perf circular バッファーを使用したパフォーマンスのボトルネックの監視 リンクのコピーリンクがクリップボードにコピーされました!
システムで実行されている特定のプロセスまたはアプリケーションの一部のパフォーマンスのボトルネックを監視するために、perf ツールを使用してデータのイベント固有のスナップショットを取得する循環バッファーを作成できます。このような場合には、perf は、指定されたイベントが検出されると、後で分析するために perf.data ファイルにデータのみを書き込みます。
27.1. perf を使用した循環バッファーおよびイベント固有のスナップショット リンクのコピーリンクがクリップボードにコピーされました!
perf を使用してプロセスまたはアプリケーションでパフォーマンスの問題を調査する場合、特定の対象イベントが発生する前の数時間のデータを記録することは、簡単ではない、または適切ではない場合があります。このような場合は、perf record を使用して、特定のイベントの後にスナップショットを取得するカスタムの循環バッファーを作成できます。
--overwrite オプションを使用すると、perf record は上書き可能な循環バッファーにすべてのデータを保存します。バッファーがいっぱいになると、perf record が最も古いレコードを自動的に上書きするため、perf.data ファイルに書き込まれることはありません。
--overwrite および --switch-output-event オプションを併用すると、--switch-output-event トリガーイベントを検出するまで、データを継続的に記録およびダンプする循環バッファーが設定されます。トリガーイベントは、ユーザーが関心のある何かが発生したので、循環バッファー内のデータを perf.data ファイルに書き込むように perf record に通知します。これにより、関心のある特定のデータが収集されると同時に、perf.data ファイルに不要なデータを書き込まないことで、実行中の perf プロセスのオーバーヘッドが削減されます。
27.2. perf 循環バッファーを使用したパフォーマンスのボトルネックを監視するための特定のデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
perf ツールを使用すると、関心のあるデータのみを収集するために指定したイベントによってトリガーされる循環バッファーを作成できます。イベント固有のデータを収集する循環バッファーを作成するには、perf に --overwrite および --switch-output-event オプションを使用します。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 プロセスまたはアプリケーション内の関心のある場所に、監視したいプロセスまたはアプリケーションに uprobe を配置している。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
トリガーイベントとして uprobe を使用して循環バッファーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、実行可能ファイルを開始し、
-eオプションの後に指定された CPU サイクルを、perfが--switch-output-eventオプションの後に指定されたトリガーイベントである uprobe を検出するまで収集します。この時点で、perfは循環バッファーにあるすべてのデータのスナップショットを取得し、タイムスタンプで識別される一意のperf.dataファイルに保存します。この例では、合計 2 つのスナップショットが生成され、最後のperf.dataファイルは Ctrl+c を押すことによって強制されました。
第28章 perf を停止または再起動せずに、実行中の perf コレクターからトレースポイントを追加および削除する リンクのコピーリンクがクリップボードにコピーされました!
コントロールパイプインターフェイスを使用して、実行中の perf コレクターで異なるトレースポイントを有効化および無効化することで、perf を停止または再起動せずに、収集するデータを動的に調整できます。これにより、プロセスの停止または再起動中に記録されたはずのパフォーマンスデータが失われることはありません。
28.1. perf を停止または再起動せずに、実行中の perf コレクターにトレースポイントを追加する リンクのコピーリンクがクリップボードにコピーされました!
コントロールパイプインターフェイスを使用して実行中の perf コレクターにトレースポイントを追加し、perf を停止してパフォーマンスデータを損失することなく録画中のデータを調整します。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。
手順
制御パイプインターフェイスを設定します。
mkfifo control ack perf.pipe
# mkfifo control ack perf.pipeCopy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールファイル設定と、有効にするイベントで
perf recordを実行します。perf record --control=fifo:control,ack -D -1 --no-buffering -e 'sched:*' -o - > perf.pipe
# perf record --control=fifo:control,ack -D -1 --no-buffering -e 'sched:*' -o - > perf.pipeCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
-eオプションの後に'sched:*'を宣言すると、スケジューラーイベントでperf recordが開始されます。2 つ目の端末で、制御パイプの読み取り側を起動します。
cat perf.pipe | perf --no-pager script -i -
# cat perf.pipe | perf --no-pager script -i -Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールパイプの読み取り側を起動すると、最初の端末で以下のメッセージがトリガーされます。
Events disabled
Events disabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow 3 つ目の端末で、制御ファイルを使用してトレースポイントを有効にします。
echo 'enable sched:sched_process_fork' > control
# echo 'enable sched:sched_process_fork' > controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは
perfをトリガーし、宣言されたイベントについて制御ファイル内の現在のイベントリストをスキャンします。イベントが存在する場合は、トレースポイントが有効になり、次のメッセージが最初の端末に表示されます。event sched:sched_process_fork enabled
event sched:sched_process_fork enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow トレースポイントを有効にすると、2 つ目の端末は、トレースポイントを検出した
perfの出力を表示します。bash 33349 [034] 149587.674295: sched:sched_process_fork: comm=bash pid=33349 child_comm=bash child_pid=34056
bash 33349 [034] 149587.674295: sched:sched_process_fork: comm=bash pid=33349 child_comm=bash child_pid=34056Copy to Clipboard Copied! Toggle word wrap Toggle overflow
28.2. perf を停止または再起動せずに、実行中の perf コレクターからトレースポイントを削除する リンクのコピーリンクがクリップボードにコピーされました!
制御パイプインターフェイスを使用して、実行中の perf コレクターからトレースポイントを削除し、perf を停止してパフォーマンスデータを失うことなく収集するデータの範囲を減らします。
前提条件
-
perf のインストール で説明されているように、
perfユーザー領域ツールがインストールされている。 -
制御パイプインターフェイスを介して、トレースポイントを実行中の
perfコレクターに追加している。詳細は、perf を停止または再起動せずに、実行中の perf コレクターにトレースポイントを追加する を参照してください。
手順
トレースポイントを削除します。
echo 'disable sched:sched_process_fork' > control
# echo 'disable sched:sched_process_fork' > controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この例では、以前にスケジューラーイベントをコントロールファイルに読み込み、トレースポイント
sched:sched_process_forkを有効にしていることを前提としています。このコマンドは
perfをトリガーし、宣言されたイベントについて制御ファイル内の現在のイベントリストをスキャンします。イベントが存在する場合は、トレースポイントが無効になり、制御パイプの設定に使用する端末に以下のメッセージが表示されます。event sched:sched_process_fork disabled
event sched:sched_process_fork disabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第29章 numastat を使用したメモリー割り当てのプロファイリング リンクのコピーリンクがクリップボードにコピーされました!
numastat ツールを使用すると、システムのメモリー割り当てに関する統計を表示できます。
numastat ツールは、各 NUMA ノードのデータを個別に表示します。この情報を使用して、システムのメモリーパフォーマンスや、システムのさまざまなメモリーポリシーの効果を調査できます。
29.1. デフォルトの numastat 統計 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、numastat ツールは、各 NUMA ノードの以下のカテゴリーに対する統計を表示します。
numa_hit- このノードに正常に割り当てられていたページ数。
numa_miss-
対象のノードのメモリーが少ないために、このノードに割り当てたページ数。それぞれの
numa_missイベントには、別のノードで対応するnuma_foreignイベントがあります。 numa_foreign-
代わりに別のノードに割り当てられたこのノードについて最初に意図されたページ数です。それぞれの
numa_foreignイベントには、対応するnuma_missイベントが別のノードにあります。 interleave_hit- このノードに正常に割り当てられるインターリーブポリシーページの数。
local_node- このノードのプロセスで、このノードで正常に割り当てられるページ数。
other_node- 別のノードのプロセスでこのノードに割り当てられるページ数。
高い numa_hit の値と低い numa_miss の値 (互いに相対的) は、最適なパフォーマンスを示します。
29.2. numastat を使用したメモリー割り当ての表示 リンクのコピーリンクがクリップボードにコピーされました!
numastat ツールを使用してシステムのメモリー割り当てを表示できます。
前提条件
numactlパッケージをインストールする。dnf install numactl
# dnf install numactlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
システムのメモリー割り当てを表示する。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第30章 CPU 使用率を最適化するためのオペレーティングシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
ワークロード全体で CPU 使用率を最適化するように、オペレーティングシステムを設定できます。
30.1. プロセッサーの問題を監視および診断するためのツール リンクのコピーリンクがクリップボードにコピーされました!
以下は、プロセッサー関連のパフォーマンス問題を監視および診断するために Red Hat Enterprise Linux 9 で利用可能なツールです。
-
turbostatツールは、指定した間隔でカウンターの結果を出力し、過剰な電力使用量、ディープスリープ状態に入れない、システム管理割り込み (SMI) が不必要に作成されるなど、サーバーでの予期しない動作を特定するのに役立ちます。 -
numactlユーティリティーはプロセッサーとメモリー親和性を管理する数多くのオプションを提供します。numactlパッケージには、カーネルがサポートする NUMA ポリシーに簡単なプログラミングインターフェイスを提供するlibnumaライブラリーが含まれており、numactlアプリケーションよりも詳細なチューニングに使用できます。 -
numastatツールは、オペレーティングシステムおよびそのプロセスについて NUMA ノードごとのメモリー統計を表示し、プロセスのメモリーがシステム全体に分散されているか、特定のノードで集中化されているかを表示します。このツールは、numactlパッケージで提供されます。 -
numadは NUMA アフィニティーの自動管理デーモンです。NUMA リソースの割り当てと管理を動的に改善するために、システム内の NUMA トポロジーとリソースの使用状況を監視します。 -
/proc/interruptsファイルには割り込み要求 (IRQ) 番号、システムの各プロセッサーによって処理される同様の割り込み要求の数、送信される割り込みのタイプ、およびリスト表示される割り込み要求に応答するデバイスのコンマ区切りのリストが表示されます。 pqosユーティリティーはintel-cmt-catパッケージで利用できます。最新の Intel プロセッサーで CPU キャッシュとメモリー帯域幅を監視します。以下を監視します。- サイクルごとの命令 (IPC)。
- 最終レベルのキャッシュ MISSES の数。
- LLC で特定の CPU で実行されるプログラムのサイズ (キロバイト単位)。
- ローカルメモリーへの帯域幅 (MBL)。
- リモートメモリー (MBR) への帯域幅。
-
X86_energy_perf_policyツールを使用すると、パフォーマンスと電力消費効率の相対的な重要性を定義できます。この情報は、パフォーマンスと電力消費効率の間でトレードオフするオプションを選択すると、この機能をサポートするプロセッサーに影響を与えるために使用できます。 -
tasksetツールは、util-linuxパッケージで提供されます。これにより、管理者は実行中のプロセスのプロセッサー親和性を取得および設定したり、指定されたプロセッサー親和性でプロセスを起動したりできます。
30.2. システムトポロジーの種類 リンクのコピーリンクがクリップボードにコピーされました!
現代のコンピューティングでは、ほとんどの最近のシステムに複数のプロセッサーがあるため、CPU の意図は誤解を招くものです。システムのトポロジーは、これらのプロセッサー同士が、他のシステムリソースに接続する方法です。これにより、システムおよびアプリケーションのパフォーマンスに影響を及ぼし、システムのチューニングの考慮事項が影響を受ける可能性があります。
現代のコンピューティングで使用されるトポロジーの主なタイプを以下に示します。
SMP (Symmetric Multi-Processor) トポロジー- SMP トポロジーにより、すべてのプロセッサーが同時にメモリーにアクセスできるようになります。ただし、共有および同等のメモリーアクセスは、本質的にすべての CPU からのメモリーアクセスをシリアライズするため、SMP システムのスケーリング制約が一般的に許容できないものとして表示されます。このため、最近のサーバーシステムはすべて NUMA マシンです。
NUMA (Non-Uniform Memory Access) の固定 (ピニング)NUMA トポロジーは、SMP トポロジーよりも最近開発されました。NUMA システムでは、複数のプロセッサーが 1 つのソケット上で物理的にグループ化されます。各ソケットには、そのメモリーへのローカルアクセスを持つメモリーとプロセッサーの専用領域があります。これらは、すべてノードと呼ばれます。同じノード上のプロセッサーは、そのノードのメモリーバンクに高速でアクセスでき、ノード上にないメモリーバンクへの低速アクセスを提供します。
そのため、ローカル以外のメモリーにアクセスするとパフォーマンスが低下します。したがって、NUMA トポロジーを使用するシステム上のパフォーマンスに敏感なアプリケーションは、アプリケーションを実行するプロセッサーと同じノードにあるメモリーにアクセスする必要があり、可能な限りリモートメモリーにアクセスしないようにしてください。
パフォーマンスに敏感するマルチスレッドアプリケーションは、特定のプロセッサーではなく特定の NUMA ノードで実行されるように設定することで、メリットが得られます。これが適切なかどうかは、システムやアプリケーションの要件によって異なります。複数のアプリケーションスレッドが同じキャッシュされたデータにアクセスする場合、同じプロセッサーでこれらのスレッドを実行するように設定することが適切な場合があります。ただし、異なるデータにアクセスし、キャッシュする複数のスレッドが同じプロセッサーで実行される場合、各スレッドは、以前のスレッドによってアクセスされたキャッシュデータをエビクトする可能性があります。これは、各スレッドがキャッシュを '失い'、メモリーからデータをフェッチし、これをキャッシュで置き換えていることを意味します。
perfツールを使用して、過剰な数のキャッシュミスをチェックします。
30.2.1. システムトポロジーの表示 リンクのコピーリンクがクリップボードにコピーされました!
システムのトポロジーを理解するのに便利なコマンドは複数あります。この手順では、システムトポロジーを確認する方法を説明します。
手順
システムトポロジーの概要を表示するには、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CPU 数、スレッド数、コア数、ソケット数、NUMA ノード数などの CPU アーキテクチャーに関する情報を収集するには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システムのグラフィカル表現を表示するには、以下のコマンドを実行します。
dnf install hwloc-gui lstopo
# dnf install hwloc-gui # lstopoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 図30.1
lstopoの出力詳細なテキスト出力を表示するには、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
30.3. カーネルティック時間の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Enterprise Linux 9 はティックレスカーネルを使用します。これは、電力使用量を低減し、新しいプロセッサーがディープスリープ状態を利用できるようにするために、アイドル状態の CPU を中断しません。
Red Hat Enterprise Linux 9 には動的ティックレスオプションもあります。これは、高パフォーマンスコンピューティングやリアルタイムのコンピューティングなどのレイテンシーに制約のあるワークロードに役立ちます。デフォルトでは、動的ティックレスオプションは無効になっています。Red Hat は、cpu-partitioning TuneD プロファイルを使用して、isolated_cores で指定されたコアの動的な tickless オプションを有効にすることを推奨します。
この手順では、動的なティックレス動作を永続的に有効にする方法を説明します。
手順
特定のコアで動的なティックレス動作を有効にするには、
nohz_fullパラメーターを使用して、カーネルコマンドラインでこれらのコアを指定します。16 コアシステムでは、nohz_full=1-15カーネルオプションを有効にします。grubby --update-kernel=ALL --args="nohz_full=1-15"
# grubby --update-kernel=ALL --args="nohz_full=1-15"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、コア
1から15までの動的なティックレス動作が有効になり、すべての時間管理が未指定のコアのみに移動します (コア0)。システムが起動したら、
rcuスレッドをレイテンシーを区別しないコア (この場合は core0) に手動で移動します。for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; done
# for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: カーネルコマンドラインで
isolcpusパラメーターを使用して、特定のコアをユーザー空間タスクから分離します。 オプション: カーネルの
write-back bdi-flushスレッドの CPU 親和性をハウスキーピングコアに設定します。echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
echo 1 > /sys/bus/workqueue/devices/writeback/cpumaskCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
システムを再起動したら、
dynticksが有効になっていることを確認します。journalctl -xe | grep dynticks Mar 15 18:34:54 rhel-server kernel: NO_HZ: Full dynticks CPUs: 1-15.
# journalctl -xe | grep dynticks Mar 15 18:34:54 rhel-server kernel: NO_HZ: Full dynticks CPUs: 1-15.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 動的ティックレス設定が正しく機能していることを確認します。
perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、CPU 1 に 3 秒間スリープするように指示しながら、CPU 1 のティックを測定します。
デフォルトのカーネルタイマーの設定では、通常の CPU で 3100 ティックが表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 動的ティックレスカーネルを設定すると、代わりに 4 ティックが表示されるはずです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
30.4. 割り込み要求の概要 リンクのコピーリンクがクリップボードにコピーされました!
割り込み要求または IRQ は、ハードウェアの一部からプロセッサーに直ちに送信されるシグナルです。システム内の各デバイスには、固有の割り込みを送信できる IRQ 番号が割り当てられます。割り込みが有効になっていると、割り込み要求を受信するプロセッサーは割り込み要求に対応するために現在のアプリケーションスレッドの実行を即時に一時停止します。
割り込みは通常の動作を停止するため、割り込み率が高くなると、システムのパフォーマンスが大幅に低下する可能性があります。割り込みの親和性を設定するか、優先度の低い割り込みをバッチ (複数の割り込みをまとめる) に送信することで、割り込みにかかる時間を低減することができます。
割り込み要求には関連するアフィニティープロパティー smp_affinity があり、割り込み要求を処理するプロセッサーを定義します。アプリケーションのパフォーマンスを向上させるには、割り込みの親和性とプロセスの親和性を同じプロセッサーまたは同じコアにあるプロセッサーに割り当てます。これにより、指定された割り込みとアプリケーションスレッドがキャッシュラインを共有できるようになります。
割り込みステアリングに対応するシステムでは、割り込み要求の smp_affinity プロパティーを変更するとハードウェアが設定され、カーネルを介入することなくハードウェアレベルで特定のプロセッサーに割り込みを処理させる決定が行われるようになります。
30.4.1. 割り込みの手動分散 リンクのコピーリンクがクリップボードにコピーされました!
BIOS が NUMA トポロジーをエクスポートする場合、irqbalance サービスは、サービスを要求するハードウェアに対してローカルとなるノードで割り込み要求を自動的に処理できます。
手順
- 設定する割り込み要求に対応するデバイスを確認します。
プラットフォームのハードウェア仕様を見つけます。システムのチップセットが割り込みの分散に対応しているかどうかを確認します。
- その場合には、以下の手順に従って割り込み配信を設定できます。また、チップセットが割り込みの分散に使用するアルゴリズムを確認してください。BIOS によっては割り込み配信を設定するオプションがあります。
- そうでない場合は、チップセットは常にすべての割り込みを単一の静的 CPU にルーティングします。使用される CPU を設定することはできません。
システムでどの Advanced Programmable Interrupt Controller (APIC) モードが使用されているかを確認します。
journalctl --dmesg | grep APIC
$ journalctl --dmesg | grep APICCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
システムが
flat以外のモードを使用している場合は、APIC ルーティングの物理フラットへの設定と同様の行が表示されます。 このようなメッセージが表示されない場合は、システムが
flatモードを使用します。システムで
x2apicモードを使用している場合は、bootloader設定のカーネルコマンドラインにnox2apicオプションを追加して無効にできます。物理以外のフラットモード (
flat) のみが、複数の CPU への割り込みの分散をサポートします。このモードは、CPU が最大8のシステムでのみ利用できます。
-
システムが
-
smp_affinity マスクを計算します。smp_affinity maskの計算方法は、smp_affinity マスクの設定 を参照してください。
30.4.2. smp_affinity マスクの設定 リンクのコピーリンクがクリップボードにコピーされました!
smp_affinity の値は、システム内のすべてのプロセッサーを表す 16 進数のビットマスクとして保存されます。各ビットは異なる CPU を設定します。最も大きなビットは CPU 0 です。
マスクのデフォルト値は f で、割り込み要求をシステム内のどのプロセッサーでも処理できることを意味します。この値を 1 に設定すると、プロセッサー 0 のみが割り込みを処理できます。
手順
バイナリーでは、割り込みを処理する CPU に 1 の値を使用します。たとえば、割り込みを処理する CPU 0 と CPU 7 を設定するには、バイナリーコードに
0000000010000001を使用します。Expand 表30.1 CPU のバイナリービット CPU
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
バイナリー
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
バイナリーコードを 16 進数に変換します。
たとえば、Python を使用してバイナリーコードを変換するには、次のコマンドを実行します。
>>> hex(int('0000000010000001', 2)) '0x81'>>> hex(int('0000000010000001', 2)) '0x81'Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセッサーが 32 個を超えるシステムでは、32 ビットグループごとに
smp_affinity値を区切る必要があります。たとえば、64 プロセッサーシステムの最初の 32 プロセッサーのみが割り込み要求を処理できるようにするには、0xffffffff,00000000を使用します。特定の割り込み要求の割り込み親和性の値は、関連付けられた
/proc/irq/irq_number/smp_affinityファイルに保存されます。このファイルでsmp_affinityマスクを設定します。echo mask > /proc/irq/irq_number/smp_affinity
# echo mask > /proc/irq/irq_number/smp_affinityCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第31章 スケジューリングポリシーの調整 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux では、プロセス実行の最小単位はスレッドと呼ばれます。システムスケジューラーは、スレッドを実行するプロセッサーと、スレッドの実行期間を決定します。ただし、スケジューラーの主な懸念はシステムをビジーに維持することであるため、アプリケーションのパフォーマンスに対してスレッドを最適にスケジュールしない場合があります。
たとえば、NUMA システムのアプリケーションがノード A で実行され、ノード B のプロセッサーが利用可能になるとします。プロセッサーをノード B でビジー状態に維持するために、スケジューラーはアプリケーションのスレッドのいずれかをノード B に移動します。ただし、アプリケーションスレッドは依然としてノード A のメモリーにアクセスする必要があります。ただし、スレッドがノード B で実行され、ノード A のメモリーがスレッドに対してローカルにならないため、このメモリーへのアクセスには時間がかかります。そのため、スレッドがノード B での実行を終了するには、ノード A のプロセッサーが利用可能になるまで待機してから、ローカルメモリーアクセスで元のノードでスレッドを実行するよりも時間がかかる場合があります。
31.1. スケジューリングポリシーの分類 リンクのコピーリンクがクリップボードにコピーされました!
パフォーマンス重視のアプリケーションには、多くの場合、スレッドが実行される場所を決定する手段や管理者の恩恵を受けることができます。Linux スケジューラーは、スレッドの実行場所と実行期間を決定する複数のスケジューリングポリシーを実装します。
以下は、スケジューリングポリシーの主なカテゴリーです。
Normal policies- 通常スレッドは、通常の優先度のタスクに使用されます。
Realtime policiesリアルタイムポリシーは、中断なしで完了する必要のある時間的制約のあるタスクに使用されます。リアルタイムスレッドは、タイムスライスの対象ではありません。つまり、スレッドは、ブロック、終了、デプロイメント、または優先度の高いスレッドによってプリエンプションされるまで実行されます。
最も優先度の低いリアルタイムスレッドは、通常のポリシーを持つスレッドの前にスケジュールされます。詳細は、SCHED_FIFO を使用した静的優先度のスケジューリング および SCHED_RR を使用したラウンドロビン方式の優先度スケジューリング をご覧ください。
31.2. SCHED_FIFO を使用した静的優先度スケジューリング リンクのコピーリンクがクリップボードにコピーされました!
SCHED_FIFO は静的優先度スケジューリングとも呼ばれ、各スレッドに固定の優先度を定義するリアルタイムポリシーです。このポリシーにより、管理者はイベントの応答時間を改善し、レイテンシーを短縮できます。このポリシーは、時間的制約のあるタスクについて長期間実行しないようにすることが推奨されます。
SCHED_FIFO が使用されている場合、スケジューラーは SCHED_FIFO の全スレッドのリストを優先度順にスキャンし、実行準備ができているスレッドを最も優先度の高いものとしてスケジュールします。SCHED_FIFO スレッドの優先度レベルは、1 から 99 までの任意の整数にすることができます。ここで、99 は最も高い優先度として処理されます。Red Hat は、レイテンシーの問題を特定する場合にのみ、数値を減らし、優先度を増加させることを推奨します。
リアルタイムスレッドはタイムスライスの影響を受けないため、Red Hat は優先度を 99 に設定しないことを推奨します。これにより、プロセスは移行およびウォッチドッグスレッドと同じ優先レベルを維持します。スレッドが演算ループに入り、これらのスレッドがブロックされると、実行できなくなります。単一のプロセッサーを持つシステムは、この状況では最終的にハングします。
管理者は、SCHED_FIFO 帯域幅を制限し、リアルタイムのアプリケーションプログラマーがプロセッサーを単調にするリアルタイムのタスクを開始できないようにすることができます。
以下は、このポリシーで使用されるパラメーターの一部です。
/proc/sys/kernel/sched_rt_period_us-
このパラメーターは、プロセッサー帯域幅の 100 パーセントとみなされる期間 (マイクロ秒単位) を定義します。デフォルト値は
1000000 μs(1 秒) です。 /proc/sys/kernel/sched_rt_runtime_us-
このパラメーターは、リアルタイムスレッドを実行する時間 (マイクロ秒単位) を定義します。デフォルト値は
950000 μs(0.95 秒) です。
31.3. SCHED_RR を使用したラウンドロビン優先度スケジューリング リンクのコピーリンクがクリップボードにコピーされました!
SCHED_RR は、SCHED_FIFO のラウンドロビン型です。このポリシーは、複数のスレッドを同じ優先レベルで実行する必要がある場合に役に立ちます。
SCHED_FIFO と同様に、SCHED_RR は、各スレッドに固定の優先度を定義するリアルタイムポリシーです。スケジューラーは、すべての SCHED_RR スレッドのリストを優先度順にスキャンし、実行準備ができているスレッドを最も優先度の高いものとしてスケジュールします。ただし、SCHED_FIFO とは異なり、優先順位が同じスレッドは、特定のタイムスライス内のラウンドロビンスタイルでスケジュールされます。
このタイムスライスの値は、/proc/sys/kernel/sched_rr_timeslice_ms ファイルの sched_rr_timeslice_ms カーネルパラメーターでミリ秒単位で設定できます。最小値は 1 millisecond です。
31.4. SCHED_OTHER を使用した通常のスケジューリング リンクのコピーリンクがクリップボードにコピーされました!
SCHED_OTHER は、Red Hat Enterprise Linux 9 のデフォルトスケジューリングポリシーです。このポリシーは Completely Fair Scheduler (CFS) を使用して、このポリシーでスケジュールされているすべてのスレッドへの公平プロセッサーアクセスを許可します。このポリシーは、スレッドが多数ある場合や、データスループットの優先度が優先される場合に最も便利です。これは、時間とともにスレッドをより効率的にスケジュールできるためです。
このポリシーが使用されると、スケジューラーは各プロセススレッドの niceness 値に基づいて動的な優先順位リストを作成します。管理者はプロセスの niceness 値を変更できますが、スケジューラーの動的優先順位のリストを直接変更することはできません。
31.5. スケジューラーポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
chrt コマンドラインツールを使用してスケジューラーポリシーおよび優先順位を確認し、調整します。これは、必要なプロパティーで新規プロセスを開始したり、実行中のプロセスのプロパティーを変更したりできます。また、ランタイム時にポリシーを設定するのにも使用できます。
手順
アクティブなプロセスのプロセス ID (PID) を表示します。
ps
# psCopy to Clipboard Copied! Toggle word wrap Toggle overflow psコマンドで--pidまたは-pオプションを使用して、特定の PID の詳細を表示します。特定のプロセスのスケジューリングポリシー、PID、および優先順位を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、468 と 476 はプロセスの PID です。
プロセスのスケジューリングポリシーを設定します。
たとえば、PID 1000 のプロセスを、優先度が 50 の SCHED_FIFO に設定するには、以下を実行します。
chrt -f -p 50 1000
# chrt -f -p 50 1000Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、PID 1000 のプロセスを、優先度が 0 の SCHED_OTHER に設定するには、以下を実行します。
chrt -o -p 0 1000
# chrt -o -p 0 1000Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、PID 1000 のプロセスを、優先度が 10 の SCHED_RR に設定するには、以下を実行します。
chrt -r -p 10 1000
# chrt -r -p 10 1000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のポリシーおよび優先度で新規アプリケーションを開始するには、アプリケーションの名前を指定します。
chrt -f 36 /bin/my-app
# chrt -f 36 /bin/my-appCopy to Clipboard Copied! Toggle word wrap Toggle overflow
31.6. chrt コマンドのポリシーオプション リンクのコピーリンクがクリップボードにコピーされました!
chrt コマンドでは、プロセスのスケジューリングポリシーを表示および設定することができます。
次の表は、プロセスのスケジューリングポリシーを設定するために使用できる、適切なポリシーオプションを説明しています。
| 短いオプション | Long オプション | 説明 |
|---|---|---|
|
|
|
スケジュールを |
|
|
|
スケジュールを |
|
|
|
スケジュールを |
31.7. ブートプロセス中のサービス優先度の変更 リンクのコピーリンクがクリップボードにコピーされました!
systemd サービスを使用すると、システムの起動プロセス中に起動したサービスに対して、リアルタイムの優先度を設定できます。ユニット設定ディレクティブ は、ブートプロセス中にサービスの優先度を変更するために使用されます。
ブートプロセスの優先度の変更は、service セクションの以下のディレクティブを使用して行われます。
CPUSchedulingPolicy=-
実行したプロセスの CPU スケジューリングポリシーを設定します。これは、
他のポリシー、fifoポリシー、およびrrポリシーを設定するために使用されます。 CPUSchedulingPriority=-
実行したプロセスの CPU スケジューリングの優先度を設定します。利用可能な優先度の範囲は、選択した CPU スケジューリングポリシーによって異なります。リアルタイムスケジューリングポリシーでは、
1(最も低い優先度) から99(最も高い優先度) までの整数を使用できます。
以下の手順では、ブートプロセス中に mcelog サービスを使用してサービスの優先度を変更する方法を説明します。
前提条件
TuneD パッケージをインストールします。
dnf install tuned
# dnf install tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow TuneD サービスを有効にして起動している。
systemctl enable --now tuned
# systemctl enable --now tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
実行中のスレッドのスケジュールの優先度を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 補助の
mcelogサービス設定ディレクトリーファイルを作成し、このファイルにポリシー名と優先度を挿入します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemdスクリプト設定を再読み込みします。systemctl daemon-reload
# systemctl daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow mcelogサービスを再起動します。systemctl restart mcelog
# systemctl restart mcelogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
systemd問題で設定したmcelog優先度を表示します。tuna -t mcelog -P thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 826 FIFO 20 0,1,2,3 13 0 mcelog
# tuna -t mcelog -P thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 826 FIFO 20 0,1,2,3 13 0 mcelogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
31.8. 優先順位マップ リンクのコピーリンクがクリップボードにコピーされました!
優先度はグループで定義され、特定のカーネル機能専用のグループもあります。リアルタイムスケジューリングポリシーでは、1 (最も低い優先度) から 99 (最も高い優先度) までの整数を使用できます。
次の表は、プロセスのスケジューリングポリシーを設定する際に使用できる優先度の範囲を示しています。
| 優先度 | Threads | 説明 |
|---|---|---|
| 1 | 優先度の低いカーネルスレッド |
通常、この優先度は |
| 2 - 49 | 利用可能 | 標準的なアプリケーションの優先度に使用される範囲。 |
| 50 | デフォルトの IRQ 値 | |
| 51 - 98 | 優先度の高いスレッド | この範囲は、定期的に実行されるスレッドと、迅速な応答時間に使用します。CPU にバインドされたスレッドには割り込みが必要になるため、この範囲を使用しないでください。 |
| 99 | ウォッチドッグおよび移行 | 最も高い優先順位で実行される必要があるシステムスレッド。 |
31.9. TuneD cpu-partitioning プロファイル リンクのコピーリンクがクリップボードにコピーされました!
レイテンシーに敏感なワークロード用に Red Hat Enterprise Linux 9 を調整する場合は、cpu-partitioning TuneD プロファイルを使用することが推奨されます。
Red Hat Enterprise Linux 9 以前では、低レイテンシーの Red Hat ドキュメントで、低レイテンシーのチューニングを実現するために必要な低レベルの手順が数多く説明されていました。Red Hat Enterprise Linux 9 では、cpu-partitioning TuneD プロファイルを使用することで、低レイテンシーのチューニングをより効率的に実行できます。このプロファイルは、個々の低レイテンシーアプリケーションの要件に従って簡単にカスタマイズできます。
以下の図は、cpu-partitioning プロファイルの使用方法を示す例になります。この例では、CPU とノードのレイアウトを使用します。
図31.1 cpu-partitioning の図
/etc/tuned/cpu-partitioning-variables.conf ファイルで cpu-partitioning プロファイルを設定するには、以下の設定オプションを使用します。
- 負荷分散機能のある分離された CPU
cpu-partitioning の図では、4 から 23 までの番号が付けられたブロックが、デフォルトの分離された CPU です。カーネルスケジューラーのプロセスの負荷分散は、この CPU で有効になります。これは、カーネルスケジューラーの負荷分散を必要とする複数のスレッドを使用した低レイテンシープロセス用に設計されています。
isolated_cores=cpu-listオプションを使用して、/etc/tuned/cpu-partitioning-variables.confファイルで cpu-partitioning プロファイルを設定できます。このオプションは、カーネルスケジューラーの負荷分散を使用する分離する CPU をリスト表示します。分離された CPU のリストはコンマ区切りで表示するか、
3-5のようにハイフンを使用して範囲を指定できます。このオプションは必須です。このリストにない CPU は、自動的にハウスキーピング CPU と見なされます。- 負荷分散を行わずに分離した CPU
cpu-partitioning の図では、2 と 3 の番号が付けられたブロックは、追加のカーネルスケジューラープロセスの負荷分散を提供しない分離された CPU です。
/etc/tuned/cpu-partitioning-variables.confファイルで cpu-partitioning プロファイルを設定するには、no_balance_cores=cpu-listオプションを使用します。このオプションは、カーネルスケジューラーの負荷分散を使用しない CPU を分離するようにリスト表示します。no_balance_coresオプションの指定は任意ですが、このリストの CPU は、isolated_coresリストに記載されている CPU のサブセットである必要があります。このような CPU を使用するアプリケーションスレッドは、各 CPU に個別にピン留めする必要があります。
- ハウスキーピング CPU
-
cpu-partitioning-variables.confファイル内で分離されていない CPU は、自動的にハウスキーピング CPU と見なされます。ハウスキーピング CPU では、すべてのサービス、デーモン、ユーザープロセス、移動可能なカーネルスレッド、割り込みハンドラー、およびカーネルタイマーの実行が許可されます。
31.10. 低レイテンシーチューニングへの TuneD の cpu-partitioning プロファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、TuneD の cpu-partitioning プロファイルを使用して、低レイテンシーになるようにシステムをチューニングする方法を説明します。これは、cpu-partitioning の図で説明されているように、cpu-partitioning と CPU レイアウトを使用できる低レイテンシーのアプリケーションの例を使用します。
この場合のアプリケーションでは、以下を使用します。
- ネットワークからデータを読み込む 1 つの専用リーダースレッドが、CPU 2 に固定されます。
- このネットワークデータを処理する多数のスレッドは、CPU 4-23 に固定されます。
- 処理されたデータをネットワークに書き込む専用のライタースレッドは、CPU 3 に固定されます。
前提条件
-
dnf install tuned-profiles-cpu-partitioningコマンドを root で使用して、cpu-partitioningTuneD プロファイルをインストールしている。
手順
/etc/tuned/cpu-partitioning-variables.confファイルを次のように編集します。isolation_cores=${f:calc_isolated_cores:1}行をコメントアウトします。isolated_cores=${f:calc_isolated_cores:1}# isolated_cores=${f:calc_isolated_cores:1}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 分離された CPU について次の情報を追加します。
# All isolated CPUs: isolated_cores=2-23 # Isolated CPUs without the kernel’s scheduler load balancing: no_balance_cores=2,3
# All isolated CPUs: isolated_cores=2-23 # Isolated CPUs without the kernel’s scheduler load balancing: no_balance_cores=2,3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cpu-partitioningTuneD プロファイルを設定します。tuned-adm profile cpu-partitioning
# tuned-adm profile cpu-partitioningCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムを再起動します。
再起動後、システムは、cpu-partitioning の図の分離に従って、低レイテンシーにチューニングされます。このアプリケーションでは、タスクセットを使用して、リーダーおよびライターのスレッドを CPU 2 および 3 に固定し、残りのアプリケーションスレッドを CPU 4-23 に固定できます。
検証
分離された CPU が
Cpus_allowed_listフィールドに反映されていないことを確認します。cat /proc/self/status | grep Cpu Cpus_allowed: 003 Cpus_allowed_list: 0-1
# cat /proc/self/status | grep Cpu Cpus_allowed: 003 Cpus_allowed_list: 0-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのプロセスのアフィニティーを確認するには、次のように入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TuneD は、一部のプロセス (主にカーネルプロセス) のアフィニティーを変更できません。この例では、PID 4 および 9 のプロセスは変更されません。
31.11. cpu-partitioning TuneD プロファイルのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
TuneD プロファイルを拡張して、追加のチューニング変更を行うことができます。
たとえば、cpu-partitioning プロファイルは、cstate=1 を使用する CPU を設定します。cpu-partitioning プロファイルを使用しながら、cstate1 から cstate0 に CPU の cstate を変更するために、以下の手順では my_profile という名前の新しい TuneD プロファイルを説明しています。このプロファイルは、cpu-partitioning プロファイルを継承した後、C state-0 を設定します。
手順
/etc/tuned/my_profileディレクトリーを作成します。mkdir /etc/tuned/my_profile
# mkdir /etc/tuned/my_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow このディレクトリーに
tuned.confファイルを作成し、次の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいプロファイルを使用します。
tuned-adm profile my_profile
# tuned-adm profile my_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
この共有例では、再起動は必要ありません。ただし、my_profile プロファイルの変更を有効にするために再起動が必要な場合は、マシンを再起動します。
第32章 ネットワークパフォーマンスのチューニング リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク設定のチューニングは、考慮すべき要素が多数ある複雑なプロセスです。たとえば、これには、CPU からメモリーへのアーキテクチャー、CPU コアの量などが含まれます。Red Hat Enterprise Linux は、ほとんどのシナリオに最適化されたデフォルト設定を使用します。ただし、場合によっては、ネットワーク設定をチューニングして、スループットや遅延を増やしたり、パケットドロップなどの問題を解決したりする必要があります。
32.1. ネットワークアダプター設定のチューニング リンクのコピーリンクがクリップボードにコピーされました!
40 Gbps 以上の高速ネットワークでは、ネットワークアダプター関連のカーネル設定の特定のデフォルト値がパケットドロップやパフォーマンス低下の原因となる可能性があります。これらの設定をチューニングすると、このような問題を防ぐことができます。
32.1.1. nmcli を使用して、高いパケットドロップ率を減らすためにリングバッファーサイズを増やす リンクのコピーリンクがクリップボードにコピーされました!
パケットドロップ率が原因でアプリケーションがデータの損失、タイムアウト、またはその他の問題を報告する場合は、イーサネットデバイスのリングバッファーのサイズを増やします。
受信リングバッファーは、デバイスドライバーとネットワークインターフェイスコントローラー (NIC) の間で共有されます。カードは、送信 (TX) および受信 (RX) リングバッファーを割り当てます。名前が示すように、リングバッファーは循環バッファーであり、オーバーフローによって既存のデータが上書きされます。NIC からカーネルにデータを移動するには、ハードウェア割り込みと、SoftIRQ とも呼ばれるソフトウェア割り込みの 2 つの方法があります。
カーネルは RX リングバッファーを使用して、デバイスドライバーが着信パケットを処理できるようになるまで着信パケットを格納します。デバイスドライバーは、通常は SoftIRQ を使用して RX リングをドレインします。これにより、着信パケットは sk_buff または skb と呼ばれるカーネルデータ構造に配置され、カーネルを経由して関連するソケットを所有するアプリケーションまでの移動を開始します。
カーネルは TX リングバッファーを使用して、ネットワークに送信する必要がある発信パケットを保持します。これらのリングバッファーはスタックの一番下にあり、パケットドロップが発生する重要なポイントであり、ネットワークパフォーマンスに悪影響を及ぼします。
手順
インターフェイスのパケットドロップ統計を表示します。
ethtool -S enp1s0 ... rx_queue_0_drops: 97326 rx_queue_1_drops: 63783 ...# ethtool -S enp1s0 ... rx_queue_0_drops: 97326 rx_queue_1_drops: 63783 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの出力は、ネットワークカードとドライバーに依存することに注意してください。
discardまたはdropカウンターの値が高い場合は、カーネルがパケットを処理できるよりも速く、使用可能なバッファーがいっぱいになることを示します。リングバッファーを増やすと、このような損失を回避できます。最大リングバッファーサイズを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pre-set maximumsセクションの値がCurrent hardware settingsセクションよりも高い場合は、次の手順で設定を変更できます。このインターフェイスを使用する NetworkManager 接続プロファイルを特定します。
nmcli connection show NAME UUID TYPE DEVICE Example-Connection a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1s0
# nmcli connection show NAME UUID TYPE DEVICE Example-Connection a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続プロファイルを更新し、リングバッファーを増やします。
RX リングバッファーを増やすには、次のように実行します。
nmcli connection modify Example-Connection ethtool.ring-rx 4096
# nmcli connection modify Example-Connection ethtool.ring-rx 4096Copy to Clipboard Copied! Toggle word wrap Toggle overflow TX リングバッファーを増やすには、次のように実行します。
nmcli connection modify Example-Connection ethtool.ring-tx 4096
# nmcli connection modify Example-Connection ethtool.ring-tx 4096Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkManager 接続をリロードします。
nmcli connection up Example-Connection
# nmcli connection up Example-ConnectionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要NIC が使用するドライバーによっては、リングバッファーを変更すると、ネットワーク接続が短時間中断されることがあります。
32.1.2. パケットドロップを回避するためにネットワークデバイスのバックログキューをチューニングする リンクのコピーリンクがクリップボードにコピーされました!
ネットワークカードがパケットを受信し、カーネルプロトコルスタックがこれらのパケットを処理する前に、カーネルはこれらのパケットをバックログキューに保存します。カーネルは、CPU コアごとに個別のキューを維持します。
コアのバックログキューがいっぱいの場合、カーネルは、netif_receive_skb() カーネル関数がこのキューに割り当てるそれ以降の受信パケットをすべてドロップします。サーバーに速度が 10 Gbps 以上のネットワークアダプターまたは複数の 1 Gbps アダプターが含まれている場合は、バックログキューのサイズをチューニングしてこの問題を回避します。
前提条件
- 速度が 10 Gbps 以上、または複数の 1 Gbps ネットワークアダプター
手順
バックログキューのチューニングが必要かどうかを判断し、
/proc/net/softnet_statファイル内のカウンターを表示します。awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t 221951548 0 0 0 0 0 0 0 0 0 0 0 0 192058677 18862 0 0 0 0 0 0 0 0 0 0 1 455324886 0 0 0 0 0 0 0 0 0 0 0 2 ...# awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t 221951548 0 0 0 0 0 0 0 0 0 0 0 0 192058677 18862 0 0 0 0 0 0 0 0 0 0 1 455324886 0 0 0 0 0 0 0 0 0 0 0 2 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この
awkコマンドは、/proc/net/softnet_statの値を 16 進形式から 10 進形式に変換し、表形式で表示します。各行は、コア 0 から始まる CPU コアを表します。関連する列は次のとおりです。
- 最初の列: 受信フレームの総数
- 2 番目の列: バックログキューがいっぱいであるためにドロップされたフレームの数
- 最後の列: CPU コア番号
/proc/net/softnet_statファイルの 2 番目の列の値が時間の経過とともに増加する場合は、バックログキューのサイズを増やします。現在のバックログキューのサイズを表示します。
sysctl net.core.netdev_max_backlog net.core.netdev_max_backlog = 1000
# sysctl net.core.netdev_max_backlog net.core.netdev_max_backlog = 1000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の内容を含む
/etc/sysctl.d/10-netdev_max_backlog.confファイルを作成します。net.core.netdev_max_backlog = 2000
net.core.netdev_max_backlog = 2000Copy to Clipboard Copied! Toggle word wrap Toggle overflow net.core.netdev_max_backlogパラメーターを現在の値の 2 倍に設定します。/etc/sysctl.d/10-netdev_max_backlog.confファイルから設定をロードします。sysctl -p /etc/sysctl.d/10-netdev_max_backlog.conf
# sysctl -p /etc/sysctl.d/10-netdev_max_backlog.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
/proc/net/softnet_statファイルの 2 番目の列を監視します。awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t# awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -tCopy to Clipboard Copied! Toggle word wrap Toggle overflow それでも値が増加する場合は、
net.core.netdev_max_backlog値を再度 2 倍にします。パケットドロップカウンターが増加しなくなるまで、このプロセスを繰り返します。
32.1.3. NIC の送信キューの長さを増やして送信エラーの数を減らす リンクのコピーリンクがクリップボードにコピーされました!
カーネルは、パケットを送信する前に送信キューにパケットを格納します。デフォルトの長さ (1000 パケット) は、通常、10 Gbps には十分です。また、多くの場合、40 Gbps ネットワークにも十分です。ただし、より高速なネットワークの場合、またはアダプターで送信エラーが増加する場合は、キューの長さを増やしてください。
手順
現在の送信キューの長さを表示します。
ip -s link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 ...
# ip -s link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
enp1s0インターフェイスの送信キューの長さ (qlen) は1000です。ネットワークインターフェイスのソフトウェア送信キューのドロップされたパケットカウンターを監視します。
tc -s qdisc show dev enp1s0 qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 Sent 16889923 bytes 426862765 pkt (dropped 191980, overlimits 0 requeues 2) ...
# tc -s qdisc show dev enp1s0 qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 Sent 16889923 bytes 426862765 pkt (dropped 191980, overlimits 0 requeues 2) ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 送信エラー数が多い、または増加している場合は、送信キューの長さをより長く設定します。
このインターフェイスを使用する NetworkManager 接続プロファイルを特定します。
nmcli connection show NAME UUID TYPE DEVICE Example-Connection a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1s0
# nmcli connection show NAME UUID TYPE DEVICE Example-Connection a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続プロファイルを更新し、送信キューの長さを増やします。
nmcli connection modify Example-Connection link.tx-queue-length 2000
# nmcli connection modify Example-Connection link.tx-queue-length 2000Copy to Clipboard Copied! Toggle word wrap Toggle overflow キューの長さを現在の値の 2 倍に設定します。
変更を適用します。
nmcli connection up Example-Connection
# nmcli connection up Example-ConnectionCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
送信キューの長さを表示します。
ip -s link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 2000 ...
# ip -s link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 2000 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow ドロップされたパケットカウンターを監視します。
tc -s qdisc show dev enp1s0
# tc -s qdisc show dev enp1s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow droppedカウンターがまだ増加する場合は、送信キューの長さを再度 2 倍にします。カウンターが増加しなくなるまで、このプロセスを繰り返します。
32.2. IRQ バランシングのチューニング リンクのコピーリンクがクリップボードにコピーされました!
マルチコアホストでは、Red Hat Enterprise Linux が割り込みキュー (IRQ) のバランスをとり、CPU コア全体に割り込みを分散するようにすることで、パフォーマンスを向上させることができます。
32.2.1. 割り込みと割り込みハンドラー リンクのコピーリンクがクリップボードにコピーされました!
ネットワークインターフェイスコントローラー (NIC) が受信データを受信すると、Direct Memory Access (DMA) を使用してそのデータをカーネルバッファーにコピーします。次に、NIC はハード割り込みをトリガーして、このデータについてカーネルに通知します。これらの割り込みは、すでに別のタスクに割り込んでおり、ハンドラー自体は割り込むことができないため、最小限の作業を行う割り込みハンドラーによって処理されます。ハード割り込みは、特にカーネルロックを使用する場合、CPU 使用率の点でコストがかかる可能性があります。
その後、ハード割り込みハンドラーは、パケット受信の大部分をソフトウェア割り込み要求 (SoftIRQ) プロセスに任せます。カーネルは、これらのプロセスをより公平にスケジュールできます。
例32.1 ハードウェア割り込みの表示
カーネルは、割り込みカウンターを /proc/interrupts ファイルに保存します。enp1s0 などの特定の NIC のカウンターを表示するには、次のように入力します。
各キューには、最初の列に割り込みベクトルが割り当てられています。カーネルは、システムの起動時、またはユーザーが NIC ドライバーモジュールをロードしたときに、これらのベクトルを初期化します。各受信 (RX) キューと送信 (TX) キューには、どの NIC またはキューから割り込みが発生しているかを割り込みハンドラーに通知する固有のベクトルが割り当てられます。列は、各 CPU コアの受信割り込みの数を表します。
32.2.2. ソフトウェア割り込み要求 リンクのコピーリンクがクリップボードにコピーされました!
ソフトウェア割り込み要求 (SoftIRQ) は、ネットワークアダプターの受信リングバッファーをクリアします。カーネルは、他のタスクが割り込みされない時間に SoftIRQ ルーチンが実行されるようにスケジュールします。Red Hat Enterprise Linux では、ksoftirqd/cpu-number という名前のプロセスがこれらのルーチンを実行し、ドライバー固有のコード関数を呼び出します。
各 CPU コアの SoftIRQ カウンターを監視するには、次のように入力します。
watch -n1 'grep -E "CPU|NET_RX|NET_TX" /proc/softirqs'
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
NET_TX: 49672 52610 28175 97288 12633 19843 18746 220689
NET_RX: 96 1615 789 46 31 1735 1315 470798
# watch -n1 'grep -E "CPU|NET_RX|NET_TX" /proc/softirqs'
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
NET_TX: 49672 52610 28175 97288 12633 19843 18746 220689
NET_RX: 96 1615 789 46 31 1735 1315 470798
このコマンドは出力を動的に更新します。Ctrl+C を押して出力に割り込みます。
32.2.3. NAPI ポーリング リンクのコピーリンクがクリップボードにコピーされました!
New API (NAPI) は、受信ネットワークパケットの効率を向上させるためのデバイスドライバーパケット処理フレームワークの拡張機能です。ハード割り込みは、通常、カーネル空間からユーザー空間へのコンテキストの切り替えを引き起こし、またその逆のコンテキストの切り替えも引き起こし、それ自体を中断することができないため、コストがかかります。割り込み結合を行っても、割り込みハンドラーは CPU コアを完全に独占します。NAPI を使用すると、ドライバーは、パケットを受信するたびにカーネルによってハード割り込みされるのではなく、ポーリングモードを使用できます。
通常の操作では、カーネルは最初のハード割り込みを発行し、続いて NAPI ルーチンを使用してネットワークカードをポーリングするソフト割り込み要求 (SoftIRQ) ハンドラーを発行します。SoftIRQ が CPU コアを独占しないようにするために、ポーリングルーチンには、SoftIRQ が消費できる CPU 時間を決定するバジェットがあります。SoftIRQ ポーリングルーチンが完了すると、カーネルはルーチンを終了し、後で再度実行してネットワークカードからパケットを受信するプロセスを繰り返すようにスケジュールします。
32.2.4. irqbalance サービス リンクのコピーリンクがクリップボードにコピーされました!
Non-Uniform Memory Access (NUMA) アーキテクチャーを備えたシステムと備えていないシステムの両方で、irqbalance サービスは、システム条件に基づいて CPU コア間で効果的に割り込みのバランスをとります。irqbalance サービスはバックグラウンドで実行され、10 秒ごとに CPU 負荷を監視します。CPU の負荷が高すぎる場合、このサービスは割り込みを他の CPU コアに移動します。その結果、システムのパフォーマンスが向上し、負荷がより効率的に処理されます。
irqbalance が実行されていない場合、通常は CPU コア 0 がほとんどの割り込みを処理します。中程度の負荷でも、この CPU コアはシステム内のすべてのハードウェアのワークロードを処理しようとしてビジーになる可能性があります。その結果、割り込みまたは割り込みベースの作業ができなかったり、遅延したりする可能性があります。これにより、ネットワークやストレージのパフォーマンスの低下、パケットロス、その他の問題が発生する可能性があります。
irqbalance を無効にすると、ネットワークのスループットに悪影響を及ぼす可能性があります。
CPU コアが 1 つしかないシステムでは、irqbalance サービスは何のメリットも提供せず、自動的に終了します。
デフォルトでは、irqbalance サービスは有効になっており、Red Hat Enterprise Linux 上で実行されています。サービスを無効にした場合に再度有効にするには、次のように入力します。
systemctl enable --now irqbalance
# systemctl enable --now irqbalance
32.2.5. CPU 上で SoftIRQ を実行できる時間の増加 リンクのコピーリンクがクリップボードにコピーされました!
SoftIRQ の実行時間が十分でない場合、受信データの速度が、バッファーを十分な速さでドレインするカーネルの能力を超える可能性があります。その結果、ネットワークインターフェイスコントローラー (NIC) のバッファーがオーバーフローし、パケットが失われます。
softirqd プロセスが 1 回の NAPI ポーリングサイクルでインターフェイスからすべてのパケットを取得できなかった場合、それは SoftIRQ に十分な CPU 時間がないことを示しています。これは、10 Gbps 以上の高速 NIC を備えたホストに当てはまる可能性があります。net.core.netdev_budget および net.core.netdev_budget_usecs カーネルパラメーターの値を増やすと、softirqd がポーリングサイクルで処理できる時間とパケット数を制御できます。
手順
net.core.netdev_budgetパラメーターのチューニングが必要かどうかを判断するには、/proc/net/softnet_statファイル内のカウンターを表示します。awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t 221951548 0 0 0 0 0 0 0 0 0 0 0 0 192058677 0 20380 0 0 0 0 0 0 0 0 0 1 455324886 0 0 0 0 0 0 0 0 0 0 0 2 ...# awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t 221951548 0 0 0 0 0 0 0 0 0 0 0 0 192058677 0 20380 0 0 0 0 0 0 0 0 0 1 455324886 0 0 0 0 0 0 0 0 0 0 0 2 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この
awkコマンドは、/proc/net/softnet_statの値を 16 進形式から 10 進形式に変換し、表形式で表示します。各行は、コア 0 から始まる CPU コアを表します。関連する列は次のとおりです。
- 最初の列: 受信フレームの総数
-
3 番目の列: 1 回の NAPI ポーリングサイクルでインターフェイスからすべてのパケットを取得できなかった
softirqdプロセスの回数。 - 最後の列: CPU コア番号
/proc/net/softnet_statファイルの 3 番目の列のカウンターが、時間の経過とともに増加する場合は、システムをチューニングします。net.core.netdev_budget_usecsおよびnet.core.netdev_budgetパラメーターの現在の値を表示します。sysctl net.core.netdev_budget_usecs net.core.netdev_budget net.core.netdev_budget_usecs = 2000 net.core.netdev_budget = 300
# sysctl net.core.netdev_budget_usecs net.core.netdev_budget net.core.netdev_budget_usecs = 2000 net.core.netdev_budget = 300Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの設定を使用すると、
softirqdプロセスは、1 回のポーリングサイクルで、NIC から最大 300 個のメッセージを処理するのに最大 2000 マイクロ秒あります。ポーリングは、どの条件が最初に満たされたかに基づいて終了します。次の内容を含む
/etc/sysctl.d/10-netdev_budget.confファイルを作成します。net.core.netdev_budget = 600 net.core.netdev_budget_usecs = 4000
net.core.netdev_budget = 600 net.core.netdev_budget_usecs = 4000Copy to Clipboard Copied! Toggle word wrap Toggle overflow パラメーターを現在の値の 2 倍に設定します。
/etc/sysctl.d/10-netdev_budget.confファイルから設定をロードします。sysctl -p /etc/sysctl.d/10-netdev_budget.conf
# sysctl -p /etc/sysctl.d/10-netdev_budget.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
/proc/net/softnet_statファイルの 3 番目の列を監視します。awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t# awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -tCopy to Clipboard Copied! Toggle word wrap Toggle overflow それでも値が増加する場合は、
net.core.netdev_budget_usecsとnet.core.netdev_budgetをより高い値に設定します。カウンターが増加しなくなるまで、このプロセスを繰り返します。
32.3. ネットワーク遅延の改善 リンクのコピーリンクがクリップボードにコピーされました!
CPU 電力管理機能により、時間を考慮する必要があるアプリケーション処理に望ましくない遅延が発生する可能性があります。これらの電源管理機能の一部またはすべてを無効にして、ネットワーク遅延を改善できます。
たとえば、サーバーの負荷が高いときよりもアイドル状態のときの遅延が高い場合は、CPU 電源管理設定が遅延に影響を与える可能性があります。
CPU 電源管理機能を無効にすると、電力消費量が増加し、熱損失が発生する可能性があります。
32.3.1. CPU の電源状態がネットワーク遅延に与える影響 リンクのコピーリンクがクリップボードにコピーされました!
CPU の消費状態 (C-状態) は、コンピューターの消費電力を最適化し、削減します。C-状態には、C0 から始まる番号が付けられます。C0 では、プロセッサーはフルパワーで動作し、実行しています。C1 では、プロセッサーはフルパワーで動作していますが、実行されていません。C-状態の番号が大きいほど、CPU がオフにするコンポーネントの数が多くなります。
CPU コアがアイドル状態になると常に、内蔵の省電力ロジックが介入し、さまざまなプロセッサーコンポーネントをオフにして、コアを現在の C-状態から上位の C-状態に移行しようとします。CPU コアがデータを処理する必要がある場合、Red Hat Enterprise Linux (RHEL) はプロセッサーに割り込みを送信してコアをウェイクアップし、C-状態を C0 に戻します。
ディープ C-状態から C0 に戻るには、プロセッサーのさまざまなコンポーネントの電源を再度オンにするため、時間がかかります。マルチコアシステムでは、多くのコアが同時にアイドル状態になり、より深い C-状態になることもあります。RHEL がそれらを同時にウェイクアップしようとすると、すべてのコアがディープ C-状態から戻る間に、カーネルが大量のプロセッサー間割り込み (IPI) を生成する可能性があります。割り込みの処理中にロックが必要となるため、システムはすべての割り込みの処理中にしばらく停止する可能性があります。これにより、イベントに対するアプリケーションの応答が大幅に遅延する可能性があります。
例32.2 コアごとの C-状態時間の表示
PowerTOP アプリケーションの Idle Stats ページには、CPU コアが各 C-状態で費やした時間が表示されます。
32.3.2. EFI ファームウェアの C-状態設定 リンクのコピーリンクがクリップボードにコピーされました!
EFI ファームウェアを備えたほとんどのシステムでは、個々の消費状態 (C-状態) を有効または無効にすることができます。ただし、Red Hat Enterprise Linux (RHEL) では、アイドルドライバーによって、カーネルがファームウェアの設定を使用するかどうかが決定されます。
-
intel_idle: これは、Intel CPU を搭載したホスト上のデフォルトのドライバーであり、EFI ファームウェアからの C-状態設定を無視します。 -
acpi_idle: RHEL は、Intel 以外のベンダーの CPU を搭載したホスト上、およびintel_idleが無効になっている場合に、このドライバーを使用します。デフォルトでは、acpi_idleドライバーは EFI ファームウェアの C-状態設定を使用します。
32.3.3. カスタム TuneD プロファイルを使用した C-状態の無効化 リンクのコピーリンクがクリップボードにコピーされました!
TuneD サービスは、カーネルの Power Management Quality of Service (PMQOS) インターフェイスを使用して、消費状態 (C 状態) のロックを設定します。カーネルアイドルドライバーは、このインターフェイスと通信して C-状態を動的に制限できます。これにより、管理者がカーネルコマンドラインパラメーターを使用して、C-状態の最大値をハードコーディングする必要がなくなります。
前提条件
-
tunedパッケージがインストールされている。 -
tunedサービスが有効化され、実行されている。
手順
アクティブなプロファイルを表示します。
tuned-adm active Current active profile: network-latency
# tuned-adm active Current active profile: network-latencyCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム TuneD プロファイル用のディレクトリーを作成します。
mkdir /etc/tuned/network-latency-custom/
# mkdir /etc/tuned/network-latency-custom/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の内容を含む
/etc/tuned/network-latency-custom/tuned.confファイルを作成します。[main] include=network-latency [cpu] force_latency=cstate.id:1|2
[main] include=network-latency [cpu] force_latency=cstate.id:1|2Copy to Clipboard Copied! Toggle word wrap Toggle overflow このカスタムプロファイルは、
network-latencyプロファイルからすべての設定を継承します。force_latencyTuneD パラメーターは、遅延をマイクロ秒 (µs) 単位で指定します。C-状態のレイテンシーが指定された値よりも高い場合、Red Hat Enterprise Linux のアイドルドライバーは CPU がより高い C-状態に移行するのを防ぎます。force_latency=cstate.id:1|2を指定すると、TuneD は最初に/sys/devices/system/cpu/cpu_<number>_/cpuidle/state_<cstate.id>_/ディレクトリーが存在するかどうかを確認します。この場合、TuneD はこのディレクトリー内のlatencyファイルからレイテンシー値を読み取ります。ディレクトリーが存在しない場合は、TuneD はフォールバック値として 2 マイクロ秒を使用します。network-latency-customプロファイルをアクティブ化します。tuned-adm profile network-latency-custom
# tuned-adm profile network-latency-customCopy to Clipboard Copied! Toggle word wrap Toggle overflow
32.3.4. カーネルコマンドラインオプションを使用した C-状態の無効化 リンクのコピーリンクがクリップボードにコピーされました!
processor.max_cstate および intel_idle.max_cstate カーネルコマンドラインパラメーターは、CPU コアが使用できる最大消費状態(C-状態)を設定します。たとえば、パラメーターを 1 に設定すると、CPU は C1 より下の C-状態を要求しなくなります。
この方法を使用して、ホスト上のアプリケーションの遅延が C-状態の影響を受けているかどうかをテストします。特定の状態をハードコーディングしないようにするには、より動的なソリューションの使用を検討してください。Disabling C-states by using a custom TuneD profile を参照してください。
前提条件
-
tunedサービスが実行されていないか、C-状態設定を更新しないように設定されています。
手順
システムが使用するアイドル状態のドライバーを表示します。
cat /sys/devices/system/cpu/cpuidle/current_driver intel_idle
# cat /sys/devices/system/cpu/cpuidle/current_driver intel_idleCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが
intel_idleドライバーを使用している場合は、intel_idle.max_cstateカーネルパラメーターを設定して、CPU コアが使用できる最高の C-状態を定義します。grubby --update-kernel=ALL --args="intel_idle.max_cstate=0"
# grubby --update-kernel=ALL --args="intel_idle.max_cstate=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow intel_idle.max_cstate=0を設定すると、intel_idleドライバーが無効になります。その結果、カーネルは、EFI ファームウェアで設定された C-状態値を使用するacpi_idleドライバーを使用します。このため、これらの C-状態設定をオーバーライドするには、processor.max_cstateも設定します。すべてのホストで、CPU ベンダーから独立して、CPU コアが使用できる最高の C-状態を設定します。
grubby --update-kernel=ALL --args="processor.max_cstate=0"
# grubby --update-kernel=ALL --args="processor.max_cstate=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要intel_idle.max_cstate=0に加えてprocessor.max_cstate=0を設定すると、acpi_idleドライバーはprocessor.max_cstateの値をオーバーライドして1に設定します。その結果、processor.max_cstate=0 intel_idle.max_cstate=0の場合、カーネルが使用する最高の C-状態は C0 ではなく C1 になります。変更を有効にするためにホストを再起動します。
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
最大の C-状態を表示します。
cat /sys/module/processor/parameters/max_cstate 1
# cat /sys/module/processor/parameters/max_cstate 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが
intel_idleドライバーを使用している場合は、最大の C-状態を表示します。cat /sys/module/intel_idle/parameters/max_cstate 0
# cat /sys/module/intel_idle/parameters/max_cstate 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
32.4. 大量の連続したデータストリームのスループットの向上 リンクのコピーリンクがクリップボードにコピーされました!
IEEE 802.3 標準によれば、仮想ローカルエリアネットワーク (VLAN) タグのないデフォルトのイーサネットフレームの最大サイズは 1518 バイトです。これらの各フレームには 18 バイトのヘッダーが含まれて、ペイロード用に 1500 バイトが残されます。したがって、サーバーがネットワーク経由で送信するデータの 1500 バイトごとに、18 バイト (1.2%) のイーサネットフレームヘッダーがオーバーヘッドとなって送信されます。レイヤー 3 およびレイヤー 4 プロトコルのヘッダーにより、パケットあたりのオーバーヘッドがさらに増加します。
ネットワーク上のホストが、多数の連続したデータストリーム (バックアップサーバーや多数の巨大なファイルをホストするファイルサーバーなど) を頻繁に送信する場合は、オーバーヘッドを節約するためにジャンボフレームの採用を検討してください。ジャンボフレームは、標準のイーサネットペイロードサイズである 1500 バイトよりも大きな最大伝送単位 (MTU) を持つ非標準フレームです。たとえば、最大許容 MTU が 9000 バイトのペイロードでジャンボフレームを設定すると、各フレームのオーバーヘッドは 0.2% に減少します。
ネットワークとサービスによっては、クラスターのストレージバックエンドなど、ネットワークの特定の部分でのみジャンボフレームを有効にすることが有益な場合があります。これにより、パケットの断片化が回避されます。
32.4.1. ジャンボフレームを設定する前の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク内のハードウェア、アプリケーション、サービスに応じて、ジャンボフレームはさまざまな影響を与える可能性があります。ジャンボフレームを有効にすることがシナリオにメリットをもたらすかどうかを慎重に考慮して決定してください。
前提条件
伝送パス上のすべてのネットワークデバイスはジャンボフレームをサポートし、同じ最大伝送単位 (MTU) サイズを使用する必要があります。逆の場合は、次の問題に直面する可能性があります。
- ドロップされたパケット
- 断片化されたパケットが原因の遅延が大きい
- 断片化によるパケットロスのリスクの増加。たとえば、ルーターが 1 つの 9000 バイトフレームを 6 つの 1500 バイトフレームに分割し、それらの 1500 バイトフレームのいずれかが失われた場合、フレーム全体は再設定できないため失われます。
次の図では、ネットワーク A のホストがネットワーク C のホストにパケットを送信する場合、3 つのサブネット内のすべてのホストが同じ MTU を使用する必要があります。
ジャンボフレームの利点
- より高いスループット: 各フレームにはより多くのユーザーデータが含まれますが、プロトコルオーバーヘッドは固定されています。
- CPU 使用率の低下: ジャンボフレームにより発生する割り込みが少なくなるため、CPU サイクルが節約されます。
ジャンボフレームの欠点
- 遅延が大きい: フレームが大きいと、後続のパケットが遅延します。
- メモリーバッファーの使用量の増加: フレームが大きくなると、バッファーキューメモリーがより早くいっぱいになる可能性があります。
32.4.2. 既存の NetworkManager 接続プロファイルでの MTU の設定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークでデフォルトとは異なる最大伝送単位 (MTU) が必要な場合は、対応する NetworkManager 接続プロファイルでこの設定を設定できます。
ジャンボフレームは、1500 - 9000 バイトのペイロードを持つネットワークパケットです。同じブロードキャストドメイン内のすべてのデバイスは、これらのフレームをサポートする必要があります。
前提条件
- ブロードキャストドメイン内のすべてのデバイスが同じ MTU を使用している。
- ネットワークの MTU を把握している。
- 不一致の MTU を使用するネットワークの接続プロファイルがすでに設定されている。
手順
オプション: 現在の MTU を表示します。
ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...# ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: NetworkManager 接続プロファイルを表示します。
nmcli connection show NAME UUID TYPE DEVICE Example f2f33f29-bb5c-3a07-9069-be72eaec3ecf ethernet enp1s0 ...
# nmcli connection show NAME UUID TYPE DEVICE Example f2f33f29-bb5c-3a07-9069-be72eaec3ecf ethernet enp1s0 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 不一致の MTU を使用してネットワークへの接続を管理するプロファイルに MTU を設定します。
nmcli connection modify Example mtu 9000
# nmcli connection modify Example mtu 9000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続を再度アクティベートします。
nmcli connection up Example
# nmcli connection up ExampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
MTU 設定を表示します。
ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...# ip link show ... 3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 伝送パス上にパケットを断片化するホストがないことを確認します。
受信側で、カーネルの IP 再構築統計を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カウンターが
0を返した場合、パケットは再構築されていません。送信者側で、prohibit-fragmentation-bit を指定して ICMP リクエストを送信します。
ping -c1 -Mdo -s 8972 destination_host
# ping -c1 -Mdo -s 8972 destination_hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが成功した場合、パケットは断片化されていません。
-sパケットサイズオプションの値を次のように計算します。MTU サイズ - 8 バイト ICMP ヘッダー - 20 バイト IPv4 ヘッダー = パケットサイズ
32.5. 高スループットのための TCP 接続のチューニング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux で TCP 関連の設定をチューニングして、スループットを向上させ、レイテンシーを短縮し、パケットロスなどの問題を防止します。
32.5.1. iperf3 を使用した TCP スループットのテスト リンクのコピーリンクがクリップボードにコピーされました!
iperf3 ユーティリティーは、サーバーモードとクライアントモードを提供し、2 つのホスト間のネットワークスループットテストを実行します。
アプリケーションのスループットは、アプリケーションが使用するバッファーサイズなどの多くの要因に依存します。したがって、iperf3 などのテストユーティリティーで測定された結果は、実稼働ワークロード下のサーバー上のアプリケーションの結果とは大幅に異なる可能性があります。
前提条件
-
iperf3パッケージはクライアントとサーバーの両方にインストールされている。 - どちらかのホスト上の他のサービスによって、テスト結果に大きな影響を与えるネットワークトラフィックが発生することはない。
- 速度が 40 Gbps 以上の接続の場合、ネットワークカードは Accelerated Receive Flow Steering (ARFS) をサポートし、この機能はインターフェイスで有効になっている。
手順
オプション: サーバーとクライアントの両方のネットワークインターフェイスコントローラー (NIC) の最大ネットワーク速度を表示します。
ethtool enp1s0 | grep "Speed" Speed: 100000Mb/s
# ethtool enp1s0 | grep "Speed" Speed: 100000Mb/sCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバー上では以下の設定になります。
firewalldサービスでデフォルトのiperf3TCP ポート 5201 を一時的に開きます。firewall-cmd --add-port=5201/tcp
# firewall-cmd --add-port=5201/tcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow iperf3をサーバーモードで起動します。iperf3 --server
# iperf3 --serverCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスは現在、受信クライアント接続を待機しています。
クライアントで以下を実行します。
スループットの測定を開始します。
iperf3 --time 60 --zerocopy --client 192.0.2.1
# iperf3 --time 60 --zerocopy --client 192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow --time <seconds>: クライアントが送信を停止する時間を秒単位で定義します。このパラメーターを機能すると予想される値に設定し、後の測定で値を増やします。クライアントが送信パス上のデバイスまたはサーバーが処理できる速度よりも速い速度でパケットを送信すると、パケットがドロップされる可能性があります。
-
--zerocopy:write()システムコールを使用する代わりに、ゼロコピーメソッドを有効にします。このオプションは、ゼロコピー対応アプリケーションをシミュレートする場合、または単一ストリームで 40 Gbps 以上に達する場合にのみ必要です。 -
--client <server>: クライアントモードを有効にし、iperf3サーバーを実行するサーバーの IP アドレスまたは名前を設定します。
iperf3がテストを完了するまで待ちます。サーバーとクライアントの両方で統計が毎秒表示され、最後に概要が表示されます。たとえば、以下はクライアントに表示される概要です。[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 101 GBytes 14.4 Gbits/sec 0 sender [ 5] 0.00-60.04 sec 101 GBytes 14.4 Gbits/sec receiver
[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 101 GBytes 14.4 Gbits/sec 0 sender [ 5] 0.00-60.04 sec 101 GBytes 14.4 Gbits/sec receiverCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、平均ビットレートは 14.4 Gbps でした。
サーバー上では以下の設定になります。
-
Ctrl+C を押して
iperf3サーバーを停止します。 firewalldで TCP ポート 5201 を閉じます。firewall-cmd --remove-port=5201/tcp
# firewall-cmd --remove-port=5201/tcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Ctrl+C を押して
32.5.2. システム全体の TCP ソケットバッファー設定 リンクのコピーリンクがクリップボードにコピーされました!
ソケットバッファーには、カーネルが受信したデータ、または送信する必要があるデータが一時的に保存されます。
- 読み取りソケットバッファーには、カーネルが受信したがアプリケーションがまだ読み取っていないパケットが保持されます。
- 書き込みソケットバッファーには、アプリケーションがバッファーに書き込んだものの、カーネルがまだ IP スタックとネットワークドライバーに渡していないパケットが保持されます。
TCP パケットが大きすぎてバッファーサイズを超えている場合、またはパケットの送受信速度が速すぎる場合、カーネルはデータがバッファーから削除されるまで、新しい受信 TCP パケットをドロップします。この場合、ソケットバッファーを増やすことでパケットロスを防ぐことができます。
net.ipv4.tcp_rmem (読み取り) と net.ipv4.tcp_wmem (書き込み) の両方のソケットバッファーカーネル設定には、次の 3 つの値が含まれます。
net.ipv4.tcp_rmem = 4096 131072 6291456 net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 131072 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
表示される値はバイト単位であり、Red Hat Enterprise Linux はそれらを次の方法で使用します。
- 最初の値は最小バッファーサイズです。新しいソケットのサイズを小さくすることはできません。
- 2 番目の値はデフォルトのバッファーサイズです。アプリケーションがバッファーサイズを設定しない場合、これがデフォルト値になります。
-
3 番目の値は、自動的にチューニングされるバッファーの最大サイズです。アプリケーションで
setsockopt()関数をSO_SNDBUFソケットオプションとともに使用すると、この最大バッファーサイズが無効になります。
net.ipv4.tcp_rmem および net.ipv4.tcp_wmem パラメーターは、IPv4 プロトコルと IPv6 プロトコルの両方のソケットサイズを設定することに注意してください。
32.5.3. システム全体の TCP ソケットバッファーの増加 リンクのコピーリンクがクリップボードにコピーされました!
システム全体の TCP ソケットバッファーには、カーネルが受信したデータ、または送信する必要があるデータが一時的に保存されます。net.ipv4.tcp_rmem (読み取り) と net.ipv4.tcp_wmem (書き込み) の両方のソケットバッファーカーネル設定には、それぞれ最小値、デフォルト値、および最大値の 3 つの設定が含まれています。
バッファーサイズを大きすぎる設定にすると、メモリーが無駄に消費されます。各ソケットはアプリケーションが要求するサイズに設定でき、カーネルはこの値を 2 倍にします。たとえば、アプリケーションが 256 KiB のソケットバッファーサイズを要求し、100 万個のソケットを開く場合、システムは潜在的なソケットバッファースペースとしてのみ最大 512 GB RAM (512 KiB x 100 万) を使用できます。
さらに、最大バッファーサイズの値が大きすぎると、レイテンシーが長くなる可能性があります。
前提条件
- かなりの割合で TCP パケットがドロップされました。
手順
接続の遅延を決定します。たとえば、クライアントからサーバーに ping を実行して、平均ラウンドトリップ時間 (RTT) を測定します。
ping -c 10 server.example.com ... --- server.example.com ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 117.208/117.056/119.333/0.616 ms
# ping -c 10 server.example.com ... --- server.example.com ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 117.208/117.056/119.333/0.616 msCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、レイテンシーは 117 ミリ秒です。
次の式を使用して、チューニングするトラフィックの帯域幅遅延積 (BDP) を計算します。
connection speed in bytes * latency in ms = BDP in bytes
connection speed in bytes * latency in ms = BDP in bytesCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、レイテンシーが 117 ミリ秒の 10 Gbps 接続の BDP を計算するには、次のようにします。
(10 * 1000 * 1000 * 1000 / 8) * 117 = 10683760 bytes
(10 * 1000 * 1000 * 1000 / 8) * 117 = 10683760 bytesCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/sysctl.d/10-tcp-socket-buffers.confファイルを作成し、要件に基づいて、最大読み取りバッファーサイズまたは書き込みバッファーサイズ、またはその両方を設定します。net.ipv4.tcp_rmem = 4096 262144 21367520 net.ipv4.tcp_wmem = 4096 24576 21367520
net.ipv4.tcp_rmem = 4096 262144 21367520 net.ipv4.tcp_wmem = 4096 24576 21367520Copy to Clipboard Copied! Toggle word wrap Toggle overflow 値をバイト単位で指定します。環境に最適化された値を特定するには、以下の大体の目安を参考にしてください。
-
デフォルトのバッファーサイズ (2 番目の値): この値をわずかに増やすか、最大でも
524288(512 KiB) に設定します。デフォルトのバッファーサイズが大きすぎると、バッファーの崩壊が発生し、その結果、遅延が急増する可能性があります。 - 最大バッファーサイズ (3 番目の値): 多くの場合、BDP の 2 倍から 3 倍の値で十分です。
-
デフォルトのバッファーサイズ (2 番目の値): この値をわずかに増やすか、最大でも
/etc/sysctl.d/10-tcp-socket-buffers.confファイルから設定をロードします。sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf
# sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow より大きなソケットバッファーサイズを使用するようにアプリケーションを設定します。
net.ipv4.tcp_rmemおよびnet.ipv4.tcp_wmemパラメーターの 3 番目の値は、アプリケーションのsetsockopt()関数が要求できる最大バッファーサイズを定義します。詳細は、アプリケーションのプログラミング言語のドキュメントを参照してください。アプリケーションの開発者ではない場合は、開発者にお問い合わせください。
net.ipv4.tcp_rmemまたはnet.ipv4.tcp_wmemパラメーターの 2 番目の値を変更した場合は、新しい TCP バッファーサイズを使用するようにアプリケーションを再起動します。3 番目の値のみを変更した場合は、自動チューニングによってこれらの設定が動的に適用されるため、アプリケーションを再起動する必要はありません。
検証
- オプション: iperf3 を使用して TCP スループットをテストします。
パケットドロップが発生したときに使用したのと同じ方法を使用して、パケットドロップ統計を監視します。
パケットドロップが依然として発生するが、レートが低い場合は、バッファーサイズをさらに増やします。
32.5.4. TCP ウィンドウのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux でデフォルトで有効になっている TCP ウィンドウスケーリング機能は、スループットを大幅に向上させる TCP プロトコルの拡張機能です。
たとえば、ラウンドトリップ時間 (RTT) が 1.5 ミリ秒の 1 Gbps 接続の場合、次のようになります。
- TCP ウィンドウスケーリングを有効にすると、約 630 Mbps が現実的になります。
- TCP ウィンドウスケーリングを無効にすると、スループットは 380 Mbps に低下します。
TCP が提供する機能の 1 つはフロー制御です。フロー制御を使用すると、送信者は受信者が受信可能な量のデータを送信できますが、それ以上のデータは送信できません。これを達成するために、受信者は、送信者が送信できるデータの量である window 値をアドバタイズします。
TCP は当初、最大 64 KiB のウィンドウサイズをサポートしていましたが、帯域幅遅延積 (BDP) が高い場合、送信者が一度に 64 KiB を超えるサイズを送信できないため、この値が制限となります。高速接続では、一度に 64 KiB をはるかに超えるデータを転送できます。たとえば、システム間の遅延が 1 ms の 10 Gbps リンクでは、一度に 1 MiB を超えるデータが転送される可能性があります。ホストが 64 KiB のみを送信し、他のホストがその 64 KiB を受信するまで一時停止する場合、非効率的になります。
このボトルネックを解消するために、TCP ウィンドウスケーリング拡張機能を使用すると、TCP ウィンドウ値を左算術シフトしてウィンドウサイズを 64 KiB を超えて増やすことができます。たとえば、最大ウィンドウ値 65535 は左に 7 桁シフトし、ウィンドウサイズは 8 MiB 近くになります。これにより、一度により多くのデータを転送できるようになります。
TCP ウィンドウスケーリングは、すべての TCP 接続を開く 3 ウェイ TCP ハンドシェイク中にネゴシエートされます。この機能が動作するには、送信者と受信者の両方が TCP ウィンドウスケーリングをサポートしている必要があります。参加者の一方または両方がハンドシェイクでウィンドウスケーリング機能をアドバタイズしない場合、接続は元の 16 ビット TCP ウィンドウサイズの使用に戻ります。
デフォルトでは、TCP ウィンドウスケーリングは Red Hat Enterprise Linux で有効になっています。
sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_window_scaling = 1
# sysctl net.ipv4.tcp_window_scaling
net.ipv4.tcp_window_scaling = 1
サーバー上で TCP ウィンドウスケーリングが無効 (0) になっている場合は、設定した際と同じ方法で設定を元に戻します。
32.5.5. TCP SACK がパケットドロップ率を下げる仕組み リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL) でデフォルトで有効になっている TCP Selective Acknowledgment (TCP SACK) 機能は、TCP プロトコルの拡張機能であり、TCP 接続の効率を高めます。
TCP 送信では、受信者は受信するパケットごとに ACK パケットを送信者に送信します。たとえば、クライアントは TCP パケット 1 - 10 をサーバーに送信しますが、パケット番号 5 と 6 が失われます。TCP SACK がないと、サーバーはパケット 7 - 10 をドロップし、クライアントは損失点からすべてのパケットを再送信する必要があり、非効率的です。両方のホストで TCP SACK が有効になっている場合、クライアントは失われたパケット 5 と 6 のみを再送信する必要があります。
TCP SACK を無効にするとパフォーマンスが低下し、TCP 接続の受信側でのパケットドロップ率が高くなります。
デフォルトでは、RHEL では TCP SACK が有効になっています。確認するには、以下を実行します。
sysctl net.ipv4.tcp_sack 1
# sysctl net.ipv4.tcp_sack
1
サーバー上で TCP SACK が無効 (0) になっている場合は、設定した際と同じ方法で設定を元に戻します。
32.6. UDP 接続のチューニング リンクのコピーリンクがクリップボードにコピーされました!
UDP トラフィックのスループットを向上させるために Red Hat Enterprise Linux のチューニングを開始する前に、現実的に想定することが重要です。UDP は単純なプロトコルです。TCP と比較すると、UDP にはフロー制御、輻輳制御、データ信頼性などの機能が含まれていません。このため、ネットワークインターフェイスコントローラー (NIC) の最大速度に近いスループットレートで、UDP 経由で信頼性の高い通信を実現することが困難になります。
32.6.1. パケットドロップの検出 リンクのコピーリンクがクリップボードにコピーされました!
カーネルがパケットをドロップできるネットワークスタックには複数のレベルがあります。Red Hat Enterprise Linux は、これらのレベルの統計を表示するためのさまざまなユーティリティーを提供します。潜在的な問題を特定するためにこれらを使用してください。
ごくわずかな割合のパケットがドロップされる場合は無視できることに注意してください。ただし、大幅な割合でパケットがドロップされる場合は、チューニング措置を検討してください。
ネットワークスタックが受信トラフィックを処理できない場合、カーネルはネットワークパケットをドロップします。
手順
小さすぎるソケットバッファーまたは遅いアプリケーション処理による UDP プロトコル固有のパケットドロップを特定します。
nstat -az UdpSndbufErrors UdpRcvbufErrors #kernel UdpSndbufErrors 4 0.0 UdpRcvbufErrors 45716659 0.0
# nstat -az UdpSndbufErrors UdpRcvbufErrors #kernel UdpSndbufErrors 4 0.0 UdpRcvbufErrors 45716659 0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力の 2 番目の列にはカウンターがリストされます。
32.6.2. iperf3 を使用した UDP スループットのテスト リンクのコピーリンクがクリップボードにコピーされました!
iperf3 ユーティリティーは、サーバーモードとクライアントモードを提供し、2 つのホスト間のネットワークスループットテストを実行します。
アプリケーションのスループットは、アプリケーションが使用するバッファーサイズなど、多くの要因に依存します。したがって、iperf3 などのテストユーティリティーで測定された結果は、実稼働ワークロード下のサーバー上のアプリケーションの結果とは大きく異なる可能性があります。
前提条件
-
iperf3パッケージはクライアントとサーバーの両方にインストールされている。 - 両方のホスト上の他のサービスによって、テスト結果に大きな影響を与えるネットワークトラフィックが発生することはない。
- オプション: サーバーとクライアントの両方で最大 UDP ソケットサイズを増やしている。詳細は、Increasing the system-wide UDP socket buffers を参照してください。
手順
オプション: サーバーとクライアントの両方のネットワークインターフェイスコントローラー (NIC) の最大ネットワーク速度を表示します。
ethtool enp1s0 | grep "Speed" Speed: 10000Mb/s
# ethtool enp1s0 | grep "Speed" Speed: 10000Mb/sCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバー上では以下の設定になります。
UDP ソケット読み取りバッファーの最大サイズを表示し、値をメモします。
sysctl net.core.rmem_max net.core.rmem_max = 16777216
# sysctl net.core.rmem_max net.core.rmem_max = 16777216Copy to Clipboard Copied! Toggle word wrap Toggle overflow 表示される値はバイト単位です。
firewalldサービスでデフォルトのiperf3ポート 5201 を一時的に開きます。firewall-cmd --add-port=5201/tcp --add-port=5201/udp
# firewall-cmd --add-port=5201/tcp --add-port=5201/udpCopy to Clipboard Copied! Toggle word wrap Toggle overflow iperf3は、サーバー上の TCP ソケットのみを開くことに注意してください。クライアントが UDP を使用する場合、最初にこの TCP ポートに接続します。その後、サーバーが同じポート番号で UDP ソケットを開いて UDP トラフィックのスループットテストを実行します。このため、ローカルファイアウォールで TCP プロトコルと UDP プロトコルの両方に対してポート 5201 を開く必要があります。iperf3をサーバーモードで起動します。iperf3 --server
# iperf3 --serverCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスは受信クライアント接続を待機するようになります。
クライアントで以下を実行します。
クライアントがサーバーへの接続に使用するインターフェイスの最大伝送単位 (MTU) を表示し、その値をメモします。
ip link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 ...
# ip link show enp1s0 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow UDP ソケット書き込みバッファーの最大サイズを表示し、値をメモします。
sysctl net.core.wmem_max net.core.wmem_max = 16777216
# sysctl net.core.wmem_max net.core.wmem_max = 16777216Copy to Clipboard Copied! Toggle word wrap Toggle overflow 表示される値はバイト単位です。
スループットの測定を開始します。
iperf3 --udp --time 60 --window 16777216 --length 1472 --bitrate 2G --client 192.0.2.1
# iperf3 --udp --time 60 --window 16777216 --length 1472 --bitrate 2G --client 192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
--udp: テストには UDP プロトコルを使用します。 -
--time <seconds>: クライアントが送信を停止する時間を秒単位で定義します。 -
--window <size>: UDP ソケットのバッファーサイズを設定します。理想的には、クライアントとサーバーのサイズが同じです。それらが異なる場合は、このパラメーターを小さい方の値に設定します。クライアントではnet.core.wmem_max、サーバーではnet.core.rmem_maxです。 -
--length <size>: 読み取りおよび書き込みを行うバッファーの長さを設定します。このオプションを断片化されていない最大のペイロードに設定します。理想的な値は次のように計算します。MTU - IP ヘッダー (IPv4 の場合は 20 バイト、IPv6 の場合は 40 バイト) - 8 バイトの UDP ヘッダー。 --bitrate <rate>: ビットレートをビット/秒単位で指定した値に制限します。2 Gbps の場合は2Gなど、単位を指定できます。このパラメーターを機能すると予想される値に設定し、後の測定で値を増やします。クライアントが送信パス上のデバイスまたはサーバーが処理できる速度よりも速い速度でパケットを送信すると、パケットがドロップされる可能性があります。
-
--client <server>: クライアントモードを有効にし、iperf3サーバーを実行するサーバーの IP アドレスまたは名前を設定します。
-
iperf3がテストを完了するまで待ちます。サーバーとクライアントの両方で統計が毎秒表示され、最後に概要が表示されます。たとえば、以下はクライアントに表示される概要です。[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-60.00 sec 14.0 GBytes 2.00 Gbits/sec 0.000 ms 0/10190216 (0%) sender [ 5] 0.00-60.04 sec 14.0 GBytes 2.00 Gbits/sec 0.002 ms 0/10190216 (0%) receiver
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-60.00 sec 14.0 GBytes 2.00 Gbits/sec 0.000 ms 0/10190216 (0%) sender [ 5] 0.00-60.04 sec 14.0 GBytes 2.00 Gbits/sec 0.002 ms 0/10190216 (0%) receiverCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、平均ビットレートは 2 Gbps で、パケットの損失はありませんでした。
サーバー上では以下の設定になります。
-
Ctrl+C を押して
iperf3サーバーを停止します。 firewalldのポート 5201 を閉じます。firewall-cmd --remove-port=5201/tcp --remove-port=5201/udp
# firewall-cmd --remove-port=5201/tcp --remove-port=5201/udpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Ctrl+C を押して
32.6.3. UDP トラフィックスループットに対する MTU サイズの影響 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションが大きな UDP メッセージサイズを使用する場合、ジャンボフレームを使用するとスループットを改善できます。IEEE 802.3 標準によれば、仮想ローカルエリアネットワーク (VLAN) タグのないデフォルトのイーサネットフレームの最大サイズは 1518 バイトです。これらの各フレームには 18 バイトのヘッダーが含まれて、ペイロード用に 1500 バイトが残されます。したがって、サーバーがネットワーク経由で送信するデータの 1500 バイトごとに、18 バイト (1.2%) がオーバーヘッドになります。
ジャンボフレームは、標準のイーサネットペイロードサイズである 1500 バイトよりも大きな最大伝送単位 (MTU) を持つ非標準フレームです。たとえば、最大許容 MTU が 9000 バイトのペイロードでジャンボフレームを設定すると、各フレームのオーバーヘッドは 0.2% に減少します。
伝送パス上のすべてのネットワークデバイスと関連するブロードキャストドメインは、ジャンボフレームをサポートし、同じ MTU を使用する必要があります。伝送パス上の一貫性のない MTU 設定によるパケットの断片化と再構築により、ネットワークスループットが低下します。
接続の種類によっては、特定の MTU 制限があります。
- イーサネット: MTU は 9000 バイトに制限されます。
- データグラムモードの IP over InfiniBand (IPoIB): MTU は、InfiniBand MTU より 4 バイト小さい値に制限されます。
- インメモリーネットワークは通常、より大きな MTU をサポートします。詳細は、それぞれのドキュメントを参照してください。
32.6.4. UDP トラフィックスループットに対する CPU 速度の影響 リンクのコピーリンクがクリップボードにコピーされました!
バルク転送では、UDP プロトコルは TCP よりも効率が大幅に低くなります。これは、主に UDP でのパケット集約が欠落しているためです。デフォルトでは、Generic Receive Offload (GRO) 機能と UDP Fragmentation Offload (UFO) 機能は有効になっていません。その結果、CPU 周波数によって、高速リンクでのバルク転送の UDP スループットが制限される可能性があります。
たとえば、高い最大伝送単位 (MTU) と大きなソケットバッファーを備えたチューニングされたホストでは、3 GHz CPU が、UDP トラフィックをフルスピードで送受信する 10 GBit NIC のトラフィックを処理できます。ただし、UDP トラフィックを送信する場合は、3 GHz 未満の CPU 速度 100 MHz ごとに約 1 - 2 Gbps の速度低下が予想されます。また、3 GHz の CPU 速度がほぼ 10 Gbps に達する場合、同じ CPU は 40 GBit NIC 上の UDP トラフィックを約 20 - 25 Gbps に制限します。
32.6.5. システム全体の UDP ソケットバッファーの増加 リンクのコピーリンクがクリップボードにコピーされました!
ソケットバッファーには、カーネルが受信したデータ、または送信する必要があるデータが一時的に保存されます。
- 読み取りソケットバッファーには、カーネルが受信したがアプリケーションがまだ読み取っていないパケットが保持されます。
- 書き込みソケットバッファーには、アプリケーションがバッファーに書き込んだものの、カーネルがまだ IP スタックとネットワークドライバーに渡していないパケットが保持されます。
UDP パケットが大きすぎてバッファーサイズを超えている場合、またはパケットの送受信速度が速すぎる場合、カーネルはデータがバッファーから削除されるまで、新しい受信 UDP パケットをドロップします。この場合、ソケットバッファーを増やすことでパケットロスを防ぐことができます。
バッファーサイズを大きすぎる設定にすると、メモリーが無駄に消費されます。各ソケットはアプリケーションが要求するサイズに設定でき、カーネルはこの値を 2 倍にします。たとえば、アプリケーションが 256 KiB のソケットバッファーサイズを要求し、100 万個のソケットを開く場合、システムは潜在的なソケットバッファースペースとしてのみ 512 GB RAM (512 KiB x 100 万) を必要とします。
前提条件
- かなりの割合で UDP パケットがドロップされました。
手順
/etc/sysctl.d/10-udp-socket-buffers.confファイルを作成し、要件に基づいて最大読み取りバッファーサイズまたは書き込みバッファーサイズ、あるいはその両方を設定します。net.core.rmem_max = 16777216 net.core.wmem_max = 16777216
net.core.rmem_max = 16777216 net.core.wmem_max = 16777216Copy to Clipboard Copied! Toggle word wrap Toggle overflow 値をバイト単位で指定します。この例の値は、バッファーの最大サイズを 16 MiB に設定します。両方のパラメーターのデフォルト値は
212992バイト (208 KiB) です。/etc/sysctl.d/10-udp-socket-buffers.confファイルから設定をロードします。sysctl -p /etc/sysctl.d/10-udp-socket-buffers.conf
# sysctl -p /etc/sysctl.d/10-udp-socket-buffers.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow より大きなソケットバッファーサイズを使用するようにアプリケーションを設定します。
net.core.rmem_maxおよびnet.core.wmem_maxパラメーターは、アプリケーションのsetsockopt()関数が要求できる最大バッファーサイズを定義します。setsockopt()関数を使用しないようにアプリケーションを設定すると、カーネルはrmem_defaultおよびwmem_defaultパラメーターの値を使用することに注意してください。詳細は、アプリケーションのプログラミング言語のドキュメントを参照してください。アプリケーションの開発者ではない場合は、開発者にお問い合わせください。
- 新しい UDP バッファーサイズを使用するには、アプリケーションを再起動します。
検証
パケットドロップが発生したときに使用したのと同じ方法を使用して、パケットドロップ統計を監視します。
パケットドロップが依然として発生するが、レートが低い場合は、バッファーサイズをさらに増やします。
32.7. アプリケーション読み取りソケットバッファーのボトルネックの特定 リンクのコピーリンクがクリップボードにコピーされました!
TCP アプリケーションが読み取りソケットバッファーを十分な頻度でクリアしない場合、パフォーマンスが低下し、パケットが失われる可能性があります。Red Hat Enterprise Linux は、このような問題を特定するためのさまざまなユーティリティーを提供します。
32.7.1. 受信バッファーのコラプシングとプルーニングの特定 リンクのコピーリンクがクリップボードにコピーされました!
受信キュー内のデータが受信バッファーサイズを超えると、TCP スタックはソケットバッファーから不要なメタデータを削除して、スペースを解放しようとします。このステップはコラプシングとして知られています。
コラプシングが追加のトラフィック用に十分なスペースを解放できない場合、カーネルは着信する新しいデータをプルーニングします。これは、カーネルがメモリーからデータを削除し、パケットが失われることを意味します。
操作のコラプシングとプルーニングを回避するには、TCP バッファーのコラプシングとプルーニングがサーバー上で発生するかどうかを監視し、この場合は TCP バッファーをチューニングします。
手順
nstatユーティリティーを使用して、TcpExtTCPRcvCollapsedカウンターとTcpExtRcvPrunedカウンターをクエリーします。nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned #kernel TcpExtRcvPruned 0 0.0 TcpExtTCPRcvCollapsed 612859 0.0
# nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned #kernel TcpExtRcvPruned 0 0.0 TcpExtTCPRcvCollapsed 612859 0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow しばらく待ってから、
nstatコマンドを再実行します。nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned #kernel TcpExtRcvPruned 0 0.0 TcpExtTCPRcvCollapsed 620358 0.0
# nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned #kernel TcpExtRcvPruned 0 0.0 TcpExtTCPRcvCollapsed 620358 0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最初の実行と比較してカウンターの値が増加している場合は、チューニングが必要です。
-
アプリケーションが
setsockopt(SO_RCVBUF)呼び出しを使用している場合は、それを削除することを検討してください。この呼び出しでは、アプリケーションは呼び出しで指定された受信バッファーサイズのみを使用し、サイズを自動チューニングするソケットの機能をオフにします。 -
アプリケーションが
setsockopt(SO_RCVBUF)呼び出しを使用しない場合は、TCP 読み取りソケットバッファーのデフォルト値と最大値をチューニングします。
-
アプリケーションが
受信バックログキューを表示します (
Recv-Q)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ss -ntコマンドを、各実行の間に数秒の待ち時間を設けて複数回実行します。出力の
Recv-Q列に高い値が 1 件だけリストされている場合、アプリケーションは 2 つの受信操作の間にありました。ただし、lastrcvが継続的に増加する一方で、Recv-Qの値が一定のままである場合、またはRecv-Qが時間の経過とともに継続的に増加する場合は、次の問題のいずれかが原因である可能性があります。- アプリケーションはソケットバッファーを十分な頻度でチェックしません。この問題の解決方法の詳細は、アプリケーションのベンダーにお問い合わせください。
アプリケーションは十分な CPU 時間を取得できません。この問題をさらにデバッグするには、以下を実行します。
アプリケーションが実行されている CPU コアを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PSR列には、プロセスが現在割り当てられている CPU コアが表示されます。- 同じコア上で実行されている他のプロセスを特定し、それらを他のコアに割り当てることを検討してください。
32.8. 大量のリクエストを受信するアプリケーションのチューニング リンクのコピーリンクがクリップボードにコピーされました!
Web サーバーなど、大量の受信リクエストを処理するアプリケーションを実行する場合、パフォーマンスを最適化するために Red Hat Enterprise Linux をチューニングすることが必要になる場合があります。
32.8.1. 多数の TCP 接続試行を処理するための TCP リッスンバックログの調整 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションが LISTEN 状態で TCP ソケットを開くと、カーネルは、このソケットが処理できる許可されるクライアント接続の数を制限します。クライアントが、アプリケーションが処理できるよりも多くの接続を確立しようとすると、新しい接続が失われるか、カーネルが SYN Cookie をクライアントに送信します。
システムが通常のワークロード下にあり、正規のクライアントからの接続が多すぎるためにカーネルが SYN Cookie を送信する場合は、Red Hat Enterprise Linux (RHEL) をチューニングしてこれを回避します。
前提条件
-
RHEL は、
possible SYN flooding on port <ip_address>:<port_number>エラーメッセージを Systemd ジャーナルに記録します。 - 多数の接続試行は有効なソースからのものであり、攻撃によって引き起こされたものではありません。
手順
チューニングが必要かどうかを確認するには、影響を受けるポートの統計を表示します。
ss -ntl '( sport = :443 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 650 500 192.0.2.1:443 0.0.0.0:*
# ss -ntl '( sport = :443 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 650 500 192.0.2.1:443 0.0.0.0:*Copy to Clipboard Copied! Toggle word wrap Toggle overflow バックログ (
Recv-Q) 内の現在の接続数がソケットバックログ (Send-Q) より大きい場合、リッスンバックログはまだ十分大きくないため、チューニングが必要です。オプション: 現在の TCP リッスンバックログ制限を表示します。
sysctl net.core.somaxconn net.core.somaxconn = 4096
# sysctl net.core.somaxconn net.core.somaxconn = 4096Copy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/sysctl.d/10-socket-backlog-limit.confファイルを作成し、り大きなリッスンバックログ制限を設定します。net.core.somaxconn = 8192
net.core.somaxconn = 8192Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションは
net.core.somaxconnカーネルパラメーターで指定したよりも多くのリッスンバックログを要求することができますが、カーネルはこのパラメーターで設定した番号にアプリケーションを制限することに注意してください。/etc/sysctl.d/10-socket-backlog-limit.confファイルから設定をロードします。sysctl -p /etc/sysctl.d/10-socket-backlog-limit.conf
# sysctl -p /etc/sysctl.d/10-socket-backlog-limit.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいリッスンバックログ制限を使用するようにアプリケーションを再設定します。
-
アプリケーションが制限の config オプションを提供している場合は、それを更新します。たとえば、Apache HTTP サーバーには、このサービスのリッスンバックログ制限を設定するための
ListenBacklog設定オプションが用意されています。 - 制限を設定できない場合は、アプリケーションを再コンパイルします。
重要net.core.somaxconnカーネル設定とアプリケーションの設定の両方を常に更新する必要があります。-
アプリケーションが制限の config オプションを提供している場合は、それを更新します。たとえば、Apache HTTP サーバーには、このサービスのリッスンバックログ制限を設定するための
- アプリケーションを再起動します。
検証
-
Systemd ジャーナルを監視して、
possible SYN flooding on port <port_number>エラーメッセージがさらに発生していないかどうかを確認します。 バックログ内の現在の接続数を監視し、ソケットバックログと比較します。
ss -ntl '( sport = :443 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 500 192.0.2.1:443 0.0.0.0:*
# ss -ntl '( sport = :443 )' State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 500 192.0.2.1:443 0.0.0.0:*Copy to Clipboard Copied! Toggle word wrap Toggle overflow バックログ (
Recv-Q) 内の現在の接続数がソケットバックログ (Send-Q) より大きい場合、リッスンバックログが十分に大きくないため、さらなるチューニングが必要です。
32.9. リッスンキューのロック競合の回避 リンクのコピーリンクがクリップボードにコピーされました!
キューロックの競合により、パケットドロップや CPU 使用率の上昇を引き起こす可能性があり、その結果、レイテンシーが長くなる可能性があります。アプリケーションをチューニングし、送信パケットステアリングを使用することで、受信 (RX) キューと送信 (TX) キューでのキューロックの競合を回避できます。
32.9.1. RX キューのロック競合の回避: SO_REUSEPORT および SO_REUSEPORT_BPF ソケットオプション リンクのコピーリンクがクリップボードにコピーされました!
マルチコアシステムでは、アプリケーションが SO_REUSEPORT または SO_REUSEPORT_BPF ソケットオプションを使用してポートを開くと、マルチスレッドネットワークサーバーアプリケーションのパフォーマンスを向上することができます。アプリケーションがこれらのソケットオプションのいずれかを使用しない場合、すべてのスレッドは受信トラフィックを受信するために単一のソケットを共有するように強制されます。単一のソケットを使用すると、次のような問題が発生します。
- パケットドロップや CPU 使用率の上昇を引き起こす可能性のある受信バッファーでの重大な競合。
- CPU 使用率の大幅な増加
- パケットドロップの可能性
SO_REUSEPORT または SO_REUSEPORT_BPF ソケットオプションを使用すると、1 つのホスト上の複数のソケットを同じポートにバインドできます。
Red Hat Enterprise Linux では、カーネルソースで SO_REUSEPORT ソケットオプションを使用する方法のコードサンプルを提供します。コード例にアクセスするには、以下を実行します。
rhel-9-for-x86_64-baseos-debug-rpmsリポジトリーを有効にします。subscription-manager repos --enable rhel-9-for-x86_64-baseos-debug-rpms
# subscription-manager repos --enable rhel-9-for-x86_64-baseos-debug-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow kernel-debuginfo-common-x86_64パッケージをインストールします。dnf install kernel-debuginfo-common-x86_64
# dnf install kernel-debuginfo-common-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
コード例は
/usr/src/debug/kernel-<version>/linux-<version>/tools/testing/selftests/net/reuseport_bpf_cpu.cファイルで利用できるようになりました。
32.9.2. TX キューのロック競合の回避: 送信パケットステアリング リンクのコピーリンクがクリップボードにコピーされました!
複数のキューをサポートするネットワークインターフェイスコントローラー (NIC) を備えたホストでは、送信パケットステアリング (XPS) によって送信ネットワークパケットの処理が複数のキューに分散されます。これにより、複数の CPU が送信ネットワークトラフィックを処理できるようになり、送信キューのロック競合と、その結果として生じるパケットドロップを回避できます。
ixgbe、i40e、mlx5 などの特定のドライバーは、XPS を自動的に設定します。ドライバーがこの機能をサポートしているかどうかを確認するには、NIC ドライバーのドキュメントを参照してください。ドライバーがこの機能をサポートしているかどうかを確認するには、NIC ドライバーのドキュメントを参照してください。ドライバーが XPS 自動チューニングをサポートしていない場合は、CPU コアを送信キューに手動で割り当てることができます。
Red Hat Enterprise Linux には、送信キューを CPU コアに永続的に割り当てるオプションがありません。インターフェイスがアクティブ化されたときに実行される NetworkManager ディスパッチャースクリプト内のコマンドを使用してください。詳細は、How to write a NetworkManager dispatcher script to apply commands on interface start を参照してください。
前提条件
- NIC が複数のキューをサポートする。
-
numactlパッケージがインストールされている。
手順
使用可能なキューの数を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pre-set maximumsセクションにはキューの総数が表示され、Current hardware settingsには受信キュー、送信キュー、その他のキュー、または結合されたキューに現在割り当てられているキューの数が表示されます。オプション: 特定のチャネルにキューが必要な場合は、それに応じてキューを割り当てます。たとえば、4 つのキューを
Combinedチャネルに割り当てるには、次のように入力します。ethtool -L enp1s0 combined 4
# ethtool -L enp1s0 combined 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow NIC がどの Non-Uniform Memory Access (NUMA) ノードに割り当てられているかを表示します。
cat /sys/class/net/enp1s0/device/numa_node 0
# cat /sys/class/net/enp1s0/device/numa_node 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルが見つからない場合、またはコマンドが
-1を返す場合は、ホストは NUMA システムではありません。ホストが NUMA システムの場合は、どの CPU がどの NUMA ノードに割り当てられているかを表示します。
lscpu | grep NUMA NUMA node(s): 2 NUMA node0 CPU(s): 0-3 NUMA node1 CPU(s): 4-7
# lscpu | grep NUMA NUMA node(s): 2 NUMA node0 CPU(s): 0-3 NUMA node1 CPU(s): 4-7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上の例では、NIC には 4 つのキューがあり、NIC は NUMA ノード 0 に割り当てられています。このノードは CPU コア 0 - 3 を使用します。したがって、各送信キューを 0 - 3 の CPU コアの 1 つにマッピングします。
echo 1 > /sys/class/net/enp1s0/queues/tx-0/xps_cpus echo 2 > /sys/class/net/enp1s0/queues/tx-1/xps_cpus echo 4 > /sys/class/net/enp1s0/queues/tx-2/xps_cpus echo 8 > /sys/class/net/enp1s0/queues/tx-3/xps_cpus
# echo 1 > /sys/class/net/enp1s0/queues/tx-0/xps_cpus # echo 2 > /sys/class/net/enp1s0/queues/tx-1/xps_cpus # echo 4 > /sys/class/net/enp1s0/queues/tx-2/xps_cpus # echo 8 > /sys/class/net/enp1s0/queues/tx-3/xps_cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow CPU コアと送信 (TX) キューの数が同じ場合は、TX キューで何らかの競合が発生するのを避けるために、1 対 1 マッピングを使用してください。複数の CPU を同じ TX キューにマップすると、各 CPU の送信操作によって TX キューのロック競合が発生し、送信スループットに悪影響が発生します。
CPU のコア番号を含むビットマップをキューに渡す必要があることに注意してください。次のコマンドを使用してビットマップを計算します。
printf %x $((1 << <core_number> ))
# printf %x $((1 << <core_number> ))Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
トラフィックを送信するサービスのプロセス ID (PID) を特定します。
pidof <process_name> 12345 98765
# pidof <process_name> 12345 98765Copy to Clipboard Copied! Toggle word wrap Toggle overflow XPS を使用するコアに PID を固定します。
numactl -C 0-3 12345 98765
# numactl -C 0-3 12345 98765Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロセスがトラフィックを送信している間、
requeuesカウンターを監視します。tc -s qdisc qdisc fq_codel 0: dev enp10s0u1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 Sent 125728849 bytes 1067587 pkt (dropped 0, overlimits 0 requeues 30) backlog 0b 0p requeues 30 ...
# tc -s qdisc qdisc fq_codel 0: dev enp10s0u1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 Sent 125728849 bytes 1067587 pkt (dropped 0, overlimits 0 requeues 30) backlog 0b 0p requeues 30 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow requeuesカウンターが大幅な速度で増加しなくなると、TX キューロックの競合は発生しなくなります。
32.9.3. UDP トラフィックが多いサーバーでの汎用受信オフロード機能の無効化 リンクのコピーリンクがクリップボードにコピーされました!
高速 UDP バルク転送を使用するアプリケーションは、UDP ソケットで UDP Generic Receive Offload (GRO) を有効にして使用する必要があります。ただし、次の条件が当てはまる場合は、GRO を無効にしてスループットを向上させることができます。
- アプリケーションは GRO をサポートしていないため、機能を追加できません。
TCP スループットは関係ありません。
警告GRO を無効にすると、TCP トラフィックの受信スループットが大幅に低下します。したがって、TCP パフォーマンスが関係するホストでは GRO を無効にしないでください。
前提条件
- ホストは主に UDP トラフィックを処理している。
- アプリケーションは GRO を使用していない。
- ホストは、VXLAN などの UDP トンネルプロトコルを使用していない。
- ホストは仮想マシン (VM) やコンテナーを実行していない。
手順
オプション: NetworkManager 接続プロファイルを表示します。
nmcli connection show NAME UUID TYPE DEVICE example f2f33f29-bb5c-3a07-9069-be72eaec3ecf ethernet enp1s0
# nmcli connection show NAME UUID TYPE DEVICE example f2f33f29-bb5c-3a07-9069-be72eaec3ecf ethernet enp1s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続プロファイルで GRO サポートを無効にします。
nmcli connection modify example ethtool.feature-gro off
# nmcli connection modify example ethtool.feature-gro offCopy to Clipboard Copied! Toggle word wrap Toggle overflow 接続プロファイルを再度アクティベートします。
nmcli connection up example
# nmcli connection up exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
GRO が無効になっていることを確認します。
ethtool -k enp1s0 | grep generic-receive-offload generic-receive-offload: off
# ethtool -k enp1s0 | grep generic-receive-offload generic-receive-offload: offCopy to Clipboard Copied! Toggle word wrap Toggle overflow - サーバー上のスループットを監視します。この設定がホスト上の他のアプリケーションにマイナスの影響を与える場合は、NetworkManager プロファイルで GRO を再度有効にします。
32.10. デバイスドライバーと NIC のチューニング リンクのコピーリンクがクリップボードにコピーされました!
RHEL では、カーネルモジュールは、ネットワークインターフェイスコントローラー (NIC) 用のドライバーを提供します。これらのモジュールは、デバイスドライバーと NIC をチューニングおよび最適化するためのパラメーターをサポートしています。たとえば、ドライバーが受信割り込みの生成の遅延をサポートしている場合は、対応するパラメーターの値を減らして、受信記述子の不足を避けることができます。
すべてのモジュールがカスタムパラメーターをサポートしているわけではなく、機能はハードウェア、ドライバーおよびファームウェアのバージョンによって異なります。
32.10.1. カスタム NIC ドライバーのパラメーターの設定 リンクのコピーリンクがクリップボードにコピーされました!
多くのカーネルモジュールは、ドライバーとネットワークインターフェイスコントローラー (NIC) をチューニングするためのパラメーターの設定をサポートしています。ハードウェアやドライバーに応じて設定をカスタマイズできます。
カーネルモジュールにパラメーターを設定すると、RHEL はこれらの設定をこのドライバーを使用するすべてのデバイスに適用します。
前提条件
- ホストに NIC がインストールされている。
- NIC のドライバーを提供するカーネルモジュールは、必要なチューニング機能をサポートしている。
- ローカルでログインしているか、パラメーターを変更するドライバーを使用するネットワークインターフェイスとは異なるネットワークインターフェイスを使用してログインしている。
手順
ドライバーを特定します。
ethtool -i enp0s31f6 driver: e1000e version: ... firmware-version: ... ...
# ethtool -i enp0s31f6 driver: e1000e version: ... firmware-version: ... ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の機能には、特定のドライバーとファームウェアのバージョンが必要になる場合があることに注意してください。
カーネルモジュールの利用可能なパラメーターを表示します。
modinfo -p e1000e ... SmartPowerDownEnable:Enable PHY smart power down (array of int) parm:RxIntDelay:Receive Interrupt Delay (array of int)
# modinfo -p e1000e ... SmartPowerDownEnable:Enable PHY smart power down (array of int) parm:RxIntDelay:Receive Interrupt Delay (array of int)Copy to Clipboard Copied! Toggle word wrap Toggle overflow パラメーターの詳細は、カーネルモジュールのドキュメントを参照してください。RHEL のモジュールについては、
kernel-docパッケージで提供される/usr/share/doc/kernel-doc-<version>/Documentation/networking/device_drivers/ディレクトリーにあるドキュメントを参照してください。/etc/modprobe.d/nic-parameters.confファイルを作成し、モジュールのパラメーターを指定します。options <module_name> <parameter1>=<value> <parameter2>=<value>
options <module_name> <parameter1>=<value> <parameter2>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、ポートの省電力メカニズムを有効にし、受信割り込みの生成を 4 ユニットに設定するには、次のように入力します。
options e1000e SmartPowerDownEnable=1 RxIntDelay=4
options e1000e SmartPowerDownEnable=1 RxIntDelay=4Copy to Clipboard Copied! Toggle word wrap Toggle overflow モジュールをアンロードします。
modprobe -r e1000e
# modprobe -r e1000eCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告アクティブなネットワークインターフェイスが使用するモジュールをアンロードすると、接続が即座に終了し、サーバーからロックアウトされる可能性があります。
モジュールをロードします。
modprobe e1000e
# modprobe e1000eCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク接続を再アクティブ化します。
nmcli connection up <profile_name>
# nmcli connection up <profile_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
カーネルメッセージを表示します。
dmesg ... [35309.225765] e1000e 0000:00:1f.6: Transmit Interrupt Delay set to 16 [35309.225769] e1000e 0000:00:1f.6: PHY Smart Power Down Enabled ...
# dmesg ... [35309.225765] e1000e 0000:00:1f.6: Transmit Interrupt Delay set to 16 [35309.225769] e1000e 0000:00:1f.6: PHY Smart Power Down Enabled ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのモジュールがパラメーター設定をカーネルリングバッファーに記録するわけではないことに注意してください。
特定のカーネルモジュールは、モジュールパラメーターごとに
/sys/module/<driver>/parameters/ディレクトリーにファイルを作成します。これらの各ファイルには、このパラメーターの現在の値が含まれています。これらのファイルを表示して設定を確認できます。cat /sys/module/<driver_name>/parameters/<parameter_name>
# cat /sys/module/<driver_name>/parameters/<parameter_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
32.11. ネットワークアダプターのオフロード設定 リンクのコピーリンクがクリップボードにコピーされました!
CPU 負荷を軽減するために、特定のネットワークアダプターは、ネットワーク処理負荷をネットワークインターフェイスコントローラー (NIC) に移動するオフロード機能を使用します。たとえば、Encapsulating Security Payload (ESP) オフロードを使用すると、NIC は ESP 操作を実行して、IPsec 接続を高速化し、CPU 負荷を軽減します。
デフォルトでは、Red Hat Enterprise Linux のほとんどのオフロード機能が有効になっています。次の場合にのみ無効にしてください。
- トラブルシューティングの目的でオフロード機能を一時的に無効にします。
- 特定の機能がホストに悪影響を与える場合は、オフロード機能を永続的に無効にします。
ネットワークドライバーでパフォーマンス関連のオフロード機能がデフォルトで有効になっていない場合は、手動で有効にすることができます。
32.11.1. オフロード機能の一時的な設定 リンクのコピーリンクがクリップボードにコピーされました!
オフロード機能によって問題が発生したり、ホストのパフォーマンスが低下したりすると予想される場合は、現在の状態に応じて、オフロード機能を一時的に有効または無効にして、原因の絞り込みを試みることができます。
オフロード機能を一時的に有効または無効にすると、次回の再起動時に以前の値に戻ります。
前提条件
- ネットワークカードがオフロード機能をサポートしている。
手順
インターフェイスで利用可能なオフロード機能とその現在の状態を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力はハードウェアとそのドライバーの機能によって異なります。
[fixed]のフラグが付いている機能の状態は変更できないことに注意してください。オフロード機能を一時的に無効にします。
ethtool -K <interface> <feature> [on|off]
# ethtool -K <interface> <feature> [on|off]Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
enp10s0u1インターフェイスで IPsec Encapsulating Security Payload (ESP) オフロードを一時的に無効にするには、次のように入力します。ethtool -K enp10s0u1 esp-hw-offload off
# ethtool -K enp10s0u1 esp-hw-offload offCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
enp10s0u1インターフェイスで Receive Flow Steering (aRFS) フィルタリングを一時的に有効にするには、次のように入力します。ethtool -K enp10s0u1 ntuple-filters on
# ethtool -K enp10s0u1 ntuple-filters onCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
オフロード機能の状態を表示します。
ethtool -k enp1s0 ... esp-hw-offload: off ntuple-filters: on ...
# ethtool -k enp1s0 ... esp-hw-offload: off ntuple-filters: on ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow オフロード機能を変更する前に発生した問題がまだ存在するかどうかをテストします。
特定のオフロード機能を変更した後に問題が解消された場合は、次のようにします。
- Red Hat サポート に連絡して問題を報告してください。
- 修正が利用可能になるまで、オフロード機能を永続的に設定すること を検討してください。
特定のオフロード機能を無効にしても問題が解決しない場合は、以下を実行します。
-
ethtool -K <interface> <feature> [on|off]コマンドを使用して、設定を前の状態にリセットします。 - 異なるオフロード機能を有効または無効にして、問題を絞り込みます。
-
32.11.2. オフロード機能の永続的な設定 リンクのコピーリンクがクリップボードにコピーされました!
ホストのパフォーマンスを制限する特定のオフロード機能を特定した場合は、現在の状態に応じて、それを永続的に有効または無効にすることができます。
オフロード機能を永続的に有効または無効にすると、NetworkManager は再起動後もその機能がこの状態のままであることを確認します。
前提条件
- ホスト上のパフォーマンスを制限する特定のオフロード機能を特定している。
手順
オフロード機能の状態を変更するネットワークインターフェイスを使用する接続プロファイルを特定します。
nmcli connection show NAME UUID TYPE DEVICE Example a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1ss0 ...
# nmcli connection show NAME UUID TYPE DEVICE Example a5eb6490-cc20-3668-81f8-0314a27f3f75 ethernet enp1ss0 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow オフロード機能の状態を永続的に変更します。
nmcli connection modify <connection_name> <feature> [on|off]
# nmcli connection modify <connection_name> <feature> [on|off]Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
Example接続プロファイルで IPsec Encapsulating Security Payload (ESP) オフロードを永続的に無効にするには、次のように入力します。nmcli connection modify Example ethtool.feature-esp-hw-offload off
# nmcli connection modify Example ethtool.feature-esp-hw-offload offCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
Example接続プロファイルでアクセラレート Receive Flow Steering (aRFS) フィルタリングを永続的に有効にするには、次のように入力します。nmcli connection modify Example ethtool.feature-ntuple on
# nmcli connection modify Example ethtool.feature-ntuple onCopy to Clipboard Copied! Toggle word wrap Toggle overflow
接続プロファイルを再度アクティベートします。
nmcli connection up Example
# nmcli connection up ExampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
オフロード機能の出力状態を表示します。
ethtool -k enp1s0 ... esp-hw-offload: off ntuple-filters: on ...
# ethtool -k enp1s0 ... esp-hw-offload: off ntuple-filters: on ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
32.12. 割り込み結合設定のチューニング リンクのコピーリンクがクリップボードにコピーされました!
割り込み結合は、ネットワークカードによって生成される割り込みの数を減らすためのメカニズムです。一般に、割り込みが少なくなると、ネットワークのレイテンシーと全体的なパフォーマンスが向上します。
割り込み結合設定のチューニングには、以下を制御するパラメーターの調整が含まれます。
- 1 つの割り込みに結合されるパケットの数。
- 割り込みを生成するまでの遅延。
最適な結合設定は、特定のネットワーク条件と使用しているハードウェアによって異なります。したがって、環境とニーズに最適な設定を見つけるには、何度か試すことが必要な場合があります。
32.12.1. 遅延またはスループットの扱いに注意が必要なサービス向けに RHEL を最適化する リンクのコピーリンクがクリップボードにコピーされました!
結合チューニングの目標は、特定のワークロードに必要な割り込みの数を最小限に抑えることです。高スループットの状況では、高いデータレートを維持しながら、割り込みをできるだけ少なくすることが目標となります。待ち時間が短い状況では、より多くの割り込みを使用してトラフィックを迅速に処理できます。
ネットワークカードの設定を調整して、1 つの割り込みに結合されるパケットの数を増減できます。その結果、トラフィックのスループットまたは遅延を向上させることができます。
手順
ボトルネックが発生しているネットワークインターフェイスを特定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 名前に
drop、discardまたはerrorを含むパケットカウンターを特定します。これらの特定の統計は、ネットワークインターフェイスカード (NIC) の結合によって発生する可能性がある、NIC のパケットバッファーでの実際のパケットロスを測定します。前の手順で特定したパケットカウンターの値を監視します。
これらをネットワークの予想値と比較して、特定のインターフェイスにボトルネックが発生しているかどうかを判断します。ネットワークのボトルネックの一般的な兆候には次のようなものがありますが、これらに限定されません。
- ネットワークインターフェイス上での多数のエラー
- 高いパケットロス
ネットワークインターフェイスの多用
注記ネットワークのボトルネックを特定する際のその他の重要な要素としては、CPU 使用率、メモリー使用率、ディスク I/O などがあります。
現在の割り込み結合設定を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
usecs値は、受信機または送信機が割り込みを生成する前に待機するマイクロ秒数を指します。 -
frames値は、受信機または送信機が割り込みを生成する前に待機するフレーム数を指します。 irq値は、ネットワークインターフェイスがすでに割り込みを処理している場合に、割り込み調整を設定するために使用されます。注記すべてのネットワークインターフェイスカードが、出力例のすべての値のレポートと変更をサポートしているわけではありません。
-
Adaptive RX/TX値は、割り込み結合設定を動的に調整する適応割り込み結合メカニズムを表します。Adaptive RX/TXが有効な場合、NIC ドライバーはパケット条件に基づいて、結合値を自動計算します (アルゴリズムは NIC ドライバーごとに異なります)。
-
必要に応じて結合設定を変更します。以下に例を示します。
ethtool.coalesce-adaptive-rxが無効になっている間に、RX パケットの割り込みを生成するまでの遅延を 100 マイクロ秒に設定するようにethtool.coalesce-rx-usecsを設定します。nmcli connection modify enp1s0 ethtool.coalesce-rx-usecs 100
# nmcli connection modify enp1s0 ethtool.coalesce-rx-usecs 100Copy to Clipboard Copied! Toggle word wrap Toggle overflow ethtool.coalesce-rx-usecsがデフォルト値に設定されている間、ethtool.coalesce-adaptive-rxを有効にします。nmcli connection modify enp1s0 ethtool.coalesce-adaptive-rx on
# nmcli connection modify enp1s0 ethtool.coalesce-adaptive-rx onCopy to Clipboard Copied! Toggle word wrap Toggle overflow Adaptive-RX 設定を次のように変更します。
-
低レイテンシー (50us 未満) が気になるユーザーは、
Adaptive-RXを有効にしないでください。 -
スループットを懸念するユーザーは、おそらく問題なく
Adaptive-RXを有効にすることができます。適応割り込み結合メカニズムを使用したくない場合は、ethtool.coalesce-rx-usecsに 100us や 250us などの大きな値を設定してみることができます。 - 自分のニーズがわからないユーザーは、問題が発生するまでこの設定を変更しないでください。
-
低レイテンシー (50us 未満) が気になるユーザーは、
接続を再度有効にします。
nmcli connection up enp1s0
# nmcli connection up enp1s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ネットワークパフォーマンスを監視し、ドロップされたパケットを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow rx_errors、rx_dropped、tx_errors、およびtx_droppedフィールドの値は 0 またはそれに近い値 (ネットワークトラフィックとシステムリソースに応じて最大数百まで) である必要があります。これらのフィールドの値が高い場合は、ネットワークに問題があることを示します。カウンターには異なる名前を付けることができます。名前に "drop"、"discard"、または "error" を含むパケットカウンターを注意深く監視します。rx_packets、tx_packets、rx_bytes、およびtx_bytesの値は時間の経過とともに増加します。値が増加しない場合は、ネットワークに問題がある可能性があります。パケットカウンターは、NIC ドライバーに応じて異なる名前を持つことができます。重要ethtoolコマンドの出力は、使用している NIC とドライバーによって異なる場合があります。極めて低いレイテンシーを重視するユーザーは、監視目的でアプリケーションレベルのメトリクスまたはカーネルパケットタイムスタンプ API を使用できます。
32.13. TCP タイムスタンプの利点 リンクのコピーリンクがクリップボードにコピーされました!
TCP タイムスタンプは、TCP ヘッダー内のオプションの情報であり、TCP プロトコルの拡張機能です。Red Hat Enterprise Linux ではデフォルトで TCP タイムスタンプが有効になっており、カーネルは TCP タイムスタンプを使用して、TCP 接続のラウンドトリップ時間 (RTT) をより適切に推定します。これにより、TCP ウィンドウとバッファーの計算がより正確になります。
さらに、TCP タイムスタンプは、セグメントの寿命と順序を判断し、ラップされたシーケンス番号から保護するための代替方法を提供します。TCP パケットヘッダーは、32 ビットフィールドにシーケンス番号を記録します。10 Gbps 接続では、このフィールドの値は 1.7 秒後にラップされる可能性があります。TCP タイムスタンプがないと、受信側はラップされたシーケンス番号を持つセグメントが新しいセグメントか古い重複かを判断できません。ただし、TCP タイムスタンプを使用すると、受信側はセグメントを受信するか破棄するかを正しく選択できます。したがって、高速ネットワークインターフェイスを備えたシステムでは TCP タイムスタンプを有効にすることが不可欠です。
net.ipv4.tcp_timestamps カーネルパラメーターには、次のいずれかの値を指定できます。
-
0: TCP タイムスタンプは無効化されています。 -
1: TCP タイムスタンプは有効化されています (デフォルト)。 2: TCP タイムスタンプは有効ですが、ランダムオフセットはありません。重要各接続のランダムなオフセットがなければ、ホストの大体の稼働時間とフィンガープリントを決定し、この情報を攻撃に使用することが可能です。
デフォルトでは、Red Hat Enterprise Linux では TCP タイムスタンプが有効になっており、現在の時刻のみを保存するのではなく、接続ごとにランダムなオフセットを使用します。
sysctl net.ipv4.tcp_timestamps net.ipv4.tcp_timestamps = 1
# sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_timestamps パラメーターの値がデフォルト (1) と異なる場合は、設定したときと同じ方法で設定を元に戻します。
32.14. イーサネットネットワークのフロー制御 リンクのコピーリンクがクリップボードにコピーされました!
イーサネットリンクで、ネットワークインターフェイスとスイッチポートの間で継続的にデータ送信が行われると、バッファー容量がいっぱいになる可能性があります。バッファー容量がいっぱいになると、ネットワークの輻輳が発生します。この場合、送信側が受信側の処理能力よりも高いレートでデータを送信すると、パケットロスが発生する可能性があります。リンクの反対側のネットワークインターフェイス (スイッチポート) のデータ処理能力が低いためです。
フロー制御メカニズムは、送信側と受信側の送受信能力がそれぞれ異なるイーサネットリンクを介したデータ送信を管理します。パケットロスを回避するために、イーサネットフロー制御メカニズムはパケット送信を一時的に停止し、スイッチポート側の高い伝送レートを制御します。なお、スイッチがスイッチポートを越えてポーズフレームを転送することはありません。
受信 (RX) バッファーがいっぱいになると、受信側は送信側にポーズフレームを送信します。その後、送信側は、1 秒未満の短い期間、データ送信を停止しますが、この一時停止期間中は受信データのバッファリングを続けます。この期間は、受信側がインターフェイスバッファーを空にして、バッファーオーバーフローを防ぐのに十分な時間を提供します。
イーサネットリンクのどちら側も、ポーズフレームを反対側に送信できます。ネットワークインターフェイスの受信バッファーがいっぱいになると、ネットワークインターフェイスはポーズフレームをスイッチポートに送信します。同様に、スイッチポートの受信バッファーがいっぱいになると、スイッチポートはネットワークインターフェイスにポーズフレームを送信します。
デフォルトでは、Red Hat Enterprise Linux のほとんどのネットワークドライバーではポーズフレームのサポートが有効になっています。ネットワークインターフェイスの現在の設定を表示するには、次のように入力します。
スイッチのベンダーに問い合わせて、スイッチがポーズフレームをサポートしているかどうかを確認してください。
第33章 I/O およびファイルシステムパフォーマンスに影響を与える要因 リンクのコピーリンクがクリップボードにコピーされました!
ストレージおよびファイルシステムパフォーマンスに適した設定は、ストレージの目的より大きく左右されます。
I/O およびファイルシステムのパフォーマンスは、以下のいずれかの要因により影響を受ける可能性があります。
- データの書き込みまたは読み取りパターン
- 順次または無作為
- バッファーまたはダイレクト IO
- 基礎となるジオメトリーとのデータ調整
- ブロックサイズ
- ファイルシステムのサイズ
- ジャーナルサイズおよび場所
- アクセス時間の記録
- データの信頼性確保
- 事前にフェッチするデータ
- ディスク領域の事前割り当て
- ファイルの断片化
- リソースの競合
33.1. I/O およびファイルシステムの問題を監視および診断するツール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 9 では、システムパフォーマンスを監視し、I/O、ファイルシステム、その設定に関連するパフォーマンス問題を診断するために、以下のツールを利用できます。
-
vmstatツールは、システム全体のプロセス、メモリー、ページング、ブロック I/O、割り込み、および CPU アクティビティーに関する報告を行います。管理者はこのツールを使用することで、パフォーマンスの問題が I/O サブシステムによるものかを判断しやすくなります。vmstatを使用した分析で、I/O サブシステムが原因でパフォーマンスが低下していることがわかった場合に、管理者はiostatツールを使用して原因となる I/O デバイスを判別できます。 -
iostatは、システムでの I/O デバイスの負荷を報告します。このツールはsysstatパッケージで提供されます。 -
blktraceは、I/O サブシステムでの時間の使用に関する詳細にわたる情報を提供します。同梱のユーティリティーであるblkparseは、blktraceからのロー出力を読み取り、blktraceが記録した入出力操作を人間が判読できるようにまとめます。 bttはblktrace出力を分析し、I/O スタックのエリアごとにデータが費やした時間を表示するので、I/O サブシステムのボトルネックを見つけやすくなります。このユーティリティーは、blktraceパッケージの一部として提供されます。blktraceメカニズムで追跡され、bttが分析する重要なイベントには、以下のようなものがあります。-
I/O イベント (
Q) のキュー -
ドライバーイベント (
D) への I/O のディスパッチ -
I/O イベントの完了 (
C)
-
I/O イベント (
-
iowatcherはblktrace出力を使用して、I/O を経時的にグラフ化できます。このツールは、ディスク I/O の論理ブロックアドレス (LBA)、1 秒あたりのスループット (メガバイト単位)、シーク数および I/O 操作に重点を置いています。これを使用することで、デバイスの演算回数の上限に到達するタイミングを判断しやすくなります。 BPF コンパイラーコレクション (BCC) は、
eBPF(extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。eBPFプログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。BCC ツールは、/usr/share/bcc/tools/ディレクトリーにインストールされます。以下のbcc-toolsは、パフォーマンスの分析に役立ちます。-
biolatencyは、ブロックデバイス I/O(ディスク I/O) のレイテンシーをヒストグラムにまとめています。これにより、デバイスのキャッシュヒット、キャッシュミス、レイテンシーアウトライナーの 2 つのモードなど、分散を調査できます。 -
biosnoopは、基本的なブロック I/O 追跡ツールで、各 I/O イベントの表示、プロセス ID および I/O レイテンシーの発行を行います。このツールを使用して、ディスク I/O パフォーマンスの問題を調査できます。 -
biotopは、カーネルのブロック I/O 操作に使用します。 -
filelifeツールは、stat()システムコールを追跡します。 -
fileslowerは、読み取りと書き込みが遅い同期ファイルを追跡します。 -
filetopは、プロセスによるファイルの読み取りと書き込みを表示します。 ext4slower、nfsslowerおよびxfsslowerは、特定のしきい値よりも操作速度の遅いファイルを表示するツールです (デフォルト値10ms)。詳細は、BPF コンパイラーコレクションでシステムパフォーマンスの分析 を参照してください。
-
-
bpftaceは、パフォーマンスの問題の分析に使用されるeBPFのトレース言語です。また、システムの監査用に BCC のような追跡ユーティリティーが含まれており、I/O のパフォーマンスの問題を調査するのに役立ちます。 以下の
SystemTapスクリプトは、ストレージまたはファイルシステムのパフォーマンスの問題の診断に役立ちます。-
disktop.stp: 5 秒ごとにディスクの読み取りまたは書き込みのステータスを確認し、その期間の上位 10 エントリーを出力します。 -
iotime.stp: 読み取り、書き込み操作に使用した時間、読み取りおよび書き込みバイト数を出力します。 -
traceio.stp: 確認された累積 I/O トラフィックに基づいて上位 10 の実行可能ファイルを秒単位で出力します。 -
traceio2.stp: 指定したデバイスに読み取りおよび書き込みが行われると、実行可能ファイル名とプロセス ID を出力します。 -
inodewatch.stp: 指定したメジャー/マイナーデバイスで、指定の inode に対して読み取りまたは書き込みが行われるたびに、実行可能ファイル名とプロセス ID を出力します。 -
inodewatch2.stp: 指定したメジャー/マイナーデバイスの指定の inode で属性が変更されるたびに、実行可能ファイル名とプロセス ID、属性を出力します。
-
33.2. ファイルシステムのフォーマットに利用可能なチューニングオプション リンクのコピーリンクがクリップボードにコピーされました!
一部のファイルシステム設定は一旦決定すると、デバイスのフォーマット後に変更できません。
以下は、ストレージデバイスをフォーマットする前に利用可能なオプションです。
Size (サイズ)- ワークロードに適したサイズのファイルシステムを作成します。ファイルシステムが小さいと、ファイルシステムのチェックにかかる時間とメモリーが少なくて済みます。ただし、ファイルシステムが小さすぎると、断片化が多くなり、パフォーマンスが低下します。
ブロックサイズブロックは、ファイルシステムの作業単位です。ブロックサイズで、単一のブロックに保存可能なデータ量が決まるので、1 度に書き込みまたは読み取りされる最小データ量を指します。
デフォルトのブロックサイズは、ほとんどのユースケースに適しています。ただし、ブロックサイズや複数のブロックのサイズが、一般的に一度に読み取る/書き込むデータ量と同じか、若干多い場合には、ファイルシステムのパフォーマンスは向上し、データの保存をより効率的に行います。ファイルが小さい場合は、引き続きブロック全体を使用します。ファイルは複数のブロックに分散できますが、ランタイム時のオーバーヘッドが増える可能性があります。
また、ファイルシステムによっては、特定のブロック数が上限となっており、ファイルシステムの最大数が制限されます。
mkfsコマンドでデバイスをフォーマットする時に、ファイルシステムのオプションの一部としてブロックサイズを指定します。ブロックサイズを指定するパラメーターは、ファイルシステムによって異なります。ジオメトリーファイルシステムジオメトリーは、ファイルシステム全体でのデータの分散に関係があります。システムで RAID などのストライプ化ストレージを使用する場合は、デバイスのフォーマット時にデータおよびメタデータを下層にあるストレージジオメトリーに合わせて調整することで、パフォーマンスを向上させることができます。
多くのデバイスは推奨のジオメトリーをエクスポートし、デバイスが特定のファイルシステムでフォーマットされるとそのジオメトリーが自動的に設定されます。デバイスでこのような推奨ジオメトリーをエクスポートしない場合や、推奨の設定を変更する場合には、
mkfsコマンドでデバイスのフォーマット時にジオメトリーを指定する必要があります。ファイルシステムのジオメトリーを指定するパラメーターは、ファイルシステムによって異なります。
外部ジャーナル- ジャーナリングファイルシステムは、操作を実行する前に、ジャーナルファイルに書き込み操作中に加えられる変更を文書化します。これにより、システムクラッシュや電源異常の発生時にストレージデバイスが破損する可能性が低下し、復旧プロセスが高速化されます。
Red Hat では、外部ジャーナルオプションの使用は推奨していません。
メタデータ集約型のワークロードでは、ジャーナルへの更新頻度が非常に多くなります。ジャーナルが大きいと、より多くのメモリーを使用しますが、書き込み操作の頻度は低減します。さらに、プライマリーストレージと同じか、それ以上の速度の専用ストレージにジャーナルを配置することで、メタデータ集約型のワークロードでデバイスのシーク時間を短縮できます。
外部ジャーナルが信頼できることを確認します。外部ジャーナルデバイスが損失すると、ファイルシステムが破損します。外部ジャーナルは、フォーマット時に作成し、マウント時にジャーナルデバイスを指定する必要があります。
33.3. ファイルシステムのマウントに利用可能なチューニングオプション リンクのコピーリンクがクリップボードにコピーされました!
以下は、ほとんどのファイルシステムで利用可能なオプションで、デバイスのマウント時に指定できます。
Access Timeファイルが読み込まれるたびに、ファイルのメタデータはアクセス時点で更新されます (
atime)。この際、追加の書き込み I/O が行われます。ほとんどのファイルシステムのatimeのデフォルト設定はrelatimeです。ただし、このメタデータの更新に時間がかかる場合で正確なアクセス時間データが必要ない場合には、
noatimeマウントオプションを指定してファイルシステムをマウントしてください。この設定で、ファイルの読み取り時にメタデータへの更新が無効になります。また、nodiratime動作も有効にし、ディレクトリーの読み取り時にメタデータへの更新を無効にします。
noatime mount オプションを使用して atime の更新を無効にすると、バックアッププログラムなどに依存するアプリケーションが破損する可能性があります。
read-aheadRead-ahead動作では、すぐに必要となる可能性の高いデータを事前にフェッチし、ページキャッシュ (ディスク上にある場合よりも早くデータを取得可能) に読み込むことでファイルのアクセス時間を短縮します。read-ahead 値が大きいほど、さらに事前にシステムのデータがフェッチされます。Red Hat Enterprise Linux は、ファイルシステムについて検出した内容に基づいて、適切な read-ahead 値の設定を試みます。ただし、正確な検出が常に可能であるとは限りません。たとえば、ストレージアレイが単一の LUN としてシステムに表示した場合に、システムはその単一の LUN を検出するので、アレイに適した read-ahead 値は設定されません。
連続 I/O を大量にストリーミングするワークロードは、read-ahead 値を高くすると効果がある場合が多いです。Red Hat Enterprise Linux で提供されるストレージ関連の tuned プロファイルは、LVM ストライプ化と同様に read-ahead 値を増やしますが、このような調整は、ワークロードすべてで常に十分であるというわけではありません。
33.4. 未使用ブロックの破棄の種類 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムで未使用のブロックを破棄することは、ソリッドステートディスクおよびシンプロビジョニングストレージのいずれの場合でも推奨のプラクティスです。
以下は、未使用のブロックを破棄する 2 つの方法です。
バッチ破棄-
fstrimコマンドに、このタイプの破棄が含まれています。ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。Red Hat Enterprise Linux 9 は、XFS および ext4 でフォーマットされおり、物理的な破棄操作に対応するデバイスでのバッチ破棄をサポートします。 オンライン破棄このタイプの破棄操作は、discard オプションを指定してマウント時に設定します。この操作は、ユーザーの介入なしにリアルタイムで実行されます。ただし、未使用から空き状態に移行しているブロックのみを破棄します。Red Hat Enterprise Linux 9 では XFS および ext4 フォーマットのデバイスでオンライン破棄をサポートしています。
Red Hat は、パフォーマンスを維持するためにオンライン破棄が必要な場合や、システムのワークロードでバッチ破棄を実行できない場合を除き、バッチ破棄を推奨します。
事前割り当てでは、領域にデータを書き込むことなく、ファイルに割り当て済みとしてディスク領域をマークします。これは、データの断片化や、読み取りのパフォーマンスの低下を抑える場合に役立ちます。Red Hat Enterprise Linux 9 は、XFS、ext4、および GFS2 ファイルシステムでの領域の事前割り当てに対応します。アプリケーションは、fallocate(2) glibc 呼び出しを使用して、事前割り当てした領域の利点を活用することもできます。
33.5. ソリッドステートディスクの調整に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
ソリッドステートディスク (SSD) は、回転磁気プラッターではなく、NAND フラッシュチップを使用して永続データを保存します。SSD は、完全な論理ブロックアドレス範囲のデータにアクセスする時間を一定に保ち、回転プラッターのように、測定できるレベルでシーク数を犠牲にすることがありません。ギガバイト単位のストレージ領域としてはより高価で、ストレージ密度が少なくなっていますが、HDD に比べ、レイテンシーが低く、スループットが高くなっています。
SSD の使用済みのブロックが、ディスク容量を占有してくると、通常パフォーマンスは低下します。パフォーマンスの低下レベルはベンダーによって異なりますが、このような状況では、すべてのデバイスでパフォーマンスが低下します。破棄動作を有効にすると、この低下を軽減できます。詳細は、未使用ブロックの破棄の種類 を参照してください。
デフォルトの I/O スケジューラーおよび仮想メモリーオプションは、SSD での使用に適しています。設定時には、SSD のパフォーマンスに影響を与える可能性がある以下の要素を考慮してください。
I/O スケジューラーI/O スケジューラーはどれでも、ほとんどの SSD で適切に動作することが想定されます。ただし、他のストレージタイプと同様に、特定のワークロードに対する最適な設定を決定するためにベンチマーク評価を行うことを推奨します。SSD を使用する場合、I/O スケジューラーの変更は特定のワークロードのベンチマーク評価を行う場合に限ることを推奨しています。I/O スケジューラー間の切り替え方法は、
/usr/share/doc/kernel-version/Documentation/block/switching-sched.txtファイルを参照してください。単一キュー HBA の場合は、デフォルトの I/O スケジューラーは
deadlineです。複数のキュー HBA の場合は、デフォルトの I/O スケジューラーはnoneです。I/O スケジューラーの設定方法は、ディスクスケジューラーの設定 を参照してください。仮想メモリー-
I/O スケジューラーと同様に、仮想メモリー (VM) サブシステムには特別なチューニングは必要ありません。SSD の I/O が高速であるという性質をもとに、
vm_dirty_background_ratioとvm_dirty_ratio設定の値を下げ、書き出しのアクティビティーが増えても通常は、ディスクの他の操作のレイテンシーに悪影響はありません。ただし、このチューニングで全体的な I/O が生み出されるので、ワークロード固有のテストがない場合には通常推奨していません。 スワップ- SSD はスワップデバイスとしても使用でき、ページアウトおよびページインのパフォーマンスが向上する可能性が高くなります。
33.6. 汎用ブロックデバイスのチューニングパラメーター リンクのコピーリンクがクリップボードにコピーされました!
ここにリストされている一般的なチューニングパラメーターは、/sys/block/sdX/queue/ ディレクトリーにあります。
以下のチューニングパラメーターは、I/O スケジューラーチューニングとは別のパラメーターで、全 I/O スケジューラーに適用されます。
add_random-
一部の I/O イベントは、
/dev/randomのエントロピープールに貢献します。これらの貢献のオーバーヘッドが測定できるレベルになった場合には、このパラメーターを0に設定してください。 iostatsデフォルトでは、
iostatsは有効で、デフォルト値は1です。iostats値を0に設定すると、デバイスの I/O 統計の収集が無効になり、I/O パスでのオーバーヘッドが少し削除されます。また、iostatsを0に設定すると、特定の NVMe ソリッドステートストレージデバイスなど、非常に高性能なデバイスのパフォーマンスが若干向上します。特定のストレージモデルで無効にするようにベンダーからの指示がない限り、iostatsは有効のままにしておくことを推奨します。iostatsを無効にすると、デバイスの I/O 統計が/proc/diskstatsファイルからなくなります。I/O 情報は、/sys/diskstatsファイルの内容をソースとしており、sarやiostatsなどの I/O ツールの監視に使用します。したがって、デバイスのiostatsパラメーターを無効にすると、デバイスは I/O 監視ツールの出力に表示されなくなります。max_sectors_kbI/O 要求の最大サイズを KB 単位で指定します。デフォルト値は
512KB です。このパラメーターの最小値は、ストレージデバイスの論理ブロックサイズで決まります。このパラメーターの最大値は、max_hw_sectors_kbの値で決まります。Red Hat は、
max_sectors_kbを常に最適な I/O サイズと内部消去ブロックサイズの倍数にするように推奨しています。0 が指定されているか、ストレージデバイスによる指定がない場合には、どちらかのパラメーターのlogical_block_sizeの値を使用します。nomerges-
要求をマージは、ほとんどのワークロードで有用です。ただし、デバッグの目的では、マージを無効にすると便利です。デフォルトでは、
nomergesパラメーターは0に設定されており、マージが有効です。単純な 1 回だけのマージを無効にするにはnomergesを1に設定します。すべてのタイプのマージを無効にするには、nomergesを2に設定します。 nr_requests-
キューに配置可能な最大 I/O 数です。現在の I/O スケジューラーが
noneの場合は、この数値を減らすことができますが、それ以外の場合は数字の増減が可能です。 optimal_io_size- このパラメーターで最適な I/O サイズを報告するストレージデバイスもあります。この値が報告される場合は、できるだけ報告された最適な I/O サイズに合わせその倍数の I/O をアプリケーションで発行させることを推奨しています。
read_ahead_kb連続読み込み操作中にオペレーティングシステムが読み取ることができる最大キロバイト数を定義します。その結果、必要な情報は、次の連続読み込みのカーネルページキャッシュにすでに存在するので、読み取り I/O のパフォーマンスが向上します。
read_ahead_kbの値を大きくすると、デバイスマッパーは効果を得られます。開始点として、各デバイスに対して128KB の値に指定すると適切です。ディスクのread_ahead_kbの値を、要求キューのディスクのmax_sectors_kbまで増やすと、大型のファイルの連続読み込みが行われるアプリケーション環境でパフォーマンスが向上する可能性があります。rotational-
一部のソリッドステートディスクは、ソリッドステートのステータスを正しく公開せず、従来の回転ディスクとしてマウントされます。スケジューラーで不要なシーク時間短縮ロジックを無効にするには、
rotationalの値を0に手動で設定します。 rq_affinity-
rq_affinityのデフォルト値は1です。これは、発行した CPU コアと同じ CPU グループにある CPU コア 1 つで I/O 操作を完了します。I/O 要求を発行したプロセッサーでのみ I/O 操作を完了するには、rq_affinityを2に設定します。上記の 2 つの機能を無効にするには、0に設定します。 scheduler-
特定のストレージデバイスにスケジューラーまたはスケジューラーの優先度を設定するには、
/sys/block/devname/queue/schedulerファイルを編集します。ここで、devname は設定するデバイスの名前に置き換えます。
第34章 systemd を使用してアプリケーションが使用するリソースを管理する リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 では、cgroup 階層のシステムを systemd ユニットツリーにバインドすることにより、リソース管理設定をプロセスレベルからアプリケーションレベルに移行します。したがって、システムリソースは、systemctl コマンドを使用するか、systemd ユニットファイルを変更して管理できます。
これを実現するために、systemd はユニットファイルから、または systemctl コマンドを介して直接さまざまな設定オプションを取得します。次に、systemd は、Linux カーネルシステムコールと cgroups や namespaces などの機能を使用して、これらのオプションを特定のプロセスグループに適用します。
次のマニュアルページで、systemd の設定オプションの完全なセットを確認できます。
-
systemd.resource-control(5) -
systemd.exec(5)
34.1. リソース管理における systemd のロール リンクのコピーリンクがクリップボードにコピーされました!
systemd のコア機能は、サービスの管理と監視です。systemd システムとサービスマネージャーは以下のことを行います。
- ブートプロセス中に、適切なタイミングで正しい順序で管理対象サービスを起動します。
- 管理対象サービスをスムーズに実行し、サービスが基盤となるハードウェアプラットフォームを最適に使用できるようにします。
- リソース管理ポリシーを定義する機能を提供します。
- サービスのパフォーマンスを向上できる、さまざまなオプションを調整する機能を提供します。
一般に、Red Hat では、システムリソースの使用を制御するために systemd を使用することを推奨します。特別な場合にのみ、cgroups 仮想ファイルシステムを手動で設定する必要があります。たとえば、cgroup-v2 階層に同等のものがない cgroup-v1 コントローラーを使用する必要がある場合です。
34.2. システムソースの配分モデル リンクのコピーリンクがクリップボードにコピーされました!
システムリソースの配分を変更するには、以下の配分モデルの 1 つまたは複数を適用できます。
- 重み
全サブグループの重みを合計し、各サブグループに、合計に対する重み比率に応じたリソースを配分します。
たとえば、10 個の cgroup があり、それぞれの重みが 100 の場合、合計は 1000 になります。各 cgroup は、リソースの 10 分の 1 を受け取ります。
重みは通常、ステートレスリソースの配分に使用されます。たとえば、CPUWeight= オプションは、このリソース配分モデルの実装です。
- 制限
cgroup は、設定された量のリソースを消費できます。サブグループ制限の合計は、親 cgroup の制限を超える可能性があります。したがって、このモデルではリソースをオーバーコミットする可能性があります。
たとえば、MemoryMax= オプションは、このリソース配分モデルの実装です。
- 保護
cgroup のリソースの保護された量を設定できます。リソースの使用状況が保護されるリソース量を下回る場合には、カーネルは、同じリソースを取得しようしている他の cgroup が優先されるように、この cgroup にペナルティーを課します。オーバーコミットも可能です。
たとえば、MemoryLow= オプションは、このリソース配分モデルの実装です。
- 割り当て
- リソースに上限がある場合に、絶対量を特別に割り当てます。オーバーコミットはできません。Linux でこのリソースのタイプとして、リアルタイムの予算などが例として挙げられます。
- ユニットファイルオプション
リソース制御設定の設定。
たとえば、CPUAccounting= や CPUQuota= などのオプションを使用して CPU リソースを設定できます。同様に、AllowedMemoryNodes= や IOAccounting= などのオプションを使用して、メモリーまたは I/O リソースを設定できます。
34.3. systemd を使用したシステムリソースの割り当て リンクのコピーリンクがクリップボードにコピーされました!
systemd を使用してシステムリソースを割り当てるには、systemd サービスとユニットの作成と管理が必要です。この割り当ては、特定の時間に、または特定のシステムイベントに応じて開始、停止、または再開するように設定できます。
手順
サービスのユニットファイルオプションの必要な値を変更するには、ユニットファイルの値を調整するか、systemctl コマンドを使用します。
選択したサービスに割り当てられた値を確認してください。
systemctl show --property <unit file option> <service name>
# systemctl show --property <unit file option> <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow CPU 時間割り当てポリシーのオプションで必要な値を設定します。
systemctl set-property <service name> <unit file option>=<value>
# systemctl set-property <service name> <unit file option>=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
選択したサービスに新しく割り当てられた値を確認してください。
systemctl show --property <unit file option> <service name>
# systemctl show --property <unit file option> <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
34.4. cgroups の systemd 階層の概要 リンクのコピーリンクがクリップボードにコピーされました!
バックエンドでは、systemd システムおよびサービスマネージャーが slice、scope、および service ユニットを使用して、コントロールグループ内のプロセスを整理および構造化します。カスタムユニットファイルを作成するか、systemctl コマンドを使用して、この階層をさらに変更できます。また、systemd は、重要なカーネルリソースコントローラーの階層を /sys/fs/cgroup/ ディレクトリーに自動的にマウントします。
リソース制御には、次の 3 つの systemd ユニットタイプを使用できます。
- サービス
ユニット設定ファイルに従って
systemdが起動したプロセスまたはプロセスのグループ。サービスは、指定したプロセスをカプセル化して、1 つのセットとして起動および停止できるようにします。サービスの名前は以下の方法で指定されます。
<name>.service
<name>.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Scope
外部で作成されたプロセスのグループ。スコープは、
fork()関数を介して任意のプロセスで開始および停止されたプロセスをカプセル化し、ランタイム時にsystemdで登録します。たとえば、ユーザーセッション、コンテナー、および仮想マシンはスコープとして処理されます。スコープの名前は以下のように指定されます。<name>.scope
<name>.scopeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - スライス
階層的に編成されたユニットのグループ。スライスは、スコープおよびサービスを配置する階層を編成します。
実際のプロセスはスコープまたはサービスに含まれます。スライスユニットの名前はすべて、階層内の場所へのパスに対応します。
ハイフン (
-) 文字は、-.sliceルートスライスからスライスへのパスコンポーネントの区切り文字として機能します。以下の例では、下記の点を前提としています。<parent-name>.slice
<parent-name>.sliceCopy to Clipboard Copied! Toggle word wrap Toggle overflow parent-name.sliceはparent.sliceのサブスライスで、これは-.sliceroot スライスのサブスライスです。parent-name.sliceには、parent-name-name2.sliceという名前の独自のサブスライスを指定できます。
サービス、スコープ、スライス ユニットは、コントロールグループ階層のオブジェクトに直接マッピングされます。これらのユニットがアクティブになると、ユニット名から構築されるグループパスを制御するように直接マッピングされます。
以下は、コントロールグループ階層の省略形の例です。
上記の例では、サービスおよびスコープにプロセスが含まれており、独自のプロセスを含まないスライスに置かれていることを示しています。
34.5. Systemd ユニットのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
systemd システムおよびサービスマネージャーを使用して、そのユニットを一覧表示します。
手順
systemctlユーティリティーを使用して、システム上のすべてのアクティブなユニットをリスト表示します。ターミナルは、次の例のような出力を返します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow UNIT- コントロールグループ階層内のユニットの位置も反映するユニットの名前です。リソース制御に関連するユニットは、スライス、スコープ および サービス です。
LOAD- ユニット設定ファイルが正しく読み込まれたかどうかを示します。ユニットファイルのロードに失敗した場合、フィールドには loaded ではなく error 状態が表示されます。ユニットの読み込みの状態は他に stub, merged, and masked などがあります。
ACTIVE-
ユニットのアクティベーションの状態 (概要レベル)。こちらは
SUBを一般化したものです。 SUB- ユニットのアクティベーションの状態 (詳細レベル)。許容値の範囲は、ユニットタイプによって異なります。
DESCRIPTION- ユニットのコンテンツおよび機能の説明。
すべてのアクティブなユニットと非アクティブなユニットをリスト表示します。
systemctl --all
# systemctl --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力の情報量を限定します。
systemctl --type service,masked
# systemctl --type service,maskedCopy to Clipboard Copied! Toggle word wrap Toggle overflow --typeオプションでは、サービス および スライス などのユニットタイプのコンマ区切りのリスト、または 読み込み済み、マスク済み などのユニットの読み込み状態が必要です。
34.6. systemd cgroups 階層の表示 リンクのコピーリンクがクリップボードにコピーされました!
コントロールグループ (cgroups) の階層と、特定の cgroups で実行しているプロセスを表示します。
手順
systemd-cglsコマンドを使用して、システム上のcgroups階層全体を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例では
cgroups階層全体を返します。この階層は、slices で形成される最も高いレベルです。systemd-cgls <resource_controller>コマンドを使用して、リソースコントローラーによってフィルター処理されたcgroups階層を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例では、選択したコントローラーと対話するサービスのリストを表示します。
systemctl status <system_unit>コマンドを使用して、特定のユニットとcgroups階層のその部分に関する詳細情報を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
34.7. プロセスの cgroup の表示 リンクのコピーリンクがクリップボードにコピーされました!
プロセスがどの コントロールグループ (cgroup) に属しているかを知ることができます。続いて cgroup をチェックして、使用するコントローラーとコントローラー固有の設定を確認できます。
手順
プロセスが属する
cgroupを表示するには、# cat proc/<PID>/cgroupコマンドを実行します。cat /proc/2467/cgroup 0::/system.slice/example.service
# cat /proc/2467/cgroup 0::/system.slice/example.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例は、対象のプロセスに関するものです。今回の例では、
example.serviceユニットに属するPID 2467で識別されるプロセスです。systemdユニットファイルの仕様で定義されているように、適切なコントロールグループにプロセスが置かれているかどうかを判断できます。cgroupが使用するコントローラーとそれぞれの設定ファイルを表示するには、cgroupディレクトリーを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cgroups のバージョン 1 階層は、コントローラーごとのモデルを使用します。したがって、/proc/PID/cgroup ファイルからの出力には、PID が属する各コントローラーの下の cgroups が表示されます。それぞれの cgroups は、/sys/fs/cgroup/<controller_name>/ のコントローラーディレクトリーにあります。
34.8. リソース消費の監視 リンクのコピーリンクがクリップボードにコピーされました!
現在実行中のコントロールグループ (cgroups) とそのリソース消費のリストをリアルタイムで表示します。
手順
systemd-cgtopコマンドを使用して、現在実行中のcgroupsの動的アカウントを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例では、現在実行中の
cgroupsが、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) 別に表示されています。デフォルトでは 1 秒ごとにリストが更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況に関する動的な見解が得られるようになります。
34.9. systemd ユニットファイルを使用してアプリケーションの制限を設定する リンクのコピーリンクがクリップボードにコピーされました!
systemd サービスマネージャーは、既存または実行中の各ユニットを監視し、それらのコントロールグループを作成します。ユニットの設定ファイルは /usr/lib/systemd/system/ ディレクトリーにあります。
ユニットファイルを手動で変更し、以下を行うことができます。
- 制限を設定する。
- 優先度を設定する。
- プロセスのグループのハードウェアリソースへのアクセスを制御する。
前提条件
-
root権限があります。
手順
/usr/lib/systemd/system/example.serviceファイルを編集して、サービスのメモリー使用量を制限します。… [Service] MemoryMax=1500K …
… [Service] MemoryMax=1500K …Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定により、コントロールグループ内のプロセスが超えることのできない最大メモリーの制限が設定されます。
example.serviceサービスは、このようなコントロールグループの一部であり、制限を課せられています。測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用できます。すべてのユニット設定ファイルを再読み込みします。
systemctl daemon-reload
# systemctl daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを再起動します。
systemctl restart example.service
# systemctl restart example.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
変更が有効になったことを確認します。
cat /sys/fs/cgroup/system.slice/example.service/memory.max 1536000
# cat /sys/fs/cgroup/system.slice/example.service/memory.max 1536000Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例では、メモリー消費量が約 1,500 KB に制限されていることを示しています。
34.10. systemctl コマンドを使用してアプリケーションに制限を設定する リンクのコピーリンクがクリップボードにコピーされました!
CPU アフィニティーの設定は、特定のプロセスにアクセスできる CPU を一部だけに制限する場合に役立ちます。実際には、CPU スケジューラーでは、プロセスのアフィニティーマスク上にない CPU で実行するプロセスはスケジューリングされません。
デフォルトの CPU アフィニティーマスクは、systemd が管理するすべてのサービスに適用されます。
特定の systemd サービスの CPU アフィニティーマスクを設定するために、systemd は CPUAffinity= を以下のものとして提供します。
- ユニットファイルオプション
-
/etc/systemd/system.confファイルの [Manager] セクションの設定オプション
CPUAffinity= ユニットファイルオプションでは、マージしてアフィニティーマスクとして使用する CPU または CPU 範囲のリストを設定します。
手順
CPUAffinity ユニットファイルオプションを使用して、特定の systemd サービスの CPU アフィニティーマスクを設定するには、次の手順を実行します。
選択したサービスで
CPUAffinityユニットファイルオプションの値を確認します。systemctl show --property <CPU affinity configuration option> <service name>
$ systemctl show --property <CPU affinity configuration option> <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow root ユーザーに切り替え、アフィニティーマスクとして使用する CPU 範囲に応じて、
CPUAffinityユニットファイルオプションの必要な値を設定します。systemctl set-property <service name> CPUAffinity=<value>
# systemctl set-property <service name> CPUAffinity=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを再起動して変更を適用します。
systemctl restart <service name>
# systemctl restart <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
34.11. マネージャー設定によるグローバルなデフォルトの CPU アフィニティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
/etc/systemd/system.conf ファイルの CPUAffinity オプションは、プロセス ID 番号 (PID) 1 と、PID1 からフォークされたすべてのプロセスのアフィニティーマスクを定義します。これにより、各サービスで CPUAffinity を上書きできます。
/etc/systemd/system.conf ファイルを使用して、すべての systemd サービスのデフォルトの CPU アフィニティーマスクを設定するには、次の手順を実行します。
-
/etc/systemd/system.confファイルの [Manager] セクションのCPUAffinity=オプションに CPU 番号を設定します。 編集したファイルを保存し、
systemdサービスをリロードします。systemctl daemon-reload
# systemctl daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow - サーバーを再起動して、変更を適用します。
34.12. systemd を使用した NUMA ポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Non-Uniform Memory Access (NUMA) は、コンピューターメモリーのサブシステム設計で、この設計ではメモリーのアクセス時間は、プロセッサーからの物理メモリーの場所により異なります。
CPU に近いメモリーは、別の CPU のローカルにあるメモリーや、一連の CPU 間で共有されているメモリーと比べ、レイテンシーが低くなっています (外部メモリー)。
Linux カーネルでは、NUMA ポリシーを使用して、カーネルがプロセス用に物理メモリーを割り当てる場所 (例: NUMA ノード) を制御します。
systemd は、サービスのメモリー割り当てポリシーを制御するためのユニットファイルオプション NUMAPolicy および NUMAMask を提供します。
手順
NUMAPolicy ユニットファイルオプションで NUMA メモリーポリシーを設定するには以下を実行します。
選択したサービスで
NUMAPolicyユニットファイルオプションの値を確認します。systemctl show --property <NUMA policy configuration option> <service name>
$ systemctl show --property <NUMA policy configuration option> <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow root として、
NUMAPolicyユニットファイルオプションに必要なポリシータイプを設定します。systemctl set-property <service name> NUMAPolicy=<value>
# systemctl set-property <service name> NUMAPolicy=<value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを再起動して変更を適用します。
systemctl restart <service name>
# systemctl restart <service name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
[Manager] 設定オプションを使用してグローバルな NUMAPolicy を設定するには、以下を実行します。
-
/etc/systemd/system.confファイルで [Manager] セクションにあるNUMAPolicyオプションを検索します。 - ポリシータイプを編集してファイルを保存します。
systemd設定をリロードします。systemd daemon-reload
# systemd daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow - サーバーを再起動します。
bind などの厳密な NUMA ポリシーを設定する場合は、CPUAffinity= ユニットファイルオプションも適切に設定されていることを確認してください。
34.13. systemd の NUMA ポリシー設定オプション リンクのコピーリンクがクリップボードにコピーされました!
Systemd で以下のオプションを指定して、NUMA ポリシーを設定します。
NUMAPolicy実行したプロセスの NUMA メモリーポリシーを制御します。次のポリシータイプを使用できます。
- default
- preferred
- bind
- interleave
- local
NUMAMask選択した NUMA ポリシーに関連付けられた NUMA ノードリストを制御します。
次のポリシーには
NUMAMaskオプションを指定する必要がないことに注意してください。- default
- local
優先ポリシーの場合、このリストで指定できるのは単一の NUMA ノードのみです。
34.14. systemd-run コマンドを使用した一時的な cgroup の作成 リンクのコピーリンクがクリップボードにコピーされました!
一時的な cgroups は、ランタイム時にユニット (サービスまたはスコープ) が消費するリソースに制限を設定します。
手順
一時的なコントロールグループを作成するには、以下の形式で
systemd-runコマンドを使用します。systemd-run --unit=<name> --slice=<name>.slice <command>
# systemd-run --unit=<name> --slice=<name>.slice <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、一時的なサービスまたはスコープユニットを作成し、開始し、そのユニットでカスタムコマンドを実行します。
-
--unit=<name>オプションは、ユニットに名前を指定します。--unitが指定されていないと、名前は自動的に生成されます。 -
--slice=<name>.sliceオプションは、サービスまたはスコープユニットを指定のスライスのメンバーにします。<name>.sliceは、既存のスライスの名前 (systemctl -t sliceの出力に表示) に置き換えるか、一意の名前を指定して新規スライスを作成します。デフォルトでは、サービスおよびスコープはsystem.sliceのメンバーとして作成されます。 <command>は、サービスまたはスコープユニットに入力するコマンドに置き換えます。以下のような、サービスまたはスコープが正常に作成され開始したことを確認するメッセージが表示されます。
Running as unit <name>.service
# Running as unit <name>.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
オプション: ランタイム情報を収集するため、プロセスが終了した後もユニットを実行したままにします。
systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>
# systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、一時的なサービスユニットを作成して起動し、そのユニットでカスタムコマンドを実行します。
--remain-after-exitオプションを使用すると、プロセスの終了後もサービスが実行し続けます。
34.15. 一時的なコントロールグループの削除 リンクのコピーリンクがクリップボードにコピーされました!
systemd システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、一時的なコントロールグループ (cgroup) を削除できます。
一時的な cgroups は、サービスまたはスコープユニットに含まれる全プロセスが完了すると、自動的に解放されます。
手順
サービスユニットの全プロセスを停止するには、以下を実行します。
systemctl stop <name>.service
# systemctl stop <name>.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow ユニットプロセスを 1 つ以上終了するには、以下を実行します。
systemctl kill <name>.service --kill-who=PID,… --signal=<signal>
# systemctl kill <name>.service --kill-who=PID,… --signal=<signal>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは
--kill-whoオプションを使用して、コントロールグループから終了するプロセスを選択します。複数のプロセスを同時に強制終了するには、PID のコンマ区切りのリストを指定します。--signalオプションは、指定されたプロセスに送信する POSIX シグナルのタイプを決定します。デフォルトのシグナルは SIGTERM です。
第35章 コントロールグループについて リンクのコピーリンクがクリップボードにコピーされました!
コントロールグループ (cgroups) カーネル機能を使用すると、アプリケーションのリソース使用状況を制御して、より効率的に使用できます。
cgroups は、以下のタスクで使用できます。
- システムリソース割り当ての制限を設定します。
- 特定のプロセスへのハードウェアリソースの割り当てにおける優先順位を設定する。
- 特定のプロセスをハードウェアリソースの取得から分離する。
35.1. コントロールグループの概要 リンクのコピーリンクがクリップボードにコピーされました!
コントロールグループ の Linux カーネル機能を使用して、プロセスを階層的に順序付けされたグループ (cgroups) に編成できます。階層 (コントロールグループツリー) は、デフォルトで /sys/fs/cgroup/ ディレクトリーにマウントされている cgroups 仮想ファイルシステムに構造を提供して定義します。
systemd サービスマネージャーは、cgroups を使用して、管理するすべてのユニットとサービスを整理します。/sys/fs/cgroup/ ディレクトリーのサブディレクトリーを作成および削除することで、cgroups の階層を手動で管理できます。
続いて、カーネルのリソースコントローラーは、cgroups 内のプロセスのシステムリソースを制限、優先順位付け、または割り当てることで、これらのプロセスの動作を変更します。これらのリソースには以下が含まれます。
- CPU 時間
- メモリー
- ネットワーク帯域幅
- これらのリソースの組み合わせ
cgroups の主なユースケースは、システムプロセスを集約し、アプリケーションとユーザー間でハードウェアリソースを分割することです。これにより、環境の効率、安定性、およびセキュリティーを強化できます。
- コントロールグループ 1
コントロールグループバージョン 1 (
cgroups-v1) はリソースごとのコントローラー階層を提供します。CPU、メモリー、I/O などのリソースごとに、独自のコントロールグループ階層があります。異なるコントロールグループ階層を組み合わせることで、1 つのコントローラーが別のコントローラーと連携してそれぞれのリソースを管理できるようになります。ただし、2 つのコントローラーが異なるプロセス階層に属している場合、連携が制限されます。cgroups-v1コントローラーは長期間にわたって開発されたため、コントロールファイルの動作と命名に一貫性がありません。- コントロールグループ 2
Control groups version 2 (
cgroups-v2) は、すべてのリソースコントローラーがマウントされる単一のコントロールグループ階層を提供します。コントロールファイルの動作と命名は、さまざまなコントローラーにおいて一貫性があります。
RHEL 9 では、デフォルトで cgroups-v2 をマウントして使用します。
35.2. カーネルリソースコントローラーの概要 リンクのコピーリンクがクリップボードにコピーされました!
カーネルリソースコントローラーは、コントロールグループの機能を有効化します。RHEL 9 は、コントロールグループバージョン 1 (cgroups-v1) および コントロールグループバージョン 2 (cgroups-v2) のさまざまなコントローラーをサポートします。
コントロールグループサブシステムとも呼ばれるリソースコントローラーは、1 つのリソース (CPU 時間、メモリー、ネットワーク帯域幅、ディスク I/O など) を表すカーネルサブシステムです。Linux カーネルは、systemd サービスマネージャーによって自動的にマウントされるリソースコントローラーの範囲を提供します。現在マウントされているリソースコントローラーの一覧は、/proc/cgroups ファイルで確認できます。
cgroups-v1 で利用可能なコントローラー
blkio- ブロックデバイスへの入出力アクセスを制限します。
cpu-
コントロールグループのタスク用の Completely Fair Scheduler (CFS) パラメーターを調整します。
cpuコントローラーは、同じマウント上のcpuacctコントローラーとともにマウントされます。 cpuacct-
コントロールグループ内のタスクが使用する CPU リソースに関する自動レポートを作成します。
cpuacctコントローラーは、同じマウント上のcpuコントローラーとともにマウントされます。 cpuset- コントロールグループタスクが、指定された CPU のサブセットでのみ実行されるように制限し、指定されたメモリーノードでのみメモリーを使用するようにタスクに指示します。
devices- コントロールグループ内のタスクのデバイスへのアクセスを制御します。
freezer- コントロールグループ内のタスクを一時停止または再開します。
memory- コントロールグループ内のタスクによるメモリー使用の制限を設定し、それらのタスクが使用したメモリーリソースに関する自動レポートを生成します。
net_cls-
特定のコントロールグループタスクから発信されたパケットを識別するために Linux トラフィックコントローラー (
tcコマンド) を有効化するクラス識別子 (classid) でネットワークパケットをタグ付けします。net_clsのサブシステムnet_ filter(iptables) でも、このタグを使用して、そのようなパケットに対するアクションを実行することができます。net_filterは、ファイアウォール識別子 (fwid) でネットワークソケットをタグ付けします。これにより、Linux ファイアウォールは、(iptablesコマンドを使用して) 特定のコントロールグループタスクから発信されたパケットを識別できるようになります。 net_prio- ネットワークトラフィックの優先度を設定します。
pids- コントロールグループ内の複数のプロセスとその子プロセスに制限を設定します。
perf_event-
perfパフォーマンス監視およびレポートユーティリティーにより、監視するタスクをグループ化します。 rdma- コントロールグループ内の Remote Direct Memory Access/InfiniB 固有リソースに制限を設定します。
hugetlb- コントロールグループ内のタスクによる大容量の仮想メモリーページの使用を制限します。
cgroups-v2 で利用可能なコントローラー
io- ブロックデバイスへの入出力アクセスを制限します。
memory- コントロールグループ内のタスクによるメモリー使用の制限を設定し、それらのタスクが使用したメモリーリソースに関する自動レポートを生成します。
pids- コントロールグループ内の複数のプロセスとその子プロセスに制限を設定します。
rdma- コントロールグループ内の Remote Direct Memory Access/InfiniB 固有リソースに制限を設定します。
cpu- コントロールグループのタスクの Completely Fair Scheduler (CFS) パラメーターを調整し、コントロールグループのタスクで使用される CPU リソースに関する自動レポートを作成します。
cpuset-
コントロールグループタスクが、指定された CPU のサブセットでのみ実行されるように制限し、指定されたメモリーノードでのみメモリーを使用するようにタスクに指示します。新しいパーティション機能により、コア機能 (
cpus{,.effective},mems{,.effective}) のみがサポートされます。 perf_event-
perfパフォーマンス監視およびレポートユーティリティーにより、監視するタスクをグループ化します。perf_evenは v2 階層で自動的に有効になります。
リソースコントローラーは、cgroups-v1 階層または cgroups-v 2 階層のいずれかで使用できますが、両方を同時に使用することはできません。
35.3. 名前空間の概要 リンクのコピーリンクがクリップボードにコピーされました!
名前空間は、ソフトウェアオブジェクトを整理および識別するための個別の空間を作成するものです。これにより、オブジェクトが相互に影響を及ぼすことがなくなります。その結果、各ソフトウェアオブジェクトが同じシステムを共有しているにもかかわらず、独自のリソースセット (マウントポイント、ネットワークデバイス、ホスト名など) が各オブジェクトに格納されます。
名前空間を使用する最も一般的なテクノロジーの 1 つとしてコンテナーが挙げられます。
特定のグローバルリソースへの変更は、その名前空間のプロセスにのみ表示され、残りのシステムまたは他の名前空間には影響しません。
プロセスがどの名前空間に所属するかを確認するには、/proc/<PID>/ns/ ディレクトリーのシンボリックリンクを確認します。
| 名前空間 | 分離 |
|---|---|
| Mount | マウントポイント |
| UTS | ホスト名および NIS ドメイン名 |
| IPC | System V IPC、POSIX メッセージキュー |
| PID | プロセス ID |
| Network | ネットワークデバイス、スタック、ポートなど。 |
| User | ユーザーおよびグループ ID |
| Control groups | コントロールグループの root ディレクトリー |
第36章 cgroupfs を使用して cgroup を手動で管理する リンクのコピーリンクがクリップボードにコピーされました!
cgroupfs 仮想ファイルシステムにディレクトリーを作成することにより、システム上の cgroup 階層を管理できます。ファイルシステムはデフォルトで /sys/fs/cgroup/ ディレクトリーにマウントされ、専用の制御ファイルで必要な設定を指定できます。
一般に、Red Hat では、システムリソースの使用を制御するために systemd を使用することを推奨します。特別な場合にのみ、cgroups 仮想ファイルシステムを手動で設定する必要があります。たとえば、cgroup-v2 階層に同等のものがない cgroup-v1 コントローラーを使用する必要がある場合です。
36.1. cgroups-v2 ファイルシステムでの cgroup の作成とコントローラーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーを作成または削除したり、cgroups 仮想ファイルシステム内のファイルに書き込んだりすることで、control groups (cgroups) を管理できます。ファイルシステムは、デフォルトで /sys/fs/cgroup/ ディレクトリーにマウントされます。cgroups コントローラーの設定を使用するには、子 cgroups に対して目的のコントローラーを有効にする必要もあります。ルート cgroup は、デフォルトで、その子 cgroups の memory および pids コントローラーを有効にしました。したがって、Red Hat は、/sys/fs/cgroup/ ルート cgroup 内に少なくとも 2 つのレベルの子 cgroups を作成することを推奨します。このようにして、オプションで子 cgroups から memory と pids コントローラーを削除し、cgroup ファイルの組織の明確さを維持します。
前提条件
- root 権限がある。
手順
/sys/fs/cgroup/Example/ディレクトリーを作成します。mkdir /sys/fs/cgroup/Example/
# mkdir /sys/fs/cgroup/Example/Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/fs/cgroup/Example/ディレクトリーはサブグループを定義します。/sys/fs/cgroup/Example/ディレクトリーを作成すると、一部のcgroups-v2インターフェイスファイルがディレクトリーに自動的に作成されます。/sys/fs/cgroup/Example/ディレクトリーには、memoryおよびpidsコントローラー用のコントローラー固有のファイルも含まれます。オプション: 新しく作成された子コントロールグループを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例は、
cgroup.procsやcgroup.controllersなどの一般的なcgroup制御インターフェイスファイルを示しています。これらのファイルは、有効なコントローラーに関係なく、すべてのコントロールグループに共通です。memory.highおよびpids.maxなどのファイルは、memoryおよびpidsコントローラーに関連し、ルートコントロールグループ (/sys/fs/cgroup/) にあり、systemdによってデフォルトで有効になります。デフォルトでは、新しく作成された子グループは、親
cgroupからすべての設定を継承します。この場合、ルートcgroupからの制限はありません。目的のコントローラーが
/sys/fs/cgroup/cgroup.controllersファイルで使用可能であることを確認します。cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma
# cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdmaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 目的のコントローラーを有効にします。この例では、
cpuおよびcpusetコントローラーです。echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control
# echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow これらのコマンドにより、
/sys/fs/cgroup/ルートコントロールグループ直下のサブグループに対してcpuおよびcpusetコントローラーが有効になります。新しく作成されたExampleコントロールグループを含みます。サブグループ で指定した各プロセスに対して、基準に基づいてコントロールチェックを適用できます。ユーザーは任意のレベルの
cgroup.subtree_controlファイルの内容を読み取り、直下のサブグループで有効にするコントローラーを把握することができます。注記デフォルトでは、ルートコントロールグループの
/sys/fs/cgroup/cgroup.subtree_controlファイルにはmemoryとpidsコントローラーが含まれます。Exampleコントロールグループの子cgroupsに必要なコントローラーを有効にします。echo "+cpu +cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control
# echo "+cpu +cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、直下のサブコントロールグループに、(
memoryまたはpidsコントローラーではなく) CPU 時間の配分の調整に関係するコントローラー だけが設定されるようになります。/sys/fs/cgroup/Example/tasks/ディレクトリーを作成します。mkdir /sys/fs/cgroup/Example/tasks/
# mkdir /sys/fs/cgroup/Example/tasks/Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/fs/cgroup/Example/tasks/ディレクトリーは、cpuおよびcpusetコントローラーにのみ関連するファイルを持つサブグループを定義します。これで、このコントロールグループにプロセスを割り当て、プロセスにcpuおよびcpusetコントローラーオプションを利用できます。オプション: 子コントロールグループを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cpu コントローラーは、該当のサブコントロールグループに、同じ CPU の CPU 時間を取り合うプロセスが 2 つ以上ある場合にのみ、有効になります。
検証
オプション: 目的のコントローラーのみがアクティブな状態で新しい
cgroupを作成したことを確認します。cat /sys/fs/cgroup/Example/tasks/cgroup.controllers cpuset cpu
# cat /sys/fs/cgroup/Example/tasks/cgroup.controllers cpuset cpuCopy to Clipboard Copied! Toggle word wrap Toggle overflow
36.2. CPU の重みの調整によるアプリケーションへの CPU 時間配分の制御 リンクのコピーリンクがクリップボードにコピーされました!
特定の cgroup ツリーの下にあるアプリケーションへの CPU 時間の配分を調整するには、cpu コントローラーの関連ファイルに値を割り当てる必要があります。
前提条件
- root 権限がある。
- CPU 時間の配分を制御するアプリケーションがある。
次の例のように、
/sys/fs/cgroup/root control group 内に、child control groups グループの 2 階層を作成しました。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
cgroups-v2 ファイルシステムでの cgroup の作成とコントローラーの有効化 で説明したのと同様に、親コントロールグループと子コントロールグループで
cpuコントローラーを有効にしました。
手順
コントロールグループ内のリソース制限を実現するために、希望する CPU の重みを設定します。
echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight
# echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weightCopy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションの PID を
g1、g2、およびg3サブグループに追加します。echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs
# echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドの例は、目的のアプリケーションが
Example/g*/子 cgroup のメンバーになり、それらの cgroup の設定に従って CPU 時間を分散させることを保証します。実行中のプロセスを持つサブ cgroups(
g1、g2、g3) の重みは、親 cgroup のレベルで合算されます (例)。その後、CPU リソースはそれぞれの重みに基づいて相対的に配分されます。その結果、すべてのプロセスが同時に実行されると、カーネルはそれぞれの cgroup の
cpu.weightファイルに基づいて、それぞれのプロセスに比例配分の CPU 時間を割り当てます。Expand サブ cgroup cpu.weightファイルCPU 時間の割り当て g1
150
約 50% (150/300)
g2
100
約 33% (100/300)
g3
50
約 16% (50/300)
cpu.weightコントローラーファイルの値はパーセンテージではありません。1 つのプロセスが実行を停止し、cgroup
g2が実行中のプロセスのない状態になると、計算では cgroupg2が省略され、cgroupsg1およびg3の重みだけが考慮されます。Expand サブ cgroup cpu.weightファイルCPU 時間の割り当て g1
150
約 75% (150/200)
g3
50
約 25% (50/200)
重要子 cgroup に複数の実行中のプロセスがある場合、cgroup に割り当てられた CPU 時間が、そのメンバープロセス間で均等に分配されます。
検証
アプリケーションが指定のコントロールグループで実行されていることを確認します。
cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup 0::/Example/g1 0::/Example/g2 0::/Example/g3
# cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup 0::/Example/g1 0::/Example/g2 0::/Example/g3Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンド出力は、
Example/g*/サブ cgroups で実行される指定されたアプリケーションのプロセスを示しています。スロットリングされたアプリケーションの現在の CPU 使用率を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記わかりやすくするために、すべてのプロセスを単一の CPU 上で実行しています。CPU の重みは、複数の CPU で使用される場合にも、同じ原則を適用します。
PID 33373、PID 33374、およびPID 33377の CPU リソースが、それぞれの子 cgroups に割り当てた 150、100、および 50 の重みに基づいて割り当てられていることに注意してください。重みは、各アプリケーションの CPU 時間の約 50%、33%、および 16% の配分に対応します。
36.3. cgroups-v1 のマウント リンクのコピーリンクがクリップボードにコピーされました!
RHEL 9 は、システムの起動プロセス中に、デフォルトで cgroup-v2 仮想ファイルシステムをマウントします。cgroup-v1 機能を使用してアプリケーションのリソースを制限するには、システムを手動で設定します。
cgroup-v1 と cgroup-v2 の両方がカーネルで完全に有効になっている。カーネルから見た場合、デフォルトのコントロールグループバージョンはありません。また、システムの起動時にマウントするかどうかは、systemd により決定します。
前提条件
- root 権限がある。
手順
systemdシステムおよびサービスマネージャーによるシステムブート中に、デフォルトでcgroups-v1をマウントするようにシステムを設定します。grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、必要なカーネルコマンドラインパラメーターが現在のブートエントリーに追加されます。
すべてのカーネルブートエントリーに同じパラメーターを追加するには:
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
# grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - システムを再起動して、変更を有効にします。
検証
cgroups-v1ファイルシステムがマウントされたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow さまざまな
cgroup-v1コントローラーに対応するcgroups-v1ファイルシステムが、/sys/fs/cgroup/ディレクトリーに正常にマウントされました。/sys/fs/cgroup/ディレクトリーの内容を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow /sys/fs/cgroup/ディレクトリーは、デフォルトでは root control group とも呼ばれ、cpusetなどのコントローラー固有のディレクトリーが含まれています。さらに、systemdに関連するディレクトリーがいくつかあります。
36.4. cgroups-v1 を使用したアプリケーションへの CPU 制限の設定 リンクのコピーリンクがクリップボードにコピーされました!
コントロールグループバージョン 1 (cgroups-v1) を使用してアプリケーションに対する CPU 制限を設定するには、/sys/fs/ 仮想ファイルシステムを使用します。
前提条件
- root 権限がある。
- CPU 消費制限の対象とするアプリケーションがシステムにインストールされている。
systemdシステムおよびサービスマネージャーによるシステムの起動時に、デフォルトでcgroups-v1をマウントするようにシステムを設定している。grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、必要なカーネルコマンドラインパラメーターが現在のブートエントリーに追加されます。
手順
CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PID 6955を持つsha1sumサンプルアプリケーションが、大量の CPU リソースを消費しています。cpuリソースコントローラーディレクトリーにサブディレクトリーを作成します。mkdir /sys/fs/cgroup/cpu/Example/
# mkdir /sys/fs/cgroup/cpu/Example/Copy to Clipboard Copied! Toggle word wrap Toggle overflow このディレクトリーはコントロールグループを表します。ここに特定のプロセスを配置して、そのプロセスに特定の CPU 制限を適用できます。同時に、いくつかの
cgroups-v1インターフェイスファイルとcpuコントローラー固有のファイルがディレクトリーに作成されます。オプション: 新しく作成されたコントロールグループを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cpuacct.usage、cpu.cfs._period_usなどのファイルは、Exampleコントロールグループ内のプロセスに設定できる特定の設定や制限を表しています。ファイル名の先頭に、それが属するコントロールグループコントローラーの名前が付いていることに注意してください。デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。
コントロールグループの CPU 制限を設定します。
echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
# echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_usCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
cpu.cfs_period_usファイルは、コントロールグループの CPU リソースへのアクセスを再割り当てする必要がある頻度を表します。期間はマイクロ秒 (µs、"us") 単位です。上限は 1,000,000 マイクロ秒、下限は 1,000 マイクロ秒です。 cpu.cfs_quota_usファイルは、コントロールグループ内のすべてのプロセスが 1 つの期間 (cpu.cfs_period_usで定義) 中にまとめて実行できる合計時間をマイクロ秒単位で表します。コントロールグループ内のプロセスが 1 つの期間中にクォータで指定された時間をすべて使い果たすと、そのプロセスは残り期間にわたってスロットリングされ、次の期間まで実行できなくなります。下限は 1000 マイクロ秒です。上記のコマンド例は、CPU 時間制限を設定して、
Exampleコントロールグループでまとめられているすべてのプロセスは、1 秒ごと (cpu.cfs_period_usに定義されている) に、0.2 秒間だけ (cpu.cfs_quota_usに定義されている) 実行できるようにしています。
-
オプション: 制限を確認します。
cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us 1000000 200000
# cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us 1000000 200000Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションの PID を
Exampleコントロールグループに追加します。echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
# echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procsCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドによって、特定のアプリケーションが
Exampleコントロールグループのメンバーとなり、Exampleコントロールグループに設定された CPU 制限を超えないようになります。PID はシステム内の既存のプロセスを表す必要があります。このPID 6955は、プロセスsha1sum /dev/zero &に割り当てられておりcpuコントローラーの使用例を示すために使用されています。
検証
アプリケーションが指定のコントロールグループで実行されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションのプロセスは、アプリケーションのプロセスに CPU 制限を適用する
Exampleコントロールグループで実行されます。スロットルしたアプリケーションの現在の CPU 使用率を特定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PID 6955の CPU 消費が 99% から 20% に減少していることに注意してください。
cpu.cfs_period_us および cpu.cfs_quota_us に対応する cgroups-v2 は、cpu.max ファイルです。cpu.max ファイルは、cpu コントローラーから入手できます。
第37章 BPF コンパイラーコレクションでシステムパフォーマンスの分析 リンクのコピーリンクがクリップボードにコピーされました!
BPF Compiler Collection (BCC) は、Berkeley Packet Filter (BPF) の機能を組み合わせてシステムパフォーマンスを分析します。BPF を使用すると、カーネル内でカスタムプログラムを安全に実行して、パフォーマンス監視、トレース、およびデバッグ用のシステムイベントとデータにアクセスできます。BCC は、ユーザーがシステムから重要な詳細情報を抽出するための BPF プログラムの開発とデプロイを、ツールとライブラリーを使用して簡素化します。
37.1. bcc-tools パッケージのインストール リンクのコピーリンクがクリップボードにコピーされました!
bcc-tools パッケージをインストールします。これにより、依存関係として BPF Compiler Collection (BCC) ライブラリーもインストールされます。
手順
bcc-toolsをインストールします。dnf install bcc-tools
# dnf install bcc-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow BCC ツールは、
/usr/share/bcc/tools/ディレクトリーにインストールされます。
検証
インストールされたツールを検査します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リスト内の
docディレクトリーには、各ツールのドキュメントがあります。
37.2. bcc-tools でパフォーマンスの分析 リンクのコピーリンクがクリップボードにコピーされました!
BPF Compiler Collection (BCC) ライブラリーから事前に作成された特定のプログラムを使用して、システムパフォーマンスをイベントごとに効率的かつセキュアに分析します。BCC ライブラリーで事前作成されたプログラムセットは、追加プログラム作成の例として使用できます。
前提条件
- bcc-tools パッケージがインストールされている
- root 権限がある。
手順
execsnoopを使用してシステムプロセスを調べる-
1 つのターミナルで
execsnoopプログラムを実行します。
/usr/share/bcc/tools/execsnoop
# /usr/share/bcc/tools/execsnoopCopy to Clipboard Copied! Toggle word wrap Toggle overflow lsコマンドの短期的なプロセスを作成するために、別のターミナルで次のように入力します。ls /usr/share/bcc/tools/doc/
$ ls /usr/share/bcc/tools/doc/Copy to Clipboard Copied! Toggle word wrap Toggle overflow execsnoopを実行している端末に、次のような出力が表示されます。PCOMM PID PPID RET ARGS ls 8382 8287 0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/ ...
PCOMM PID PPID RET ARGS ls 8382 8287 0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/ ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow execsnoopプログラムは、システムリソースを消費する新しいプロセスごとに 1 つの行を出力します。また、lsなどの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。execsnoop出力には以下のフィールドが表示されます。
-
1 つのターミナルで
- PCOMM
-
親プロセス名。(
ls) - PID
-
プロセス ID。(
8382) - PPID
-
親プロセス ID。(
8287) - RET
-
exec()システムコールの戻り値 (0)。プログラムコードを新規プロセスに読み込みます。 - ARGS
- 引数を使用して起動したプログラムの場所。
execsnoop の詳細、例、オプションについては、/usr/share/bcc/tools/doc/execsnoop_example.txt ファイルを参照してください。
exec() の詳細は、exec(3) man ページを参照してください。
opensnoopを使用して、コマンドにより開かれるファイルを追跡する-
1 つのターミナルで
opensnoopプログラムを実行し、unameコマンドのプロセスによってのみ開かれたファイルを出力します。
/usr/share/bcc/tools/opensnoop -n uname
# /usr/share/bcc/tools/opensnoop -n unameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 別のターミナルで、特定のファイルを開くコマンドを入力します。
uname
$ unameCopy to Clipboard Copied! Toggle word wrap Toggle overflow opensnoopを実行している端末は、以下のような出力を表示します。PID COMM FD ERR PATH 8596 uname 3 0 /etc/ld.so.cache 8596 uname 3 0 /lib64/libc.so.6 8596 uname 3 0 /usr/lib/locale/locale-archive ...
PID COMM FD ERR PATH 8596 uname 3 0 /etc/ld.so.cache 8596 uname 3 0 /lib64/libc.so.6 8596 uname 3 0 /usr/lib/locale/locale-archive ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow opensnoopプログラムは、システム全体でopen()システム呼び出しを監視し、unameが開こうとしたファイルごとに出力行を出力します。opensnoop出力には、以下のフィールドが表示されます。- PID
-
プロセス ID。(
8596) - COMM
-
プロセス名。(
uname) - FD
-
ファイルの記述子。開いたファイルを参照するために
open()が返す値です。(3) - ERR
- すべてのエラー。
- PATH
-
open()で開こうとしたファイルの場所。
コマンドが、存在しないファイルを読み込もうとすると、
FDコラムは-1を返し、ERRコラムは関連するエラーに対応する値を出力します。その結果、opensnoopは、適切に動作しないアプリケーションの特定に役立ちます。
-
1 つのターミナルで
opensnoop の詳細、例、オプションについては、/usr/share/bcc/tools/doc/opensnoop_example.txt ファイルを参照してください。
open() の詳細は、open(2) man ページを参照してください。
biotopを使用して、ディスク上で I/O 操作を実行している上位のプロセスを監視する-
1 つのターミナルで
biotopプログラムを引数30を指定して実行し、30 秒間のサマリーを生成します。
/usr/share/bcc/tools/biotop 30
# /usr/share/bcc/tools/biotop 30Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記引数を指定しないと、デフォルトでは 1 秒ごとに出力画面が更新されます。
別のターミナルで、次のコマンドを入力して、ローカルハードディスクデバイスからコンテンツを読み取り、出力を
/dev/zeroファイルに書き込みます。dd if=/dev/vda of=/dev/zero
# dd if=/dev/vda of=/dev/zeroCopy to Clipboard Copied! Toggle word wrap Toggle overflow この手順では、
biotopを示す特定の I/O トラフィックを生成します。biotopを実行している端末は、以下のような出力を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow biotop出力には、以下のフィールドが表示されます。
-
1 つのターミナルで
- PID
-
プロセス ID。(
9568) - COMM
-
プロセス名。(
dd) - DISK
-
読み取り操作を実行するディスク。(
vda) - I/O
- 実行された読み取り操作の数。(16294)
- Kbytes
- 読み取り操作によって使用したバイト数 (KB)。(14,440,636)
- AVGms
- 読み取り操作の平均 I/O 時間。(3.69)
biotop の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/biotop_example.txt ファイルを参照してください。
dd の詳細は、dd(1) man ページを参照してください。
xfsslower を使用して、予想以上に遅いファイルシステム操作を明らかにする
xfsslower は、XFS ファイルシステムによる読み取り操作、書き込み操作、開く操作、または同期操作 (fsync) の実行に費やされた時間を測定します。1 引数を指定すると、1 ms よりも遅い操作のみが表示されます。
1 つのターミナルで
xfsslowerプログラムを実行します。/usr/share/bcc/tools/xfsslower 1
# /usr/share/bcc/tools/xfsslower 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記引数を指定しないと、
xfsslowerはデフォルトで 10 ms よりも低速な操作を表示します。別のターミナルで、
vimエディターでテキストファイルを作成するコマンドを入力して、XFS ファイルシステムとのやり取りを開始します。vim text
$ vim textCopy to Clipboard Copied! Toggle word wrap Toggle overflow 前の手順でファイルを保存すると、
xfsslowerを実行しているターミナルに次のような内容が表示されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各行は、特定のしきい値よりも時間がかかったファイルシステム内の操作を表しています。
xfsslowerは、操作に想定以上に時間がかかるなど、ファイルシステムで発生し得る問題を検出します。xfsslower出力には、以下のフィールドが表示されます。- COMM
-
プロセス名。(
b’bash') - T
操作の種類。(
R)- Read
- Write
- Sync
- OFF_KB
- ファイルオフセット (KB)。(0)
- FILENAME
- 読み取り、書き込み、または同期されるファイル。
xfsslower の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/xfsslower_example.txt ファイルを参照してください。
fsync の詳細は、fsync(2) の man ページを参照してください。
第38章 メモリーアクセスを最適化するためにオペレーティングシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
RHEL に含まれているツールを使用して、オペレーティングシステムを設定し、ワークロード全体でメモリーアクセスを最適化できます。
38.1. システムメモリーの問題を監視および診断するツール リンクのコピーリンクがクリップボードにコピーされました!
以下のツールは、システムパフォーマンスを監視し、システムメモリーに関連するパフォーマンス問題を診断するために、Red Hat Enterprise Linux 9 で利用できます。
-
procps-ngパッケージが提供するvmstatツールは、システムのプロセス、メモリー、ページング、ブロック I/O、トラップ、ディスク、および CPU アクティビティーのレポートを表示します。これは、マシンが最後にオンされてから、または前回のレポート以降、これらのイベントの平均をインスタンス化するレポートを提供します。 valgrindフレームワークは、ユーザー空間のバイナリーにインストルメンテーションを提供します。dnf install valgrindコマンドを使用して、このツールをインストールします。これには、以下のようなプログラムパフォーマンスのプロファイリングおよび分析に使用できるツールが多数含まれています。memcheckオプションは、デフォルトのvalgrindツールです。これは、以下のような多くのメモリーエラーを検出し、報告することが困難となる可能性のあるメモリーエラーを検出および報告します。- 発生すべきでないメモリーアクセス
- 未定義または初期化されていない値の使用
- 誤って解放されたヒープメモリー
- ポインターの重複
メモリーリーク
注記memcheck は、このエラーのみを報告でき、エラーを回避することはできません。ただし、
memcheckは、エラーが発生した場合すぐにエラーメッセージを記録します。
-
cachegrindオプションは、システムのキャッシュ階層および分岐予測とのアプリケーションの対話をシミュレートします。アプリケーションの実行期間の統計を収集し、コンソールにサマリーを出力します。 -
massifオプションは、指定されたアプリケーションによって使用されるヒープ容量を測定します。便利な容量やブックキーピングと調整目的で割り当てられた容量を測定します。
38.2. システムのメモリーの概要 リンクのコピーリンクがクリップボードにコピーされました!
Linux カーネルは、システムのメモリーリソース (RAM) の使用状況を最大化するために設計されています。このような設計の特徴と、ワークロードのメモリー要件によっては、システムのメモリーの一部がワークロードの変わりにカーネル内で使用されますが、メモリーのサイズは解放されています。この空きメモリーは、特別なシステム割り当てや、その他の優先度のシステムサービス用に予約されています。
システムメモリーの残りの部分はワークロード自体に専用で、以下の 2 つのカテゴリーに分類されます。
File memoryこのカテゴリーに追加されたページは、永続ストレージのファイルの一部を表します。ページキャッシュのこれらのページは、アプリケーションのアドレス空間でマッピングまたはマッピング解除できます。アプリケーションを使用することで、
mmapシステムコールを使用してファイルをアドレス空間にマップしたり、バッファー I/O の読み取りおよび書き込み経由でファイルで操作したりできます。バッファーされた I/O システムコール、およびページを直接マップするアプリケーションも、マッピングされていないページを再使用できます。その結果、これらのページは、同じページのセットに負荷の高い I/O 操作を再発行しないように、カーネルによりキャッシュに保存されます。これは特に、システムがメモリーインテンシブなタスクを実行していないときが該当します。
Anonymous memory- このカテゴリーのページは、動的に割り当てられたプロセスで使用されているか、永続ストレージのファイルに関連しません。この一連のページは、アプリケーションスタックやヒープ領域など、各タスクのメモリー内制御構造をバックアップします。
図38.1 メモリー使用状況パターン
38.3. 仮想メモリーパラメーター リンクのコピーリンクがクリップボードにコピーされました!
仮想メモリーのパラメーターは、/proc/sys/vm ディレクトリーにリスト表示されます。
利用可能な仮想メモリーパラメーターを以下に示します。
vm.dirty_ratio-
パーセンテージの値です。変更された合計システムメモリーの割合がこの値に達すると、システムがディスクへの変更の書き込みを開始します。デフォルト値は
20% です。 vm.dirty_background_ratio-
パーセンテージの値。変更された合計システムメモリーの割合がこの値に達すると、システムがバックグラウンドでディスクへの変更の書き込みを開始します。デフォルト値は
10% です。 vm.overcommit_memory大容量メモリーのリクエストを受け入れるか拒否するかを決定する条件を定義します。デフォルト値は
0です。デフォルトでは、カーネルは仮想メモリー割り当て要求が現在のメモリー量 (合計 + スワップ) に収まるかどうかをチェックし、大きな要求のみを拒否します。それ以外の場合、仮想メモリーの割り当ては付与され、これはメモリーのオーバーコミットが許可されることを意味します。
overcommit_memoryパラメーターの値を設定します。-
このパラメーターを
1に設定するとカーネルはメモリーのオーバーコミット処理を行いません。これにより、メモリーがオーバーロードする可能性が向上しますが、メモリー集中型タスクのパフォーマンスが向上します。 -
このパラメーターを
2に設定すると、カーネルは、利用可能なスワップ領域の合計と、overcommit_ratioで指定される物理 RAM の割合またはそれ以上のメモリーの要求を拒否します。これにより、メモリーのオーバーコミットのリスクが軽減されますが、物理メモリーよりも大きいスワップ領域があるシステムのみに推奨されます。
-
このパラメーターを
vm.overcommit_ratio-
overcommit_memoryが2に設定されている場合に考慮される物理 RAM の割合を指定します。デフォルト値は50です。 vm.max_map_count-
プロセスが使用可能なメモリーマップ領域の最大数を定義します。デフォルト値は
65530です。アプリケーションに十分なメモリーマップ領域が必要な場合は、この値を増やします。 vm.min_free_kbytes予約済み空きページプールのサイズを設定します。また、Linux カーネルのページ回収アルゴリズムの動作を管理する
min_page、low_page、high_pageのしきい値も設定します。また、システム全体で空き状態になる最小キロバイト数も指定します。これにより、各ローメモリーゾーンの特定の値を計算します。それぞれには、サイズに比例して予約済み空きページが多数割り当てられます。vm.min_free_kbytesパラメーターの値の設定:- パラメーターの値を増やすと、アプリケーションのワーキングセットが効果的に減少します。そのため、カーネル駆動型のワークロードのみに使用するほうがよい場合があります。この場合、ドライバーバッファーはアトミックコンテキストで割り当てる必要があります。
パラメーターの値を下げると、システムでメモリーが不足した場合に、カーネルがシステム要求の処理をレンダリングできなくなる可能性があります。
警告極端な値は、システムのパフォーマンスに悪影響を与えます。
vm.min_free_kbytesが非常に低い値に設定すると、システムのメモリーを効果的に回収できなくなります。これにより、システムがクラッシュし、サービス割り込みやその他のカーネルサービスに失敗する可能性があります。ただし、vm.min_free_kbytesを設定すると、システムの回収アクティビティーが大幅に増大し、誤ったダイレクト回収状態により割り当てレイテンシーが発生します。これにより、システムがメモリー不足の状態に即座に入ります。vm.min_free_kbytesパラメーターは、min_pagesというページ回収ウォーターマークも設定します。このウォーターマークは、ページの回収アルゴリズムを管理する他の 2 つのメモリー基準 (low_pages、およびhigh_pages) を決定する要素として使用されます。
/proc/PID/oom_adjシステムがメモリー不足になり、
panic_on_oomパラメーターが0に設定されている場合は、oom_killer関数は、システムが復旧するまで、プロセスを強制終了し、最も高いoom_scoreを持つプロセスを開始します。oom_adjパラメーターは、プロセスのoom_scoreを決定します。このパラメーターはプロセス ID ごとに設定されます。-17の値は、そのプロセスのoom_killerを無効にします。そのほかの有効な値は、-16から15までになります。
調整したプロセスによって作成されたプロセスは、そのプロセスの oom_score を継承します。
vm.swappinessswappiness 値 (
0から200まで) は、システムが匿名メモリープールまたはページキャッシュメモリープールからメモリーの回収を優先するレベルを制御します。swappinessパラメーターの値の設定:- 値を高くすると、ファイルマップ駆動型のワークロードが優先され、RAM のアクティブにアクセスされるプロセスの匿名マッピングメモリーをスワップアウトします。これは、ストレージのファイルのデータに依存するファイルサーバーやストリーミングアプリケーションが、サービスリクエストの I/O レイテンシーを低減させるためにメモリーに駐在するのに便利です。
値が小さいほど、ページキャッシュ (ファイルマップされたメモリー) を回収しつつ、匿名のマッピング駆動型ワークロードが優先されます。この設定は、ファイルシステム情報に大きく依存しないアプリケーション、数学的アプリケーションや数値計算アプリケーションなどの動的に割り当てられたメモリーやプライベートメモリーを大幅に使用するアプリケーション、QEMU のような一部のハードウェア仮想化スーパーバイザーにおいて有用です。
vm.swappinessパラメーターのデフォルト値は60です。警告vm.swappinessを0に設定すると、匿名メモリーをディスクにスワップアウトする必要がなくなります。これにより、メモリーまたは I/O 集約型のワークロード下でoom_killer関数によるプロセスの強制終了のリスクが高まります。
38.4. ファイルシステムパラメーター リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムパラメーターは、/proc/sys/fs ディレクトリーにリスト表示されます。利用可能なファイルシステムパラメーターを以下に示します。
aio-max-nr-
すべてのアクティブな非同期入出力コンテキストで許可されるイベントの最大数を定義します。デフォルト値は
65536で、この値を変更しても、カーネルデータ構造の割り当てまたはサイズ変更は行われません。 file-maxシステム全体でのファイルハンドルの最大数を決定します。Red Hat Enterprise Linux 9 のデフォルト値は、
8192またはカーネル起動時に利用可能な空きメモリーページの 10 分の 1 のいずれか高い方になります。この値を設定すると、利用可能なファイルハンドルがないためにエラーを解決できます。
38.5. カーネルパラメーター リンクのコピーリンクがクリップボードにコピーされました!
カーネルパラメーターのデフォルト値は /proc/sys/kernel/ ディレクトリーにあります。これらは、カーネルによって提供される設定されたデフォルト値、または sysctl を介してユーザーによって指定された値です。
以下は、msg* および shm* System V IPC (sysvipc) システムコールの制限を設定するのに使用されるカーネルパラメーターです。
msgmax-
メッセージキューの単一のメッセージに対する最大許容サイズ (バイト単位) を定義します。この値は、キューのサイズ (
msgmnb) を超えることはできません。sysctl msgmaxコマンドを使用して、システムの現在のmsgmax値を確認します。 msgmnb-
単一のメッセージキューの最大サイズをバイト単位で定義します。
sysctl msgmnbコマンドを使用して、システムの現在のmsgmnb値を確認します。 msgmni-
メッセージキュー識別子の最大数 (つまりキューの最大数) を定義します。
sysctl msgmniコマンドを使用して、システムの現在のmsgmni値を確認します。 shmall-
一度にシステムで使用できる共有メモリー
pagesの合計量を定義します。たとえば、AMD64 アーキテクチャーおよび Intel 64 アーキテクチャーでは、ページは4096バイトになります。sysctl shmallコマンドを使用して、システムの現在のshmall値を確認します。 shmmax-
カーネルが許可する単一の共有メモリーセグメントの最大サイズをバイト単位で定義します。カーネルで、1Gb までの共有メモリーセグメントがサポートされるようになりました。
sysctl shmmaxコマンドを使用して、システムの現在のshmmax値を確認します。 shmmni-
システム全体の共有メモリーセグメントの最大数を定義します。いずれのシステムでもデフォルト値は
4096です。
第39章 Huge Page の設定 リンクのコピーリンクがクリップボードにコピーされました!
物理メモリーは、ページと呼ばれる固定サイズのブロックで管理されます。Red Hat Enterprise Linux 9 が対応する x86_64 アーキテクチャーでは、メモリーページのデフォルトサイズは 4 KB です。このデフォルトのページサイズは、さまざまなワークロードをサポートする Red Hat Enterprise Linux などの一般的なオペレーティングシステムに適しています。
ただし、特定のアプリケーションは、特定のケースで大きなページサイズを使用する利点を得られます。たとえば、数百メガバイトまたは数千ギガバイトの大規模で比較的固定されたデータセットで動作するアプリケーションでは、4 KB ページを使用するとパフォーマンスの問題が発生する可能性があります。このようなデータセットには大量の 4 KB ページが必要になるため、オペレーティングシステムや CPU でオーバーヘッドが発生する可能性があります。
このセクションでは、RHEL 9 で利用可能なヒュージページとその設定方法を説明します。
39.1. 利用可能な Huge Page の機能 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 9 では、大規模なデータセットに対応するアプリケーションに Huge Page を使用し、このようなアプリケーションのパフォーマンスを向上できます。
以下は、RHEL 9 でサポートされる Huge Page メソッドです。
HugeTLB pagesHugeTLB ページも静的なヒュージページと呼ばれます。HugeTLB ページを予約する方法は 2 つあります。
- ブート時: メモリーが大幅に断片化されていないため、成功する可能性が高くなります。ただし、NUMA マシンでは、ページ数は NUMA ノード間で自動的に分割されます。
起動時に HugeTLB ページの動作に影響を与えるパラメーターの詳細は、Parameters for reserving HugeTLB pages at boot time を参照し、これらのパラメーターを使用して起動時に HugeTLB ページを設定する方法の詳細は、Configuring HugeTLB at boot time を参照してください。
- ランタイム時に: NUMA ノードごとにヒュージページを予約することができます。ランタイム予約がブートプロセスの早い段階で行われると、メモリーの断片化はより低くなります。
ランタイム時に HugeTLB ページの動作に影響を与えるパラメーターの詳細は、ランタイム時に HugeTLB ページを確保するためのパラメーター を参照し、これらのパラメーターを使用してランタイム時に HugeTLB ページを設定する方法の詳細は、ランタイム時の HugeTLB の設定 を参照してください。
transparent huge page (THP)THP を使用すると、カーネルがプロセスに huge page を自動的に割り当てます。そのため、静的な huge page を手動で予約する必要がありません。THP には次の 2 つの動作モードがあります。
-
system-wide: huge page の割り当てが可能であり、大きな連続した仮想メモリー領域をプロセスが使用している場合に、カーネルがプロセスへの huge page の割り当てを試みます。 per-process:madvise() システムコールを使用して指定できる個々のプロセスのメモリー領域にのみ、カーネルが huge page を割り当てます。注記THP 機能でサポートされているのは、
2 MBのページだけです。
-
起動時に HugeTLB ページの動作に影響を与えるパラメーターの詳細は、transparent huge page の有効化 および transparent huge page の無効化 を参照してください。
39.2. 起動時に HugeTLB ページを確保するためのパラメーター リンクのコピーリンクがクリップボードにコピーされました!
システムの起動時に HugeTLB ページの動作に影響を与える場合は、次のパラメーターを使用します。
これらのパラメーターを使用してブート時に HugeTLB ページを設定する方法の詳細は、ブート時に HugeTLB を設定する を参照してください。
| パラメーター | 説明 | デフォルト値 |
|---|---|---|
|
| ブート時にカーネルに設定される永続ヒュージページの数を定義します。 NUMA システムでは、このパラメーターが定義されている Huge Page はノード間で均等に分割されます。
ランタイム時に |
デフォルト値は
起動時にこの値を更新するには、 |
|
| 起動時にカーネルに設定される永続ヒュージページのサイズを定義します。 |
有効な値は |
|
| 起動時にカーネルに設定される永続 Huge Page のデフォルトのサイズを定義します。 |
有効な値は |
39.3. 起動時の HugeTLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
HugeTLB サブシステムがサポートするページサイズは、アーキテクチャーによって異なります。x86_64 アーキテクチャーは、2 MB の Huge Page および 1 GB のギガンティックページをサポートします。
この手順では、システムの起動時に 1 GB ページを予約する方法を説明します。
手順
1 GBページの HugeTLB プールを作成するには、default_hugepagesz=1Gおよびhugepagesz=1Gカーネルオプションを有効にします。grubby --update-kernel=ALL --args="default_hugepagesz=1G hugepagesz=1G"
# grubby --update-kernel=ALL --args="default_hugepagesz=1G hugepagesz=1G"Copy to Clipboard Copied! Toggle word wrap Toggle overflow /usr/lib/systemd/system/ディレクトリーにhugetlb-gigantic-pages.serviceという新しいファイルを作成し、以下の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow /usr/lib/systemd/ディレクトリーにhugetlb-reserve-pages.shという新しいファイルを作成し、以下の内容を追加します。以下の内容を追加する場合、number_of_pages を、予約する 1GB ページ数に置き換え、node を、これらのページを予約するノードの名前に置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、node0 で 2 つの
1 GBページ、node1 で 1GB のページを予約するには、number_of_pages を、node0 の場合は 2 に置き換え、node1 の場合は 1 に置き換えます。reserve_pages 2 node0 reserve_pages 1 node1
reserve_pages 2 node0 reserve_pages 1 node1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実行可能なスクリプトを作成します。
chmod +x /usr/lib/systemd/hugetlb-reserve-pages.sh
# chmod +x /usr/lib/systemd/hugetlb-reserve-pages.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 初期のブート予約を有効にします。
systemctl enable hugetlb-gigantic-pages
# systemctl enable hugetlb-gigantic-pagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
任意のタイミングで
nr_hugepagesに書き込みを行うことにより、ランタイム時にさらに1 GBページを予約してみることができます。ただし、メモリーの断片化による障害を防ぐために、起動プロセスの早い段階で1 GBのページを予約します。 - 静的 Huge Page を確保することで、システムで利用可能なメモリー量を効果的に減らすことができます。ただし、メモリーの全容量を適切に使用できなくなります。予約された Huge Page の適切なサイズプールは、これを使用するアプリケーションにとって有益になりますが、予約済み Huge Page の過度なサイズや未使用のプールは最終的にシステムパフォーマンス全体に悪影響を及ぼします。予約済みの Huge Page プールを設定する場合は、システムによってメモリーの最大容量を適切に利用できるようになります。
39.4. ランタイム時に HugeTLB ページを確保するためのパラメーター リンクのコピーリンクがクリップボードにコピーされました!
実行時に HugeTLB ページの動作に影響を与える場合は、以下のパラメーターを使用します。
これらのパラメーターを使用してランタイム時に HugeTLB ページを設定する方法の詳細は、ランタイム時の HugeTLB の設定 を参照してください。
| パラメーター | 説明 | ファイル名 |
|---|---|---|
|
| 指定された NUMA ノードに割り当てられる指定したサイズの Huge Page の数を定義します。 |
|
|
| オーバーコミットメモリーを介してシステムで作成され、使用できる追加の Huge Page の最大数を定義します。 このファイルにゼロ以外の値を書き込むと、永続 Huge Page プールが使い切られると、システムはカーネルの通常のページプールからその数の Huge Page を取得することを示しています。これら超過分の Huge Page は使用されなくなるので、これらは解放され、カーネルの通常のページプールに戻ります。 |
|
39.5. ランタイム時の HugeTLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、20 2048 kB Huge Page を node2 に追加する方法を説明します。
要件に基づいてページを確保するには、以下を置き換えます。
- 20 (予約する Huge Page 数)
- Huge Page のサイズを含めた 2048kB
- ページを予約するノードのある node2。
手順
メモリー統計を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 指定のサイズの Huge Page 数をノードに追加します。
echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages
# echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Huge Page の数が追加されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
39.6. transparent huge page の管理 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 9 では、transparent huge page (THP) がデフォルトで有効になっています。ただし、ランタイム設定、TuneD プロファイル、カーネルコマンドラインパラメーター、または systemd ユニットファイルを使用すると、transparent huge page を有効、無効、または madvise に設定できます。
39.6.1. ランタイム設定を使用した transparent huge page の管理 リンクのコピーリンクがクリップボードにコピーされました!
実行時に transparent huge page (THP) を管理して、メモリー使用量を最適化できます。ランタイム設定はシステムの再起動後まで保持されません。
手順
THP のステータスを確認します。
cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を設定します。
THP を有効にする場合:
echo always > /sys/kernel/mm/transparent_hugepage/enabled
$ echo always > /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を無効にする場合:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
$ echo never > /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を
madviseに設定する場合:echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
$ echo madvise > /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションが必要以上に多くのメモリーリソースを割り当てることを防ぐには、システム全体の THP を無効にし、
madviseシステムコールを通じて THP を明示的に要求するアプリケーションに対してのみ THP を有効にします。注記短期的な割り当てのレイテンシーが低くなると、有効期間の長い割り当てで最適パフォーマンスをすぐに実現するよりも優先度が高くなります。この場合は、THP を有効にしたままでも直接圧縮を無効にできます。
直接圧縮は、huge page の割り当て中の同期メモリー圧縮です。直接圧縮を無効にすると、メモリーの保存は保証されませんが、頻繁なページ障害の発生時にレイテンシーが高くなる可能性が減ります。また、直接圧縮を無効にすると、
madviseで示される仮想メモリー領域 (VMA) の同期圧縮のみが可能になります。ワークロードが THP から著しく異なる場合に、パフォーマンスが低下する点に注意してください。直接圧縮を無効にします。$ echo never > /sys/kernel/mm/transparent_hugepage/defrag
39.6.2. TuneD プロファイルを使用した transparent huge page の管理 リンクのコピーリンクがクリップボードにコピーされました!
TuneD プロファイルを使用して transparent huge page (THP) を管理できます。TuneD プロファイルの設定は、tuned.conf ファイルで指定します。この設定はシステムの再起動後も維持されます。
前提条件
-
TuneDパッケージがインストールされている。 -
TuneDサービスが有効になっている。
手順
アクティブなプロファイルファイルを同じディレクトリーにコピーします。
sudo cp -R /usr/lib/tuned/my_profile /usr/lib/tuned/my_copied_profile
$ sudo cp -R /usr/lib/tuned/my_profile /usr/lib/tuned/my_copied_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow tune.confファイルを編集します。sudo vi /usr/lib/tuned/my_copied_profile/tuned.conf
$ sudo vi /usr/lib/tuned/my_copied_profile/tuned.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を有効にするには、次の行を追加します。
[bootloader] cmdline = transparent_hugepage=always
[bootloader] cmdline = transparent_hugepage=alwaysCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を無効にするには、次の行を追加します。
[bootloader] cmdline = transparent_hugepage=never
[bootloader] cmdline = transparent_hugepage=neverCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を
madviseに設定するには、次の行を追加します。[bootloader] cmdline = transparent_hugepage=madvise
[bootloader] cmdline = transparent_hugepage=madviseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
TuneDサービスを再起動します。sudo systemctl restart tuned
$ sudo systemctl restart tunedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいプロファイルをアクティブに設定します。
sudo tuned-adm profile my_copied_profile
$ sudo tuned-adm profile my_copied_profileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
新しいプロファイルがアクティブであることを確認します。
sudo tuned-adm active
$ sudo tuned-adm activeCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP の必要なモードが設定されていることを確認します。
cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow
39.6.3. カーネルコマンドラインパラメーターを使用した transparent huge page の管理 リンクのコピーリンクがクリップボードにコピーされました!
カーネルパラメーターを変更することで、起動時に transparent huge page (THP) を管理できます。この設定はシステムの再起動後も維持されます。
前提条件
- システムの root 権限がある。
手順
現在のカーネルコマンドラインパラメーターを取得します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カーネルパラメーターを追加して THP を設定します。
THP を有効にする場合:
grubby --args="transparent_hugepage=always" --update-kernel=DEFAULT
# grubby --args="transparent_hugepage=always" --update-kernel=DEFAULTCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を無効にする場合:
grubby --args="transparent_hugepage=never" --update-kernel=DEFAULT
# grubby --args="transparent_hugepage=never" --update-kernel=DEFAULTCopy to Clipboard Copied! Toggle word wrap Toggle overflow THP を
madviseに設定する場合:grubby --args="transparent_hugepage=madvise" --update-kernel=DEFAULT
# grubby --args="transparent_hugepage=madvise" --update-kernel=DEFAULTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
システムを再起動して変更を有効にします。
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
THP のステータスを確認するには、次のファイルを表示します。
cat /sys/kernel/mm/transparent_hugepage/enabled always madvise [never]
# cat /sys/kernel/mm/transparent_hugepage/enabled always madvise [never]Copy to Clipboard Copied! Toggle word wrap Toggle overflow grep AnonHugePages: /proc/meminfo AnonHugePages: 0 kB
# grep AnonHugePages: /proc/meminfo AnonHugePages: 0 kBCopy to Clipboard Copied! Toggle word wrap Toggle overflow grep nr_anon_transparent_hugepages /proc/vmstat nr_anon_transparent_hugepages 0
# grep nr_anon_transparent_hugepages /proc/vmstat nr_anon_transparent_hugepages 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
39.6.4. systemd ユニットファイルを使用した transparent huge page の管理 リンクのコピーリンクがクリップボードにコピーされました!
systemd ユニットファイルを使用すると、システムの起動時に transparent huge page (THP) を管理できます。systemd サービスを作成すると、システムの再起動後も THP 設定が維持されます。
前提条件
- システムの root 権限がある。
手順
-
THP を有効、無効、および
madviseに設定するための新しい systemd サービスファイルを作成します。たとえば、/etc/systemd/system/disable-thp.serviceです。 新しい systemd サービスファイルに次の内容を追加して THP を設定します。
THP を有効にするには、
<new_thp_file>.serviceファイルに次の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow THP を無効にするには、
<new_thp_file>.serviceファイルに次の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow THP を
madviseに設定するには、<new_thp_file>.serviceファイルに次の内容を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
サービスを有効にして起動します。
systemctl enable <new_thp_file>.service
# systemctl enable <new_thp_file>.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl start <new_thp_file>.service
# systemctl start <new_thp_file>.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
THP のステータスを確認するには、次のファイルを表示します。
cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow
39.7. 翻訳されたバッファーサイズのページサイズの影響 リンクのコピーリンクがクリップボードにコピーされました!
ページテーブルからアドレスマッピングを読み取るのは、非常に時間がかかり、リソースの負荷が高くなります。そのため、CPU は、トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) と呼ばれる、最近使用されたアドレスのキャッシュで構築されます。ただし、デフォルトの TLB は、特定のアドレスマッピングのみをキャッシュできます。
要求されたアドレスマッピングが TLB ミスと呼ばれる TLB にない場合、システムはページテーブルを読み込んで、物理から仮想アドレスへのマッピングを判断する必要があります。アプリケーションメモリー要件と、アドレスマッピングのキャッシュに使用されるページサイズ間の関係により、メモリー要件が高いアプリケーションは、最小限であるアプリケーションと比べて、TLB ミスによるパフォーマンスの低下の影響が高くなる可能性があります。したがって、可能であれば TLB ミスを回避するためには重要です。
HugeTLB 機能と Transparent Huge Page 機能の両方を使用すると、アプリケーションは 4 KB よりも大きなページを使用できます。これにより、TLB に保存されているアドレスはより多くのメモリーを参照できます。これにより、TLB ミスが軽減され、アプリケーションのパフォーマンスが向上します。
第40章 SystemTap の使用 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、SystemTap を使用して、実行中の RHEL システム上のバグやパフォーマンスの問題の根本的な原因を特定できます。
アプリケーション開発者は、SystemTap を使用して、RHEL システム内でアプリケーションがどのように動作するかを詳細に監視できます。
40.1. SystemTap の目的 リンクのコピーリンクがクリップボードにコピーされました!
SystemTap は、オペレーティングシステム (特にカーネル) の動作を詳細に調査および監視するために使用できる追跡およびプロービングツールです。SystemTap は、netstat、ps、top、iostat などのツールの出力に似た情報を提供します。ただし、SystemTap は収集した情報をフィルタリング、分析するためのオプションがより多く用意されています。SystemTap スクリプトでは、SystemTap が収集する情報を指定します。
SystemTap は、カーネルアクティビティーを追跡するインフラストラクチャーを提供し、2 つの属性とこの機能を統合して、Linux 監視ツールの既存のスイートを補完することを目的としています。
- 柔軟性
- SystemTap フレームワークを使用すると、さまざまなカーネル機能、システムコール、カーネルスペースで発生するその他のイベントに関する調査および監視目的のシンプルなスクリプトを開発できます。つまり、SystemTap はツールというよりも、独自のカーネル固有のフォレンジックおよび監視ツールの開発を可能にするシステムといえます。
- 使いやすさ
- SystemTap を使用すると、カーネルを再コンパイルしたり、システムを再起動したりせずに、カーネルのアクティビティーを監視できます。
40.2. SystemTap のインストール リンクのコピーリンクがクリップボードにコピーされました!
SystemTap の使用を開始するには、必要なパッケージをインストールします。システムに複数のカーネルがインストールされている複数のカーネルで SystemTap を使用するには、カーネルバージョン ごと に必要な対応カーネルパッケージをインストールします。
前提条件
- デバッグリポジトリーおよびソースリポジトリーの有効化 で説明されているように、デバッグリポジトリーを有効にしている。
手順
必要な SystemTap パッケージをインストールします。
dnf install systemtap
# dnf install systemtapCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なカーネルパッケージをインストールします。
stap-prepの使用:stap-prep
# stap-prepCopy to Clipboard Copied! Toggle word wrap Toggle overflow stap-prepが機能しない場合は、必要なカーネルパッケージを手動でインストールします。dnf install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -i)-$(uname -r) kernel-devel-$(uname -r)
# dnf install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -i)-$(uname -r) kernel-devel-$(uname -r)Copy to Clipboard Copied! Toggle word wrap Toggle overflow $(uname -i)は、システムのハードウェアプラットフォームに自動的に置き換えられ、$(uname -r)は、実行中のカーネルのバージョンに自動的に置き換えられます。
検証
SystemTap でプローブするカーネルが現在使用中である場合 n には、インストールが成功したかどうかを確認します。
stap -v -e 'probe kernel.function("vfs_read") {printf("read performed\n"); exit()}'# stap -v -e 'probe kernel.function("vfs_read") {printf("read performed\n"); exit()}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow SystemTap デプロイメントに成功すると、以下のような出力が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力の最後の 3 行 (
Pass 5で開始) は、以下のようになります。
40.3. SystemTap を実行する特権 リンクのコピーリンクがクリップボードにコピーされました!
SystemTap スクリプトを実行するには、システム権限の昇格が必要になりますが、場合によっては、権限のないユーザーが自身のマシン上で SystemTap インストルメンテーションを実行する必要がある場合があります。
ユーザーが root アクセスなしで SystemTap を実行できるようにするには、以下の 両方 のユーザーグループにユーザーを追加します。
stapdevこのグループのメンバーは
stapを使用して SystemTap スクリプトを実行したり、staprunを使用して SystemTap インストルメンテーションモジュールを実行したりできます。stapの実行では、SystemTap スクリプトがカーネルモジュールにコンパイルされ、それがカーネルに読み込まれます。これにはシステムに対する権限の昇格が必要となり、stapdevメンバーにはそれが付与されます。ただし、この権限はstapdevメンバーに有効な root アクセスも付与することになります。このため、stapdevグループのメンバーシップは、root アクセスを信頼して付与できるメンバーにのみ許可してください。stapusr-
このグループのメンバーが SystemTap インストルメンテーションモジュールの実行に使用できるのは、
staprunのみです。また、これらのモジュールは/lib/modules/kernel_version/systemtap/ディレクトリーからしか実行できません。このディレクトリーの所有や書き込みが可能なのは root ユーザーだけでなければなりません。
40.4. SystemTap スクリプトの実行 リンクのコピーリンクがクリップボードにコピーされました!
SystemTap スクリプトは、標準入力またはファイルから実行できます。
SystemTap のインストール時に配布されるサンプルスクリプトは、便利な SystemTap スクリプトの例 または /usr/share/systemtap/examples ディレクトリーにあります。
前提条件
- Installing Systemtap で説明されているように、SystemTap および関連する必須カーネルパッケージがインストールされている。
SystemTap スクリプトを通常のユーザーとして実行するには、そのユーザーを SystemTap グループに追加します。
usermod --append --groups stapdev,stapusr user-name
# usermod --append --groups stapdev,stapusr user-nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
SystemTap スクリプトを実行します。
標準入力の場合:
stap -e "probe timer.s(1) {exit()}"# stap -e "probe timer.s(1) {exit()}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、
stap -eに対して、丸括弧内のスクリプトを標準入力で実行するように指示します。ファイルから:
stap file_name.stp
# stap file_name.stpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
40.5. 便利な SystemTap スクリプトの例 リンクのコピーリンクがクリップボードにコピーされました!
SystemTap のインストール時に配布されるサンプルスクリプトは、/usr/share/systemtap/examples ディレクトリーにあります。
stap コマンドを使用して、さまざまな SystemTap スクリプトを実行できます。
- 関数呼び出しのトレース
para-callgraph.stpSystemTap スクリプトを使用して、関数の呼び出しと関数の戻り値をトレースできます。stap para-callgraph.stp argument1 argument2
# stap para-callgraph.stp argument1 argument2Copy to Clipboard Copied! Toggle word wrap Toggle overflow このスクリプトは、2 つのコマンドライン引数を取ります。1 つは、開始/終了をトレースする対象となる関数の名前です。もう 1 つは、トリガー関数です (任意)。この関数は、スレッドごとのトレースを有効または無効にします。トリガー関数が終了するまで、各スレッドでのトレースが継続されます。
- ポーリングアプリケーションの監視
timeout.stp SystemTap スクリプトを使用して、どのアプリケーションがポーリングしているかを特定および監視できます。これを把握することで、不要なポーリングや過剰なポーリングを追跡できます。これは、トラッキングは、CPU 使用率や省電力を改善するための領域を特定するのに役立ちます。
stap timeout.stp
# stap timeout.stpCopy to Clipboard Copied! Toggle word wrap Toggle overflow このスクリプトは、各アプリケーションが
poll、select、epoll、itimer、futex、nanosleep、Signalシステムコールを何回使用したかを経時的に追跡します。- プロセスごとのシステムコールボリュームの追跡
syscalls_by_proc.stpSystemTap スクリプトを使用して、システムコールを最も多く実行しているプロセスを確認できます。システムコールを最も多く実行している 20 個のプロセスが表示されます。stap syscalls_by_proc.stp
# stap syscalls_by_proc.stpCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ネットワークソケットコードで呼び出された関数の追跡
socket-trace.stpSystemTap サンプルスクリプトを使用して、カーネルの net/socket.c ファイルから呼び出された関数を追跡できます。これにより、各プロセスがカーネルレベルでネットワークとどのように対話しているかを詳細に確認できます。stap socket-trace.stp
# stap socket-trace.stpCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 各ファイルの読み取りまたは書き込みの I/O 時間の追跡
iotime.stpSystemTap スクリプトを使用して、各プロセスがファイルへの読み取りまたは書き込みを行うのにかかる時間を監視できます。これにより、システムへの読み込みに時間がかかっているファイルを判断する上で役立ちます。stap iotime.stp
# stap iotime.stpCopy to Clipboard Copied! Toggle word wrap Toggle overflow - タスクからサイクルを奪っている IRQ やその他のプロセスを追跡する
cycle_thief.stpSystemTap スクリプトを使用すると、タスクが実行されている時間と実行されていない時間を追跡できます。これにより、どのプロセスがタスクからサイクルを奪っているかを特定できます。stap cycle_thief.stp -x pid
# stap cycle_thief.stp -x pidCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SystemTap スクリプトの詳細な例と情報は、/usr/share/systemtap/examples/index.html ファイルにあります。Web ブラウザーで開くと、使用可能なすべてのスクリプトとその説明がリスト表示されます。
第41章 SystemTap のクロスインストルメンテーション リンクのコピーリンクがクリップボードにコピーされました!
SystemTap のクロスインストルメンテーションは、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを作成し、SystemTap が完全にデプロイされていない別のシステムで使用します。
41.1. SystemTap のクロスインストルメンテーション リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが SystemTap スクリプトを実行すると、そのスクリプトからカーネルモジュールが構築されます。次に SystemTap はモジュールをカーネルに読み込みます。
通常、SystemTap スクリプトは SystemTap がデプロイされているシステムでのみ実行できます。SystemTap を 10 台のシステムで実行するには、このようなすべてのシステムに SystemTap をデプロイする必要があります。場合によっては、これは実現不可能または推奨されない場合があります。たとえば、企業のポリシーで、特定のマシンにコンパイラーやデバッグ情報を提供するパッケージのインストールが禁止されている場合には、SystemTap のデプロイメントができなくなります。
この状況を回避するために、クロスインストルメンテーション を使用します。クロスインストルメンテーションとは、あるコンピューターの SystemTap スクリプトから SystemTap インストルメンテーションモジュールを生成して、別のシステムで使用するプロセスです。このプロセスには、以下のような効果があります。
各種マシンのカーネル情報パッケージを単一のホストマシにインストールできる。
重要カーネルのパッケージ化にバグがあると、インストールが妨げられる場合があります。このような場合に ホストシステム と ターゲットシステム の
kernel-debuginfoおよびkernel-develパッケージが同じでなければなりません。バグが発生した場合は、https://bugzilla.redhat.com/ でバグを報告します。生成された SystemTap インストルメンテーションモジュール (
systemtap-runtime) を使用するには、ターゲットマシン ごとインストールする必要があるパッケージは 1 つだけです。重要構築された インストルメンテーションモジュール が機能するには、ホストシステム と ターゲットシステム が同一アーキテクチャーで同じ Linux ディストリビューションを実行している必要があります。
- インストルメンテーションモジュール
- SystemTap スクリプトから構築したカーネルモジュール。SystemTap モジュールは ホストシステム 上に構築され、ターゲットシステム の ターゲットカーネル に読み込まれます。
- ホストシステム
- ターゲットシステム に読み込めるように (SystemTap スクリプトから) インストルメンテーションモジュールをコンパイルするシステム。
- ターゲットシステム
- (SystemTap スクリプトから) インストルメンテーションモジュール を構築するシステム。
- ターゲットカーネル
- ターゲットシステム のカーネル。インストルメンテーションモジュール を読み込み、実行するカーネルです。
41.2. SystemTap のクロスインストルメンテーションの初期化 リンクのコピーリンクがクリップボードにコピーされました!
SystemTap のクロスインストルメンテーションを初期化し、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを構築して SystemTap が完全にデプロイされていない別のシステムで使用します。
前提条件
- SystemTap のインストール で説明されているように、SystemTap が ホストシステム にインストールされている。
各 ターゲットシステム に
systemtap-runtimeパッケージがインストールされている。dnf install systemtap-runtime
# dnf install systemtap-runtimeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ホストシステム と ターゲットシステム の両方のアーキテクチャーが同じである。
- ホストシステム と ターゲットシステム の両方が同じメジャーバージョンの Red Hat Enterprise Linux (Red Hat Enterprise Linux 9 など) を実行している。
カーネルパッケージのバグが原因で複数の kernel-debuginfo と kernel-devel パッケージがシステムにインストールできない場合があります。このような場合は、ホストシステム と ターゲットシステム のマイナーバージョンが同じでなければなりません。バグが発生した場合は、https://bugzilla.redhat.com/ で報告してください。
手順
各 ターゲットシステム で実行しているカーネルを確認します。
uname -r
$ uname -rCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲットシステム ごとにこの手順を繰り返します。
- Systemtap のインストール で説明されている方法に従って、ホストシステム で各 ターゲットシステム の ターゲットカーネル と関連パッケージをインストールします。
ホストシステム でインストルメンテーションモジュールを構築し、このモジュールをコピーして ターゲットシステム でこのモジュールを実行します。
リモート実装の使用
stap --remote target_system script
# stap --remote target_system scriptCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、指定したスクリプトを ターゲットシステム にリモートで実装します。これを正常に実行するには、ホストシステム から ターゲットシステム に SSH 接続できるようしておく必要があります。
手動:
ホストシステム でインストルメンテーションモジュールを構築します。
stap -r kernel_version script -m module_name -p 4
# stap -r kernel_version script -m module_name -p 4Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、kernel_version は手順 1 で判断した ターゲットカーネル を、script は インストルメンテーションモジュール に変換するスクリプトを、module_name は インストルメンテーションモジュール の任意の名前を指します。
-p4オプションは、SystemTap にコンパイルしたモジュールを読み込まないように指示します。インストルメンテーションモジュールがコンパイルされたら、ターゲットシステムにコピーして、以下のコマンドを使用して読み込みます。
staprun module_name.ko
# staprun module_name.koCopy to Clipboard Copied! Toggle word wrap Toggle overflow