システムの状態とパフォーマンスの監視と管理

Red Hat Enterprise Linux 9

システムのスループット、レイテンシー、および電力消費の最適化

Red Hat Customer Content Services

概要

さまざまなシナリオで Red Hat Enterprise Linux 9 のスループット、レイテンシー、消費電力を監視して最適化します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

Jira からのフィードバック送信 (アカウントが必要)

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

第1章 TuneD を使い始める

システム管理者は、TuneD アプリケーションを使用して、さまざまなユースケースに合わせてシステムのパフォーマンスプロファイルを最適化できます。

1.1. TuneD の目的

TuneD は、システムを監視し、特定のワークロードでパフォーマンスを最適化するサービスです。TuneD の中核となるのは、さまざまなユースケースに合わせてシステムをチューニングする プロファイル です。

TuneD には、以下のようなユースケース用に定義されたプロファイルが多数同梱されています。

  • 高スループット
  • 低レイテンシー
  • 節電

各プロファイル向けに定義されたルールを変更し、特定のデバイスのチューニング方法をカスタマイズできます。別のプロファイルに切り替えたり、TuneD を非アクティブにすると、以前のプロファイルによるシステム設定への変更はすべて、元の状態に戻ります。

また、TuneD を設定してデバイスの使用状況の変化に対応し、設定を調整して、アクティブなデバイスのパフォーマンスを向上させ、非アクティブなデバイスの消費電力を削減することもできます。

1.2. TuneD プロファイル

システムを詳細に分析することは、非常に時間のかかる作業です。TuneD では、一般的なユースケースに合わせて定義済みのプロファイルを多数提供しています。プロファイルを作成、変更、および削除することも可能です。

TuneD で提供されるプロファイルは、以下のカテゴリーに分類されます。

  • 省電力プロファイル
  • パフォーマンス重視プロファイル

performance-boosting プロファイルの場合は、次の側面に焦点が置かれます。

  • ストレージおよびネットワークに対して少ないレイテンシー
  • ストレージおよびネットワークの高い処理能力
  • 仮想マシンのパフォーマンス
  • 仮想化ホストのパフォーマンス

プロファイル設定の構文

tuned.conf ファイルは、1 つの [main] セクションとプラグインインスタンスを設定するためのその他のセクションが含まれます。ただし、すべてのセクションはオプションです。

ハッシュ記号 (#) で始まる行はコメントです。

関連情報

  • tuned.conf(5) の man ページ

1.3. デフォルトの TuneD プロファイル

インストール時に、システムの最適なプロファイルが自動的に選択されます。現時点では、以下のカスタマイズ可能なルールに従ってデフォルトのプロファイルが選択されます。

環境デフォルトプロファイル目的

コンピュートノード

throughput-performance

最適なスループットパフォーマンス

仮想マシン

virtual-guest

ベストパフォーマンスベストパフォーマンスが重要でない場合は、balanced プロファイルまたは powersave プロファイルに変更できます。

その他のケース

balanced

パフォーマンスと電力消費の調和

関連情報

  • tuned.conf(5) の man ページ

1.4. マージされた TuneD プロファイル

試験目的で提供された機能として、複数のプロファイルを一度に選択することができます。TuneD は、読み込み中にマージを試みます。

競合が発生した場合は、最後に指定されたプロファイルの設定が優先されます。

例1.1 仮想ゲストの低消費電力

以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。

# tuned-adm profile virtual-guest powersave
警告

マージは自動的に行われ、使用されるパラメーターの組み合わせが適切であるかどうかはチェックされません。結果として、この機能は一部のパラメーターを逆に調整する可能性があります。これは逆効果になる可能性があります。たとえば、throughput-performance プロファイルで高スループットにディスクを設定し、同時に、spindown-disk プロファイルでディスクスピンダウンを低い値に設定します。

関連情報

*tuned-adm man ページ* tuned.conf(5) の man ページ

1.5. TuneD プロファイルの場所

TuneD は、次のディレクトリーにプロファイルを保存します。

/usr/lib/tuned/
ディストリビューション固有のプロファイルは、このディレクトリーに保存されます。各プロファイルには独自のディレクトリーがあります。プロファイルは tuned.conf という名前の主要設定ファイルと、ヘルパースクリプトなどの他の任意のファイルから設定されます。
/etc/tuned/
プロファイルをカスタマイズする必要がある場合は、プロファイルのカスタマイズに使用されるディレクトリーにプロファイルディレクトリーをコピーします。同じ名前のプロファイルが 2 つある場合、カスタムのプロファイルは、/etc/tuned/ に置かれています。

関連情報

  • tuned.conf(5) の man ページ

1.6. RHEL とともに配布される TuneD プロファイル

以下は、Red Hat Enterprise Linux に TuneD とともにインストールされるプロファイルのリストです。

注記

利用可能な製品固有またはサードパーティーの TuneD プロファイルが複数存在する可能性があります。このようなプロファイルは通常、個別の RPM パッケージで提供されます。

balanced

デフォルトの省電力プロファイル。パフォーマンスと電力消費のバランスを取ることが目的です。可能な限り、自動スケーリングと自動チューニングを使用します。唯一の欠点はレイテンシーが増加することです。今回の TuneD リリースでは、CPU、ディスク、オーディオ、およびビデオプラグインを有効にし、conservative CPU ガバナーを有効にします。radeon_powersave オプションは、dpm-balanced 値に対応している場合はその値を使用し、それ以外の場合は auto に設定されます。

energy_performance_preference 属性を normal の電力設定に変更します。また、scaling_governor ポリシー属性を conservative または powersave CPU ガバナーのいずれかに変更します。

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 または powersave CPU ガバナーのいずれかに変更します。

注記

場合によっては、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 プロファイルに基づきます。さらに、透過的な 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-guest

throughput-performance プロファイルに基づく Red Hat Enterprise 9 仮想マシンおよび VMWare ゲスト向けプロファイル。仮想メモリーのスワップの減少や、ディスクの readahead 値の増加などが行われます。ディスクバリアは無効になりません。

throughput-performance プロファイルを継承します。また、energy_performance_preference および scaling_governor 属性を performance プロファイルに変更します。

virtual-host

throughput-performance プロファイルに基づいて仮想ホスト用に設計されたプロファイル。他のタスクの中でも特に、仮想メモリーのスワップを減らし、ディスクの先読み値を増やし、ダーティーページの書き戻しというより積極的な値を可能にします。

throughput-performance プロファイルを継承します。また、energy_performance_preference および scaling_governor 属性を performance プロファイルに変更します。

oracle
Oracle データベース向けに最適化されたプロファイルは、throughput-performance プロファイルに基づいて読み込まれます。これにより Transparent Huge Page が無効になり、その他のパフォーマンス関連カーネルパラメーターが変更されます。このプロファイルは、tuned-profiles-oracle パッケージで利用できます。
desktop
balanced プロファイルに基づく、デスクトップに最適化されたプロファイル。対話型アプリケーションの応答を向上させるスケジューラーオートグループが有効になります。
optimize-serial-console

printk 値を減らすことで、シリアルコンソールへの I/O アクティビティーを調整するプロファイル。これにより、シリアルコンソールの応答性が向上します。このプロファイルは、他のプロファイルのオーバーレイとして使用することが意図されています。以下に例を示します。

# tuned-adm profile throughput-performance optimize-serial-console
mssql
Microsoft SQL Server に提供されるプロファイル。throughput-performance プロファイルに基づきます。
intel-sst

ユーザー定義の Intel Speed Select Technology 設定で最適化されたプロファイル。このプロファイルは、他のプロファイルのオーバーレイとして使用することが意図されています。以下に例を示します。

# tuned-adm profile cpu-partitioning intel-sst

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 の図

cpu パーティション設定

/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 では、すべてのサービス、デーモン、ユーザープロセス、移動可能なカーネルスレッド、割り込みハンドラー、およびカーネルタイマーの実行が許可されます。

関連情報

  • tuned-profiles-cpu-partitioning(7) man ページ

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-partitioning TuneD プロファイルをインストールしている。

手順

  1. /etc/tuned/cpu-partitioning-variables.conf ファイルを編集し、以下の内容を追加します。

    # All isolated CPUs:
    isolated_cores=2-23
    # Isolated CPUs without the kernel’s scheduler load balancing:
    no_balance_cores=2,3
  2. cpu-partitioning TuneD プロファイルを設定します。

    # tuned-adm profile cpu-partitioning
  3. 再起動

    再起動後、システムは、cpu-partitioning の図の分離に従って、低レイテンシーにチューニングされます。このアプリケーションでは、タスクセットを使用して、リーダーおよびライターのスレッドを CPU 2 および 3 に固定し、残りのアプリケーションスレッドを CPU 4-23 に固定できます。

関連情報

  • tuned-profiles-cpu-partitioning(7) man ページ

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 を設定します。

手順

  1. /etc/tuned/my_profile ディレクトリーを作成します。

    # mkdir /etc/tuned/my_profile
  2. このディレクトリーに tuned.conf ファイルを作成し、次の内容を追加します。

    # vi /etc/tuned/my_profile/tuned.conf
    [main]
    summary=Customized tuning on top of cpu-partitioning
    include=cpu-partitioning
    [cpu]
    force_latency=cstate.id:0|1
  3. 新しいプロファイルを使用します。

    # tuned-adm profile my_profile
注記

この共有例では、再起動は必要ありません。ただし、my_profile プロファイルの変更を有効にするために再起動が必要な場合は、マシンを再起動します。

関連情報

  • tuned-profiles-cpu-partitioning(7) man ページ

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 つのカテゴリー (staticdynamic) の違いを理解することは、特定の状況や目的にどちらを使用するかを決定する際に重要です。

静的なチューニング
主に、事前定義された 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

1.13. TuneD のインストールと有効化

この手順では、TuneD アプリケーションをインストールして有効にし、TuneD プロファイルをインストールして、システムにデフォルトの TuneD プロファイルをあらかじめ設定します。

手順

  1. Tuned パッケージをインストールします。

    # dnf install tuned
  2. Tuned サービスを有効にして開始します。

    # systemctl enable --now tuned
  3. 必要に応じて、リアルタイムシステムのTuneD プロファイルをインストールします。

    リアルタイムシステムの Tuned プロファイルの場合は、rhel-9 リポジトリーを有効にします。

    # subscription-manager repos --enable=rhel-9-for-x86_64-nfv-beta-rpms

    インストールします。

    # dnf install tuned-profiles-realtime tuned-profiles-nfv
  4. TuneDプロファイルが有効であり、適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: throughput-performance
    注記

    TuneD が自動的にプリセットするアクティブなプロファイルは、マシンのタイプとシステム設定によって異なります。

    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

1.14. 利用可能な TuneD プロファイルのリスト表示

この手順では、使用しているシステムで現在利用可能なTuneDプロファイルのリストを表示します。

手順

  • システムで使用可能なすべてのTuneDプロファイルをリスト表示するには、次を使用します。

    $ tuned-adm list
    
    Available profiles:
    - accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states
    - balanced                - General non-specialized TuneD profile
    - desktop                 - Optimize for the desktop use-case
    - latency-performance     - Optimize for deterministic performance at the cost of increased power consumption
    - network-latency         - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
    - network-throughput      - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
    - powersave               - Optimize for low power consumption
    - throughput-performance  - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
    - virtual-guest           - Optimize for running inside a virtual guest
    - virtual-host            - Optimize for running KVM guests
    Current active profile: balanced
  • 現在アクティブなプロファイルのみを表示する場合は、次のコマンドを使用します。

    $ tuned-adm active
    
    Current active profile: throughput-performance

関連情報

  • tuned-adm(8) の man ページ

1.15. TuneD プロファイルの設定

この手順では、選択した TuneD プロファイルを有効にします。

前提条件

手順

  1. 必要に応じて、TuneD がシステムに最も適したプロファイルを推奨できます。

    # tuned-adm recommend
    
    throughput-performance
  2. プロファイルをアクティブ化します。

    # tuned-adm profile selected-profile

    または、複数のプロファイルの組み合わせをアクティベートできます。

    # tuned-adm profile selected-profile1 selected-profile2

    例1.3 低消費電力向けに最適化された仮想マシン

    以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。

    # tuned-adm profile virtual-guest powersave
  3. お使いのシステムで現在アクティブな TuneD プロファイルを表示します。

    # tuned-adm active
    
    Current active profile: selected-profile
  4. システムを再起動します。

    # reboot

検証手順

  • 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(8) の man ページ

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 API メソッドを確認するには、次のコマンドを実行します。

    $ busctl introspect com.redhat.tuned /Tuned com.redhat.tuned.control

    この出力は、以下のようになります。

    NAME                       	TYPE  	SIGNATURE RESULT/VALUE FLAGS
    .active_profile            	method	-     	  s            -
    .auto_profile              	method	-     	  (bs)         -
    .disable                   	method	-      	  b            -
    .get_all_plugins           	method	-     	  a{sa{ss}}    -
    .get_plugin_documentation  	method	s     	  s            -
    .get_plugin_hints          	method	s     	  a{ss}        -
    .instance_acquire_devices  	method	ss    	  (bs)         -
    .is_running                	method	-     	  b            -
    .log_capture_finish        	method	s     	  s            -
    .log_capture_start         	method	ii    	  s            -
    .post_loaded_profile       	method	-     	  s            -
    .profile_info              	method	s     	  (bsss)       -
    .profile_mode              	method	-     	  (ss)         -
    .profiles                  	method	-     	  as           -
    .profiles2                 	method	-     	  a(ss)        -
    .recommend_profile         	method	-     	  s            -
    .register_socket_signal_path    method	s     	  b            -
    .reload                    	method	-     	  b            -
    .start                     	method	-     	  b            -
    .stop                      	method	-     	  b            -
    .switch_profile            	method	s     	  (bs)         -
    .verify_profile            	method	-     	  b            -
    .verify_profile_ignore_missing  method	-     	  b            -
    .profile_changed           	signal	sbs   	  -            -

    利用可能なさまざまなメソッドの説明は、TuneD のアップストリームリポジトリー に記載されています。

1.16.2. TuneD D-Bus インターフェイスを使用したアクティブな TuneD プロファイルの変更

TuneD D-Bus インターフェイスを使用して、アクティブな TuneD プロファイルを必要な TuneD プロファイルに置き換えることができます。

前提条件

手順

  • アクティブな TuneD プロファイルを変更するには、次のコマンドを実行します。

    $ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control switch_profile s profile
    (bs) true "OK"

    profile は、必要なプロファイルの名前に置き換えます。

検証

  • 現在アクティブな TuneD プロファイルを表示するには、次のコマンドを実行します。

    $ busctl call com.redhat.tuned /Tuned com.redhat.tuned.control active_profile
    s "profile"

1.17. TuneD の無効化

この手順では、TuneD を無効にし、影響を受けるすべてのシステム設定を TuneD が変更する前の元の状態にリセットします。

手順

  • すべてのチューニングを一時的に無効にするには、次のコマンドを実行します。

    # tuned-adm off

    チューニングは、TuneD サービスの再起動後に再度適用されます。

  • または、TuneD サービスを完全に停止して無効にするには、次のようにします。

    # systemctl disable --now tuned

関連情報

  • tuned-adm(8) の man ページ

第2章 TuneD プロファイルのカスタマイズ

TuneDプロファイルを作成または変更して、ユースケースに合わせてシステムパフォーマンスを最適化できます。

前提条件

2.1. TuneD プロファイル

システムを詳細に分析することは、非常に時間のかかる作業です。TuneD では、一般的なユースケースに合わせて定義済みのプロファイルを多数提供しています。プロファイルを作成、変更、および削除することも可能です。

TuneD で提供されるプロファイルは、以下のカテゴリーに分類されます。

  • 省電力プロファイル
  • パフォーマンス重視プロファイル

performance-boosting プロファイルの場合は、次の側面に焦点が置かれます。

  • ストレージおよびネットワークに対して少ないレイテンシー
  • ストレージおよびネットワークの高い処理能力
  • 仮想マシンのパフォーマンス
  • 仮想化ホストのパフォーマンス

プロファイル設定の構文

tuned.conf ファイルは、1 つの [main] セクションとプラグインインスタンスを設定するためのその他のセクションが含まれます。ただし、すべてのセクションはオプションです。

ハッシュ記号 (#) で始まる行はコメントです。

関連情報

  • tuned.conf(5) の man ページ

2.2. デフォルトの TuneD プロファイル

インストール時に、システムの最適なプロファイルが自動的に選択されます。現時点では、以下のカスタマイズ可能なルールに従ってデフォルトのプロファイルが選択されます。

環境デフォルトプロファイル目的

コンピュートノード

throughput-performance

最適なスループットパフォーマンス

仮想マシン

virtual-guest

ベストパフォーマンスベストパフォーマンスが重要でない場合は、balanced プロファイルまたは powersave プロファイルに変更できます。

その他のケース

balanced

パフォーマンスと電力消費の調和

関連情報

  • tuned.conf(5) の man ページ

2.3. マージされた TuneD プロファイル

試験目的で提供された機能として、複数のプロファイルを一度に選択することができます。TuneD は、読み込み中にマージを試みます。

競合が発生した場合は、最後に指定されたプロファイルの設定が優先されます。

例2.1 仮想ゲストの低消費電力

以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようにシステムが最適化され、同時に、(低消費電力が最優先である場合は) 低消費電力を実現するようにシステムがチューニングされます。

# tuned-adm profile virtual-guest powersave
警告

マージは自動的に行われ、使用されるパラメーターの組み合わせが適切であるかどうかはチェックされません。結果として、この機能は一部のパラメーターを逆に調整する可能性があります。これは逆効果になる可能性があります。たとえば、throughput-performance プロファイルで高スループットにディスクを設定し、同時に、spindown-disk プロファイルでディスクスピンダウンを低い値に設定します。

関連情報

*tuned-adm man ページ* tuned.conf(5) の man ページ

2.4. TuneD プロファイルの場所

TuneD は、次のディレクトリーにプロファイルを保存します。

/usr/lib/tuned/
ディストリビューション固有のプロファイルは、このディレクトリーに保存されます。各プロファイルには独自のディレクトリーがあります。プロファイルは tuned.conf という名前の主要設定ファイルと、ヘルパースクリプトなどの他の任意のファイルから設定されます。
/etc/tuned/
プロファイルをカスタマイズする必要がある場合は、プロファイルのカスタマイズに使用されるディレクトリーにプロファイルディレクトリーをコピーします。同じ名前のプロファイルが 2 つある場合、カスタムのプロファイルは、/etc/tuned/ に置かれています。

関連情報

  • tuned.conf(5) の man ページ

2.5. TuneD プロファイル間の継承

TuneDプロファイルは、他のプロファイルを基にして、親プロファイルの特定の側面のみを変更できます。

TuneD プロファイルの [main] セクションは、include オプションを認識します。

[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

関連情報

  • tuned.conf(5) の man ページ

2.6. TuneD の静的および動的チューニング

TuneD が適用するシステムチューニングの 2 つのカテゴリー (staticdynamic) の違いを理解することは、特定の状況や目的にどちらを使用するかを決定する際に重要です。

静的なチューニング
主に、事前定義された 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
チューニングプラグインのタイプです。
DEVICES

このプラグインインスタンスが処理するデバイスのリストです。

device の行には、リスト、ワイルドカード (*)、否定 (!) が含まれます。device の行がないと、TYPE のシステムに現在または後で接続されるすべてのデバイスは、プラグインインスタンスにより処理されます。devices=* オプションを使用する場合と同じです。

例2.4 ブロックデバイスとプラグインのマッチング

次の例では、sdasdb など sd で始まるすべてのブロックデバイスに一致し、それらに対する境界は無効にしない例になります。

[data_disk]
type=disk
devices=sd*
disable_barriers=false

次の例は、sda1 および sda2 を除くすべてのブロックデバイスと一致します。

[data_disk]
type=disk
devices=!sda1, !sda2
disable_barriers=false

プラグインのインスタンスを指定しないと、そのプラグインは有効になりません。

このプラグインがより多くのオプションに対応していると、プラグインセクションでも指定できます。このオプションが指定されておらず、含まれているプラグインでこれまで指定しなかった場合は、デフォルト値が使用されます。

短いプラグイン構文

プラグインインスタンスにカスタム名を付ける必要がなく、設定ファイルにインスタンスの定義が 1 つしかない場合、TuneD は以下の簡単な構文に対応します。

[TYPE]
devices=DEVICES

この場合は、type の行を省略することができます。タイプと同様に、インスタンスは名前で参照されます。上記の例は、以下のように書き換えることができます。

例2.5 短い構文を使用したブロックデバイスのマッチング

[disk]
devices=sdb*
disable_barriers=false

プロファイルで競合するプラグインの定義

include オプションを使用して同じセクションを複数回指定した場合は、設定がマージされます。設定をマージできない場合は、競合がある以前の設定よりも、競合がある最後の定義が優先されます。以前に定義されたものが分からない場合は、replace ブール式オプションを使用して、それを true に設定します。これにより、同じ名前の以前の定義がすべて上書きされ、マージは行われません。

また、enabled=false オプションを指定してプラグインを無効にすることもできます。これは、インスタンスが定義されない場合と同じ効果になります。include オプションから以前の定義を再定義し、カスタムプロファイルでプラグインをアクティブにしない場合には、プラグインを無効にすると便利です。

注記

TuneD には、チューニングプロファイルの有効化または無効化の一環として、シェルコマンドを実行する機能が含まれます。これにより、TuneD に統合されていない機能で、TuneD プロファイルを拡張できます。

任意のシェルコマンドは、script プラグインを使用して指定できます。

関連情報

  • tuned.conf(5) の man ページ

2.8. 利用可能な TuneD プラグイン

プラグインの監視

現在、以下の監視プラグインが実装されています。

disk
デバイスおよび測定間隔ごとのディスク負荷 (IO 操作の数) を取得します。
net
ネットワークカードおよび測定間隔ごとのネットワーク負荷 (転送済みパケットの数) を取得します。
load
CPU および測定間隔ごとの CPU 負荷を取得します。

プラグインのチューニング

現在、以下のチューニングプラグインが実装されています。動的チューニングを実装するのは、これらのプラグインの一部のみです。プラグインで対応しているオプションもリスト表示されます。

cpu

CPU ガバナーを、governor オプションで指定された値に設定し、CPU 負荷に応じて、電源管理サービス品質 (PM QoS) CPU ダイレクトメモリーアクセス (DMA) のレイテンシーを動的に変更します。

CPU 負荷が load_threshold オプションで指定された値よりも小さい場合、レイテンシーは latency_high オプションで指定した値に設定されます。それ以外では、latency_low で指定した値に設定されます。

レイテンシーを特定の値に強制し、さらに動的に変更しないようにすることもできます。これを行うには、force_latency オプションを、必要なレイテンシーの値に設定します。

eeepc_she

CPU の負荷に応じて、フロントサイドバス (FSB) の速度を動的に設定します。

この機能は一部のネットブックで利用でき、ASUS Super buf 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 プラグインを使用します。他の特定プラグインが、この設定に対応している場合は、そのプラグインを使用することが推奨されます。

usb

USB デバイスの autosuspend タイムアウトを、autosuspend パラメーターで指定した値に設定します。

値が 0 の場合は、autosuspend が無効になります。

vm

transparent_hugepages オプションの値に合わせて、Transparent Huge Page を有効または無効にします。

transparent_hugepages オプションの有効な値は次のとおりです。

  • "always"
  • "never"
  • "madvise"
audio

音声コーデックの autosuspend タイムアウトを、timeout オプションで指定した値に設定します。

現在、snd_hda_intel コーデックおよび snd_ac97_codec コーデックに対応しています。値が 0 の場合は、autosuspend が無効になります。また、ブール値オプション reset_controllertrue に設定することにより、コントローラーを強制的にリセットすることもできます。

disk

elevator オプションで指定された値にディスクエレベーターを設定します。

また、以下も設定します。

  • apm オプションで指定された値への APM
  • scheduler_quantum オプションで指定された値へのスケジューラーの量子
  • spindown オプションで指定された値へのディスクスピンダウンタイムアウト
  • readahead パラメーターで指定した値までディスク先読み
  • 現在のディスクが、readahead_multiply オプションで指定した定数を掛けた値に先読みされます。

さらに、このプラグインにより、現在のドライブ使用状況に応じて、ドライブの高度な電力管理設定および spindown タイムアウト設定が動的に変更します。動的チューニングは、ブール値オプション dynamic により制御でき、デフォルトで有効になります。

scsi_host

SCSI ホストのオプションをチューニングします。

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
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 2 ブートローダーのみに対応しています。

grub2_cfg_file オプションを使用すると、GRUB 2 設定ファイルの場所を、標準以外のカスタマイズされた場所に指定できます。

そのカーネルオプションは、現在の GRUB 設定とそのテンプレートに追加されます。カーネルオプションを有効にするには、システムを再起動する必要があります。

別のプロファイルに切り替えるか、TuneD サービスを手動で停止すると、追加のオプションが削除されます。システムをシャットダウンまたは再起動しても、カーネルオプションは grub.cfg ファイルに残ります。

カーネルオプションは、以下の構文で指定できます。

cmdline=arg1 arg2 ... argN

例2.7 カーネルコマンドラインの変更

たとえば、quiet カーネルオプションを TuneD プロファイルに追加するには、tuned.conf ファイルに次の行を含めます。

[bootloader]
cmdline=quiet

以下に、isolcpus=2 オプションをカーネルコマンドラインに追加するカスタムプロファイルの例を示します。

[bootloader]
cmdline=isolcpus=2
service

プラグインオプションで指定されたさまざまな sysvinitsysv-rcopenrc、および 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 プラグインは、systemd init システム以外の現在のランレベルでのみ動作します。

例2.8 オーバーレイファイルを使用した sendmail サービスの開始および有効化

[service]
service.sendmail=start,enable,file:${i:PROFILE_DIR}/tuned-sendmail.conf

内部変数 ${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.*

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 パラメーターは、以下の値と動作をサポートします。

calc

isolated_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

スケジューリングポリシー

プロセスまたはスレッドのグループのスケジューリングポリシー、優先度、およびアフィニティーを調整するには、以下の構文を使用します。

group.groupname=rule_prio:sched:prio:affinity:regex

ここで rule_prio は、ルールの内部 TuneD 優先度を定義します。ルールは優先度に基づいてソートされます。これは、継承が以前に定義されたルールを並べ替えることができるようにするために必要です。同等の rule_prio ルールは、定義された順序で処理される必要があります。ただし、これは Python インタープリターに依存します。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 プラグインは、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

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 つの cgroupsgroup1、および group2 を作成します。cgroup group1 アフィニティーを CPU 2 に設定し、cgroup group2 を CPU 0 および 2 に設定します。4 つの CPU 設定を指定すると、isolated_cores=1 オプションはすべてのプロセスとスレッドを CPU コア 0、2、および 3 に移動します。ps_blacklist 正規表現で指定されたプロセスおよびスレッドは移動されません。

[scheduler]
cgroup_mount_point=/sys/fs/cgroup/cpuset
cgroup_mount_point_init=1
cgroup_groups_init=1
cgroup_for_isolated_cores=group
cgroup.group1=2
cgroup.group2=0,2

group.ksoftirqd=0:f:2:cgroup.group1:ksoftirqd.*
ps_blacklist=ksoftirqd.*;rcuc.*;rcub.*;ktimersoftd.*
isolated_cores=1

cgroup_ps_blacklist オプションは、指定された cgroups に属するプロセスを除外します。このオプションで指定された正規表現は、/proc/PID/cgroupscgroup 階層と照合されます。コンマ (,) は、正規表現の一致前に cgroups v1 階層を /proc/PID/cgroups から分離します。以下は、正規表現が照合される内容の例です。

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 プラグインは、階層 ID が 8 で、controller-list blkio を持つ cgroup に属するすべてのプロセスを除外します。

[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" 値を設定します。

    古いカーネルで以下のパラメーターを設定すると、sysctl500000 の値を /proc/sys/kernel/sched_migration_cost_ns ファイルに書き込むことを意味します。

    [sysctl]
    kernel.sched_migration_cost_ns=500000

    これは、最近のカーネルでは、scheduler プラグインを介して次のパラメーターを設定するのと同じです。

    [scheduler]
    sched_migration_cost_ns=500000

    つまり、TuneD500000 の値を /sys/kernel/debug/sched/migration_cost_ns ファイルに書き込みます。

2.10. TuneD プロファイルの変数

TuneD プロファイルがアクティブになると、変数は実行時にデプロイメントします。

TuneD変数を使用すると、TuneDプロファイルで必要な入力を減らすことができます。

TuneDプロファイルには事前定義された変数はありません。プロファイルに [variables] セクションを作成し、以下の構文を使用すると、独自の変数を定義できます。

[variables]

variable_name=value

プロファイル内の変数の値をデプロイメントするには、以下の構文を使用します。

${variable_name}

例2.16 変数を使用した CPU コアの分離

以下の例では、${isolated_cores} 変数が 1,2 にデプロイメントされるため、カーネルは isolcpus=1,2 オプションで起動します。

[variables]
isolated_cores=1,2

[bootloader]
cmdline=isolcpus=${isolated_cores}

変数は個別のファイルで指定できます。たとえば、次の行を tuned.conf に追加できます。

[variables]
include=/etc/tuned/my-variables.conf

[bootloader]
cmdline=isolcpus=${isolated_cores}

isolated_cores=1,2 オプションを /etc/tuned/my-variables.conf ファイルに追加すると、カーネルが isolcpus=1,2 オプションで起動します。

関連情報

  • tuned.conf(5) の man ページ

2.11. TuneD プロファイルの組み込み関数

組み込み関数は、TuneD プロファイルがアクティブになると、実行時に拡張します。

これにより、以下が可能になります。

  • さまざまな組み込み関数と、TuneD変数の使用
  • Python でカスタム関数を作成し、プラグインの形式でTuneD に追加します。

関数を呼び出すには、以下の構文を使用します。

${f:function_name:argument_1:argument_2}

プロファイルと tuned.conf ファイルが置かれたディレクトリーパスをデプロイメントするには、特殊な構文が必要な 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}}

cpulist_invert 関数は、CPU のリストを反転します。6 CPU のマシンでは、反転が 1,2 になり、カーネルは isolcpus=1,2 コマンドラインオプションで起動します。

関連情報

  • tuned.conf(5) の man ページ

2.12. TuneD プロファイルで利用可能な組み込み関数

すべての TuneD プロファイルで、以下の組み込み関数を使用できます。

PROFILE_DIR
プロファイルと tuned.conf ファイルが置かれているディレクトリーパスを返します。
exec
プロセスを実行し、その出力を返します。
assertion
2 つの引数を比較します。一致しない 場合、関数は最初の引数からテキストをログに記録し、プロファイルの読み込みを中止します。
assertion_non_equal
2 つの引数を比較します。2 つの引数が 一致する 場合、関数は最初の引数からテキストをログに記録し、プロファイルの読み込みを中止します。
kb2s
キロバイトをディスクセクターに変換します。
s2kb
ディスクセクターをキロバイトに変換します。
strip
渡されたすべての引数から文字列を作成し、最初と最後の空白の両方を削除します。
virt_check

TuneD が仮想マシン (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プロファイルを作成します。

前提条件

手順

  1. /etc/tuned/ ディレクトリーで、作成するプロファイルと同じ名前の新しいディレクトリー作成します。

    # mkdir /etc/tuned/my-profile
  2. 新しいディレクトリーに、ファイル tuned.conf を作成します。必要に応じて、[main] セクションとプラグイン定義を追加します。

    たとえば、balanced プロファイルの設定を表示します。

    [main]
    summary=General non-specialized TuneD profile
    
    [cpu]
    governor=conservative
    energy_perf_bias=normal
    
    [audio]
    timeout=10
    
    [video]
    radeon_powersave=dpm-balanced, auto
    
    [scsi_host]
    alpm=medium_power
  3. プロファイルをアクティベートするには、次のコマンドを実行します。

    # tuned-adm profile my-profile
  4. TuneD プロファイルが有効であり、システム設定が適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

関連情報

  • tuned.conf(5) の man ページ

2.14. 既存の TuneD プロファイルの変更

この手順では、既存のTuneD プロファイルに基づいて変更した子プロファイルを作成します。

前提条件

手順

  1. /etc/tuned/ ディレクトリーで、作成するプロファイルと同じ名前の新しいディレクトリー作成します。

    # mkdir /etc/tuned/modified-profile
  2. 新しいディレクトリーに、ファイル tuned.conf を作成し、以下のように [main] セクションを設定します。

    [main]
    include=parent-profile

    parent-profile を、変更しているプロファイルの名前に置き換えます。

  3. プロファイルの変更を含めます。

    例2.18 throughput-performance プロファイルでスワップを低減

    throughput-perfromance プロファイルの設定を使用し、vm.swappiness の値を、デフォルトの 10 ではなく 5 に変更するには、以下を使用します。

    [main]
    include=throughput-performance
    
    [sysctl]
    vm.swappiness=5
  4. プロファイルをアクティベートするには、次のコマンドを実行します。

    # tuned-adm profile modified-profile
  5. TuneD プロファイルが有効であり、システム設定が適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

関連情報

  • tuned.conf(5) の man ページ

2.15. TuneD を使用したディスクスケジューラーの設定

この手順では、選択したブロックデバイスに特定のディスクスケジューラーを設定するTuneD プロファイルを作成して有効にします。この設定は、システムを再起動しても持続します。

以下のコマンドと設定で、以下の内容を置き換えます。

  • device をブロックデバイスの名前に置き換えます (例: sdf)。
  • selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例: bfq)。

前提条件

手順

  1. 必要に応じて、プロファイルのベースとなる既存のTuneDプロファイルを選択します。利用可能なプロファイルのリストは、RHEL とともに配布される TuneD プロファイル を参照してください。

    現在アクティブなプロファイルを確認するには、次のコマンドを実行します。

    $ tuned-adm active
  2. TuneD プロファイルを保持する新しいディレクトリーを作成します。

    # mkdir /etc/tuned/my-profile
  3. 選択したブロックデバイスのシステム固有の識別子を見つけます。

    $ 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
    注記

    この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。

  4. /etc/tuned/my-profile/tuned.conf 設定ファイルを作成します。このファイルで、以下のオプションを設定します。

    1. 必要に応じて、既存のプロファイルを追加します。

      [main]
      include=existing-profile
    2. WWN 識別子に一致するデバイスに対して選択したディスクスケジューラーを設定します。

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      ここでは、以下のようになります。

      • IDNAME を、使用されている識別子名に置き換えます (例:ID_WWN)。
      • device system unique id を、選択した識別子の値に置き換えます (例:0x5002538d00000000)。

        devices_udev_regex オプションで複数のデバイスに一致させるには、識別子を括弧で囲み、垂直バーで区切ります。

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. プロファイルを有効にします。

    # tuned-adm profile my-profile

検証手順

  1. TuneD プロファイルがアクティブで、適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. /sys/block/device/queue/scheduler ファイルの内容を読み取ります。

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

    アクティブなスケジューラーは、角括弧 ([]) にリスト表示されます。

第3章 tuna インターフェイスを使用したシステムの確認

tuna ツールは、チューニングタスクを実行する際の複雑性を軽減します。tuna を使用して、スケジューラーの調整可能パラメーターの調整、スレッド優先度や IRQ ハンドラーのチューニング、CPU コアおよびソケットの分離を行います。tuna ツールを使用すると、次の操作を実行できます。

  • システム上の CPU の表示
  • システム上で現在実行中の割り込み要求 (IRQ) の表示
  • スレッドに関するポリシーおよび優先度の情報の変更
  • システムの現在のポリシーと優先度の表示

3.1. tuna ツールのインストール

tuna ツールは、稼働中のシステムで使用されるように設計されています。これにより、アプリケーション固有の測定ツールで、変更の直後にシステムパフォーマンスを確認および分析できます。

手順

  • tuna ツールをインストールします。

    # dnf install tuna

検証手順

  • 利用可能な tuna CLI オプションを表示します。

    # tuna -h

関連情報

  • tuna(8) の man ページ

3.2. tuna ツールを使用したシステムの状態の表示

tuna コマンドラインインターフェイス (CLI) ツールを使用して、システムの状態を表示できます。

前提条件

手順

  1. 現在のポリシーおよび優先度を表示します。

    # tuna show_threads
    pid   SCHED_ rtpri affinity             cmd
    1      OTHER     0      0,1            init
    2       FIFO    99        0     migration/0
    3      OTHER     0        0     ksoftirqd/0
    4       FIFO    99        0      watchdog/0

    あるいは、PID に対応する、またはコマンド名に一致する特定のスレッドを表示するには、次のように入力します。

    # tuna show_threads -t pid_or_cmd_list

    pid_or_cmd_list 引数は、コンマ区切りの PID またはコマンド名パターンのリストです。

  2. シナリオに応じて、次のいずれかのアクションを実行します。

  3. 変更した設定を保存します。

    # tuna save filename

    このコマンドは、現在実行中のカーネルスレッドのみを保存します。実行していないプロセスは保存されません。

関連情報

  • システム上の tuna(8) man ページ

3.3. tuna ツールを使用した CPU のチューニング

tuna ツールコマンドは、個別の CPU をターゲットとして指定できます。tuna ツールを使用すると、次のアクションを実行できます。

Isolate CPUs
指定した CPU で実行しているすべてのタスクが、次に利用可能な CPU に移動します。CPU を分離すると、すべてのスレッドのアフィニティーマスクから CPU が削除され、CPU が利用できなくなります。
Include CPUs
指定された CPU でタスクを実行できるようにします。
Restore CPUs
指定した CPU を以前の設定に戻します。

前提条件

手順

  1. すべての 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
  2. tuna インターフェイスでスレッドリストを表示します。

    # tuna show_threads -t 'thread_list from above cmd'
  3. コマンドの影響を受ける CPU のリストを指定します。

    # *tuna [command] --cpus cpu_list *

    cpu_list 引数は、--cpus 0,2 などのコンマ区切り CPU 番号のリストです。

    現在の cpu_list に特定の CPU を追加するには、たとえば --cpus +0 を使用します。

  4. シナリオに応じて、次のいずれかのアクションを実行します。

    • CPU を分離するには、次のように入力します。

      # tuna isolate --cpus cpu_list
    • CPU を含めるには、次のように入力します。

      # tuna include --cpus cpu_list
  5. 4 つ以上のプロセッサーを搭載したシステムを使用する場合は、すべての ssh スレッドを CPU 01 で実行し、すべての http スレッドを CPU 23 で実行します。

    # tuna move --cpus 0,1 -t ssh*
    # tuna move --cpus 2,3 -t http\*

検証手順

  • 現在の設定を表示し、変更が適用されたことを確認します。

    # tuna show_threads -t ssh*
    
    pid   SCHED_  rtpri  affinity   voluntary   nonvoluntary   cmd
    855   OTHER   0      0,1        23           15            sshd
    
    # tuna show_threads -t http\*
    pid   SCHED_  rtpri  affinity   voluntary   nonvoluntary   cmd
    855   OTHER   0       2,3        23           15           http

関連情報

  • /proc/cpuinfo ファイル
  • システム上の tuna(8) man ページ

3.4. tuna ツールを使用した IRQ のチューニング

/proc/interrupts ファイルには、IRQ ごとの割り込みの数、割り込みのタイプ、およびその IRQ にあるデバイスの名前が記録されます。

前提条件

手順

  1. 現在の IRQ とそれらのアフィニティーを表示します。

    # tuna show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  2. コマンドの影響を受ける IRQ のリストを指定します。

    # tuna [command] --irqs irq_list --cpus cpu_list

    irq_list 引数は、コンマ区切りの IRQ 番号またはユーザー名パターンのリストです。

    [コマンド] を、たとえば --spred に置き換えます。

  3. 指定した CPU に割り込みを移動します。

    # tuna show_irqs --irqs 128
    users            affinity
    128 iwlwifi           0,1,2,3
    
    # tuna move --irqs 128 --cpus 3

    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

関連情報

  • /procs/interrupts ファイル
  • システム上の tuna(8) man ページ

第4章 RHEL システムロールを使用したパフォーマンスの監視

システム管理者は、metrics RHEL システムロールを使用して、システムのパフォーマンスを監視できます。

4.1. RHEL システムロールを使用するためのコントロールノードと管理対象ノードの準備

個々の RHEL システムロールを使用してサービスと設定を管理するには、その前に、コントロールノードと管理対象ノードを準備する必要があります。

4.1.1. RHEL 9 でのコントロールノードの準備

RHEL システムロールを使用する前に、コントロールノードを設定する必要があります。次に、このシステムは、Playbook に従ってインベントリーから管理対象ホストを設定します。

前提条件

  • システムはカスタマーポータルに登録されます。
  • Red Hat Enterprise Linux Server サブスクリプションがシステムにアタッチされている。
  • オプション: Ansible Automation Platform サブスクリプションがシステムにアタッチされている。

手順

  1. Playbook を管理および実行するための ansible という名前のユーザーを作成します。

    [root@control-node]# useradd ansible
  2. 新しく作成した ansible ユーザーに切り替えます。

    [root@control-node]# su - ansible

    このユーザーとして残りの手順を実行します。

  3. SSH の公開鍵と秘密鍵を作成します。

    [ansible@control-node]$ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/ansible/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase): <password>
    Enter same passphrase again: <password>
    ...

    キーファイルの推奨されるデフォルトの場所を使用します。

  4. オプション: 接続を確立するたびに Ansible が SSH キーのパスワードを要求しないように、SSH エージェントを設定します。
  5. ~/.ansible.cfg ファイルを次の内容で作成します。

    [defaults]
    inventory = /home/ansible/inventory
    remote_user = ansible
    
    [privilege_escalation]
    become = True
    become_method = sudo
    become_user = root
    become_ask_pass = True
    注記

    ~/.ansible.cfg ファイルの設定は優先度が高く、グローバルな /etc/ansible/ansible.cfg ファイルの設定をオーバーライドします。

    これらの設定を使用して、Ansible は次のアクションを実行します。

    • 指定されたインベントリーファイルでホストを管理します。
    • 管理対象ノードへの SSH 接続を確立するときに、remote_user パラメーターで設定されたアカウントを使用します。
    • sudo ユーティリティーを使用して、root ユーザーとして管理対象ノードでタスクを実行します。
    • Playbook を適用するたびに、リモートユーザーの root パスワードの入力を求められます。これは、セキュリティー上の理由から推奨されます。
  6. 管理対象ホストのホスト名をリストする ~/inventory ファイルを INI または YAML 形式で作成します。インベントリーファイルでホストのグループを定義することもできます。たとえば、以下は、3 つのホストと US という名前の 1 つのホストグループを含む INI 形式のインベントリーファイルです。

    managed-node-01.example.com
    
    [US]
    managed-node-02.example.com ansible_host=192.0.2.100
    managed-node-03.example.com

    コントロールノードはホスト名を解決できる必要があることに注意してください。DNS サーバーが特定のホスト名を解決できない場合は、ホストエントリーの横に ansible_host パラメーターを追加して、その IP アドレスを指定します。

  7. RHEL システムロールをインストールします。

    • Ansible Automation Platform のない RHEL ホストに、rhel-system-roles パッケージをインストールします。

      [root@control-node]# dnf install rhel-system-roles

      このコマンドは、/usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/ ディレクトリーにコレクションをインストールし、依存関係として ansible-core パッケージをインストールします。

    • Ansible Automation Platform で、ansible ユーザーとして次の手順を実行します。

      1. ~/.ansible.cfg ファイルで コンテンツのプライマリーソースとして Red Hat Automation Hub を定義します
      2. Red Hat Automation Hub から redhat.rhel_system_roles コレクションをインストールします。

        [ansible@control-node]$ ansible-galaxy collection install redhat.rhel_system_roles

        このコマンドは、コレクションを ~/.ansible/collections/ansible_collections/redhat/rhel_system_roles/ ディレクトリーにインストールします。

次のステップ

4.1.2. 管理対象ノードの準備

管理対象ノードはインベントリーにリストされているシステムであり、Playbook に従ってコントロールノードによって設定されます。管理対象ホストに Ansible をインストールする必要はありません。

前提条件

  • コントロールノードを準備している。詳細は、Preparing a control node on RHEL 9 を参照してください。
  • コントロールノードから SSH アクセスできる。

    重要

    root ユーザーとしての直接 SSH アクセスはセキュリティーリスクを引き起こします。このリスクを軽減するには、管理対象ノードを準備するときに、このノード上にローカルユーザーを作成し、sudo ポリシーを設定します。続いて、コントロールノードの Ansible は、ローカルユーザーアカウントを使用して管理対象ノードにログインし、root などの別のユーザーとして Playbook を実行できます。

手順

  1. ansible という名前のユーザーを作成します。

    [root@managed-node-01]# useradd ansible

    コントロールノードは後でこのユーザーを使用して、このホストへの SSH 接続を確立します。

  2. ansible ユーザーのパスワードを設定します。

    [root@managed-node-01]# passwd ansible
    Changing password for user ansible.
    New password: <password>
    Retype new password: <password>
    passwd: all authentication tokens updated successfully.

    Ansible が sudo を使用して root ユーザーとしてタスクを実行する場合は、このパスワードを入力する必要があります。

  3. ansible ユーザーの SSH 公開鍵を管理対象ノードにインストールします。

    1. ansible ユーザーとしてコントロールノードにログインし、SSH 公開鍵を管理対象ノードにコピーします。

      [ansible@control-node]$ ssh-copy-id managed-node-01.example.com
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub"
      The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established.
      ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.
    2. プロンプトが表示されたら、yes と入力して接続します。

      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    3. プロンプトが表示されたら、パスワードを入力します。

      ansible@managed-node-01.example.com's password: <password>
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'managed-node-01.example.com'"
      and check to make sure that only the key(s) you wanted were added.
    4. コントロールノードでコマンドをリモートで実行して、SSH 接続を確認します。

      [ansible@control-node]$ ssh managed-node-01.example.com whoami
      ansible
  4. ansible ユーザーの sudo 設定を作成します。

    1. visudo コマンドを使用して、/etc/sudoers.d/ansible ファイルを作成および編集します。

      [root@managed-node-01]# visudo /etc/sudoers.d/ansible

      通常のエディターと比べて visudo を使用する利点は、このユーティリティーがファイルをインストールする前に基本的な健全性チェックと解析エラーのチェックを提供することです。

    2. /etc/sudoers.d/ansible ファイルで、要件に応じた sudoers ポリシーを設定します。次に例を示します。

      • ansible ユーザーのパスワードを入力した後、このホスト上で任意のユーザーおよびグループとしてすべてのコマンドを実行する権限を ansible ユーザーに付与するには、以下を使用します。

        ansible   ALL=(ALL) ALL
      • ansible ユーザーのパスワードを入力せずに、このホスト上で任意のユーザーおよびグループとしてすべてのコマンドを実行する権限を ansible ユーザーに付与するには、以下を使用します。

        ansible   ALL=(ALL) NOPASSWD: ALL

    または、セキュリティー要件に合わせてより細かいポリシーを設定します。sudoers ポリシーの詳細は、sudoers(5) man ページを参照してください。

検証

  1. すべての管理対象ノード上のコントロールノードからコマンドを実行できることを確認します。

    [ansible@control-node]$ ansible all -m ping
    BECOME password: <password>
    managed-node-01.example.com | SUCCESS => {
        	"ansible_facts": {
        	    "discovered_interpreter_python": "/usr/bin/python3"
        	},
        	"changed": false,
        	"ping": "pong"
    }
    ...

    ハードコーディングされたすべてのホストグループには、インベントリーファイルにリストされているすべてのホストが動的に含まれます。

  2. Ansible command モジュールを使用して管理対象ホスト上で whoami ユーティリティーを実行し、権限昇格が正しく機能することを確認します。

    [ansible@control-node]$ ansible managed-node-01.example.com -m command -a whoami
    BECOME password: <password>
    managed-node-01.example.com | CHANGED | rc=0 >>
    root

    コマンドが root を返した場合、管理対象ノード上で sudo が正しく設定されています。

関連情報

4.2. metrics RHEL システムロールの概要

RHEL システムロールは、複数の RHEL システムをリモートで管理するための一貫した設定インターフェイスを提供する Ansible ロールおよびモジュールのコレクションです。metrics システムロールは、ローカルシステムのパフォーマンス分析サービスを設定します。必要に応じて、ローカルシステムによって監視される一連のリモートシステムも分析の対象とします。metrics システムロールを使用すると、pcp のセットアップとデプロイが Playbook によって処理されるため、pcp を別途設定しなくても、pcp を使用してシステムのパフォーマンスを監視できます。

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

4.3. metrics RHEL システムロールを使用して視覚的にローカルシステムを監視する

この手順では、metrics RHEL システムロールを使用してローカルシステムを監視しながら、同時に Grafana によるデータの視覚化をプロビジョニングする方法について説明します。

前提条件

  • 制御ノードと管理ノードを準備している
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
  • localhost がコントロールノードのインベントリーファイルで設定されている。

    localhost ansible_connection=local

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Manage metrics
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_graph_service: yes
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_graph_service のブール値が value="yes" に設定されているため、Grafana は自動的にインストールされ、データソースとして追加された pcp でプロビジョニングされます。metrics_manage_firewallmetrics_manage_selinux は両方とも true に設定されているため、メトリクスロールは firewall および selinux システムロールを使用して、メトリクスロールが使用するポートを管理します。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml

検証

  • マシンで収集されるメトリクスを視覚化するには、Grafana Web UI へのアクセス の説明どおりに grafana Web インターフェイスにアクセスします。

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

4.4. metrics RHEL システムロールを使用して自己監視するようにシステム群を設定する

この手順では、metrics システムロールを使用して、マシン群が自己監視するように設定する方法を説明します。

前提条件

  • 制御ノードと管理ノードを準備している
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure a fleet of machines to monitor themselves
      hosts: managed-node-01.example.com
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_retention_days: 0
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_manage_firewall metrics_manage_selinux は両方とも true に設定されているため、メトリクスロールは firewall ロールと selinux ロールを使用して、metrics ロールが使用するポートを管理します。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

4.5. metrics RHEL システムロールを使用して、ローカルマシンからマシン群を集中的に監視する

この手順では、メトリクス システムロールを使用してローカルマシンを設定し、マシン群を一元的に監視するとともに、Grafana によるデータの視覚化をプロビジョニングし、Redis によりデータをクエリーする方法について説明します。

前提条件

  • 制御ノードと管理ノードを準備している
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。
  • localhost がコントロールノードのインベントリーファイルで設定されている。

    localhost ansible_connection=local

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    - name: Set up your local machine to centrally monitor a fleet of machines
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
        metrics_manage_firewall: yes
        metrics_manage_selinux: yes

    metrics_graph_service および metrics_query_service のブール値は value="yes" に設定されているため、grafana は、redis にインデックス化された pcp データの記録のあるデータソースとして追加された pcp で自動的にインストールおよびプロビジョニングされます。これにより、pcp クエリー言語をデータの複雑なクエリーに使用できます。metrics_manage_firewallmetrics_manage_selinux は両方とも true に設定されているため、metrics ロールは firewall ロールと selinux ロールを使用して、metrics ロールが使用するポートを管理します。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml

検証

  • マシンによって一元的に収集されるメトリクスのグラフィック表示とデータのクエリーを行うには、Grafana Web UI へのアクセス で説明されているように、grafana Web インターフェイスにアクセスします。

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

4.6. metrics RHEL システムロールを使用してシステムを監視しながら認証を設定する

PCP は、Simple Authentication Security Layer (SASL) フレームワークを介して scram-sha-256 認証メカニズムに対応します。metrics RHEL システムロールは、scram-sha-256 認証メカニズムを使用して認証を設定する手順を自動化します。この手順では、metrics RHEL システムロールを使用して認証を設定する方法について説明します。

前提条件

  • 制御ノードと管理ノードを準備している
  • 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。

手順

  1. 既存の Playbook ファイル (例: ~/playbook.yml) を編集し、認証関連の変数を追加します。

    ---
    - name: Set up authentication by using the scram-sha-256 authentication mechanism
      hosts: managed-node-01.example.com
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_retention_days: 0
        metrics_manage_firewall: true
        metrics_manage_selinux: true
        metrics_username: <username>
        metrics_password: <password>
  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml

検証

  • sasl 設定を確認します。

    # pminfo -f -h "pcp://managed-node-01.example.com?username=<username>" disk.dev.read
    Password: <password>
    disk.dev.read
    inst [0 or "sda"] value 19540

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

4.7. metrics RHEL システムロールを使用して SQL Server のメトリクス収集を設定して有効にする

この手順では、metrics RHEL システムロールを使用して、ローカルシステムでの pcp を使用した Microsoft SQL Server のメトリクス収集の設定と有効化を自動化する方法について説明します。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure and enable metrics collection for Microsoft SQL Server
      hosts: localhost
      roles:
        - rhel-system-roles.metrics
      vars:
        metrics_from_mssql: true
        metrics_manage_firewall: true
        metrics_manage_selinux: true

    metrics_manage_firewallmetrics_manage_selinux は両方とも true に設定されているため、metrics ロールは firewall ロールと selinux ロールを使用して、metrics ロールが使用するポートを管理します。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml

検証

  • pcp コマンドを使用して、SQL Server PMDA エージェント (mssql) が読み込まれ、実行されていることを確認します。

    # pcp
    platform: Linux sqlserver.example.com 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/sqlserver.example.com/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/sqlserver.example.com/pmie.log

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイル
  • /usr/share/doc/rhel-system-roles/metrics/ ディレクトリー

第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 によって制御されます。
  • pminfopmstat などのさまざまなクライアントツールは、同じホストまたはネットワーク上でこのデータを取得、表示、アーカイブ、処理できます。
  • 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 の pcp-zeroconf での設定 を参照してください。

手順

  1. pcp パッケージをインストールします。

    # dnf install pcp
  2. ホストマシンで pmcd サービスを有効にして起動します。

    # systemctl enable pmcd
    
    # systemctl start pmcd

検証手順

  • pmcd プロセスがホストで実行されているかどうかを確認します。

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

5.3. 最小限の PCP 設定のデプロイメント

最小 PCP 設定は、Red Hat Enterprise Linux でパフォーマンス統計を収集します。この設定は、詳細な分析のためにデータを収集するために必要な、実稼働システムに最低限のパッケージを追加します。

作成された tar.gz ファイルおよび pmlogger の出力のアーカイブは、さまざまな PCP ツールを使用して解析し、その他のソースのパフォーマンス情報と比較できます。

前提条件

手順

  1. pmlogger 設定を更新します。

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. pmcd サービスおよび pmlogger サービスを起動します。

    # systemctl start pmcd.service
    
    # systemctl start pmlogger.service
  3. 必要な操作を実行して、パフォーマンスデータを記録します。
  4. pmcd サービスおよび pmlogger サービスを停止します。

    # systemctl stop pmcd.service
    
    # systemctl stop pmlogger.service
  5. 出力を保存し、ホスト名と現在の日時に基づいて名前が付けられた tar.gz ファイルに保存します。

    # cd /var/log/pcp/pmlogger/
    
    # tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)

    このファイルをデプロイメントし、PCP ツールを使用してデータを解析します。

関連情報

5.4. PCP で配布されるシステムサービスおよびツール

Performance Co-Pilot (PCP) には、パフォーマンスの測定に使用できるさまざまなシステムサービスとツールが含まれます。基本パッケージ pcp には、システムサービスと基本ツールが含まれます。追加のツールは、pcp-system-toolspcp-gui、および pcp-devel パッケージで提供されます。

PCP で配布されるシステムサービスのロール

pmcd
PMCD (Performance Metric Collector Daemon)
pmie
Performance Metrics In difference 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 アーカイブファイルのラベルを検証、変更、または修復します。
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-dmcache
設定されたデバイスマッパーキャッシュターゲット (デバイスの IOP、キャッシュデバイスとメタデータデバイスの使用率、各キャッシュデバイスの読み取り/書き込みのヒット率とミス率、比率など) に関する情報を表示します。
pcp-dstat
一度に 1 台のシステムのメトリックを表示します。複数のシステムのメトリックを表示するには、--host オプションを使用します。
pcp-free
システム内の空きメモリーと使用済みメモリーを報告します。
pcp-htop
システム上で実行されているすべてのプロセスとそのコマンドライン引数を、top コマンドと同様の形式で表示しますが、縦横にスクロールしたり、マウスで操作したりすることができます。また、プロセスをツリー形式で表示したり、複数のプロセスを選択して一度に処理することもできます。
pcp-ipcs
呼び出しプロセスが読み取りアクセスできる inter-process communication (IPC) ファシリティーの情報を表示します。
pcp-mpstat
CPU および割り込み関連の統計情報を報告します。
pcp-numastat
カーネルのメモリーアロケータからの NUMA 割り当て統計を表示します。
pcp-pidstat
システム上で動作している個々のタスクやプロセスに関する情報を表示します (CPU パーセンテージ、メモリーやスタックの使用率、スケジューリング、優先度など)。デフォルトでは、ローカルホストのライブデータを報告します。
pcp-shping
pmdashping Performance Metrics Domain Agent (PMDA) がエクスポートした shell-ping サービスメトリクスをサンプリングして報告します。
pcp-ss
pmdasockets PMDA が収集したソケットの統計情報を表示します。
pcp-tapestat
テープデバイスの I/O 統計情報を報告します。
pcp-uptime
システムの稼働時間、現在ログオンしているユーザー数、過去 1 分、5 分、15 分のシステム負荷の平均値を表示します。
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 エラーコードと、それに対応するエラーメッセージを表示します。

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 ファーム
統合型 - 複数の pmlogger ファーム

大規模なデプロイメントの場合、Red Hat は複数の pmlogger ファームを統合させてデプロイすることを推奨します。例えば、ラックやデータセンターごとに 1 つの pmlogger ファームをデプロイします。各 pmlogger ファームは、メトリックを中央の Redis インスタンスに読み込みます。

図5.3 統合型 - 複数の pmlogger ファーム

統合型 - 複数の pmlogger ファーム
注記

デフォルトでは、Redis のデプロイメント設定は、スタンドアロン、localhost となっています。しかし、Redis はオプションとして、データを複数のホストで共有する、高可用性と高スケーラビリティを備えたクラスター形態で実行することができます。また、クラウド上に Redis クラスターをデプロイしたり、クラウドベンダーが提供するマネージド Redis クラスターを利用したりすることも可能です。

関連情報

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 でメトリックのメタデータに変更があった場合、古いアーカイブが書き換えられます。この処理時間は、保存されているアーカイブの数に応じてリニアに変化します。

関連情報

  • pmlogrewrite(1) および pmlogger(1) の man ページ

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 のソフトリミットまたはハードリミットを増やすことで実現できます。詳細は、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_timers file and specify PMLOGGER_DAILY_PARAMS="-E -k X" を更新します。ここで、Xは PCP アーカイブを保持する日数です。
Redis

pmproxy サービスは、pmlogger からのログされたメトリックを Redis インスタンスに送信します。設定ファイル /etc/pcp/pmproxy/pmproxy.conf で保持設定を指定する際に使用できる 2 つのオプションを以下に示します。

  • stream.expire では、古いメトリックを削除するまでの期間を指定します (つまり、指定した秒数の間更新されなかったメトリック)。
  • stream.maxlen は、ホストごとに 1 つのメトリックの最大メトリック値の数を指定します。この設定は、保存期間をログ間隔で割ったものでなければなりません。例えば、保存期間が 14 日、ログ間隔が 60 秒の場合は 20160 となります (60*60*24*14/60)。

関連情報

  • pmproxy(1)pmlogger(1)、および sysctl(8) の man ページ

5.9. 例: 集中ロギングデプロイメントの分析

以下の結果は、集約ロギングセットアップ (pmlogger ファームデプロイメントとも呼ばれる) で集約されています。デフォルトの pcp-zeroconf 5.3.0 インストールでは、各リモートホストが、64 の CPU コア、376 GB RAM、および 1 つのディスクが接続されたサーバーで pmcd を実行している同一のコンテナーインスタンスになります。

ロギング間隔は 10 秒で、リモートノードの proc メトリックは含まれず、メモリー値は Resident Set Size (RSS) の値を参照します。

表5.2 10 秒のロギング間隔の詳細な使用統計

ホスト数1050

1 日あたりの PCP アーカイブストレージ

91 MB

522 MB

pmlogger メモリー

160 MB

580 MB

1 日あたりの pmlogger ネットワーク (In)

2 MB

9 MB

pmproxy メモリー

1.4 GB

6.3 GB

1 日あたりの Redis メモリー

2.6 GB

12 GB

表5.3 60 秒のロギング間隔で、監視対象ホストに応じて使用されるリソース

ホスト数1050100

1 日あたりの PCP アーカイブストレージ

20 MB

120 MB

271 MB

pmlogger メモリー

104 MB

524 MB

1049 MB

1 日あたりの pmlogger ネットワーク (In)

0.38 MB

1.75 MB

3.48 MB

pmproxy メモリー

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 秒のロギング間隔での

例: 集中ロギングデプロイメントの分析 で説明した設定と同じです。

表5.4 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 ファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。

手順

  1. CA 発行の証明書を使用してセキュアな接続を確立するために、コレクターシステム上の PCP TLS 設定ファイルを更新します。

    # cat > /etc/pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = /etc/pcp/tls/server.key
    tls-cert-file = /etc/pcp/tls/server.crt
    tls-client-key-file = /etc/pcp/tls/client.key
    tls-client-cert-file = /etc/pcp/tls/client.crt
    END
  2. PCP コレクターインフラストラクチャーを再起動します。

    # systemctl restart pmcd.service
    # systemctl restart pmproxy.service

検証

  • TLS 設定を確認します。

    • pmcd サービスの場合:

      # grep 'Info:' /var/log/pcp/pmcd/pmcd.log
      [Tue Feb 07 11:47:33] pmcd(6558) Info: OpenSSL 3.0.7 setup
    • pmproxy サービスの場合:

      # grep 'Info:' /var/log/pcp/pmproxy/pmproxy.log
      [Tue Feb 07 11:44:13] pmproxy(6014) Info: OpenSSL 3.0.7 setup

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 ファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップを調整してください。

手順

  1. 次の情報を使用して TLS 設定ファイルを作成します。

    $ home=echo ~
    $ cat > ~/.pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = $home/.pcp/tls/client.key
    tls-cert-file = $home/.pcp/tls/client.crt
    END
  2. セキュアな接続を確立します。

    $ export PCP_SECURE_SOCKETS=enforce
    $ export PCP_TLSCONF_PATH=~/.pcp/tls.conf

検証

  • セキュアな接続が設定されていることを確認します。

    $ pminfo --fetch --host pcps://localhost kernel.all.load
    
    kernel.all.load
        inst [1 or "1 minute"] value 1.26
        inst [5 or "5 minute"] value 1.29
        inst [15 or "15 minute"] value 1.28

5.12. 高メモリー使用率のトラブルシューティング

以下のシナリオでは、メモリー使用率が高くなる可能性があります。

  • pmproxy プロセスは新しい PCP アーカイブの処理がビジーで、Redis の要求および応答を処理するための予備の CPU サイクルがありません。
  • Redis ノードまたはクラスターが過負荷になり、時間が経過しても着信要求を処理できません。

pmproxy サービスデーモンは、Redis ストリームを使用し、設定パラメーター (PCP チューニングパラメーター) をサポートします。これは、Redis のメモリー使用量および鍵の保存に影響します。/etc/pcp/pmproxy/pmproxy.conf ファイルには、pmproxy で利用可能な設定オプションと、関連する API がリスト表示されます。

次の手順では、メモリー使用率が高い問題をトラブルシューティングする方法について説明します。

前提条件

  1. pcp-pmda-redis パッケージをインストールします。

    # dnf install pcp-pmda-redis
  2. redis PMDA をインストールします。

    # cd /var/lib/pcp/pmdas/redis && ./Install

手順

  • 高いメモリー使用率のトラブルシューティングを行うには、次のコマンドを実行して、inflight 列を確認します。

    $ pmrep :pmproxy
             backlog  inflight  reqs/s  resp/s   wait req err  resp err  changed  throttled
              byte     count   count/s  count/s  s/s  count/s   count/s  count/s   count/s
    14:59:08   0         0       N/A       N/A   N/A    N/A      N/A      N/A        N/A
    14:59:09   0         0    2268.9    2268.9    28     0        0       2.0        4.0
    14:59:10   0         0       0.0       0.0     0     0        0       0.0        0.0
    14:59:11   0         0       0.0       0.0     0     0        0       0.0        0.0

    この列は、Redis リクエストが転送中である数を示しています。つまり、キューに入れられているか送信されており、現時点では応答は受信されていません。

    数値が高い場合は、次のいずれかの状態を示します。

    • pmproxy プロセスは新しい PCP アーカイブの処理がビジーで、Redis の要求および応答を処理するための予備の CPU サイクルがありません。
    • Redis ノードまたはクラスターが過負荷になり、時間が経過しても着信要求を処理できません。
  • メモリー使用量が多い問題のトラブルシューティングを行うには、このファームの pmlogger プロセスの数を減らし、別の pmlogger ファームを追加します。統合型 (複数の pmlogger ファームの設定) を使用します。

    Redis ノードが長時間にわたって CPU を 100% 使用している場合は、パフォーマンスが向上しているホストに移動するか、代わりにクラスター化された Redis 設定を使用します。

  • pmproxy.redis.* メトリックスを表示するには、次のコマンドを使用します。

    $ pminfo -ftd pmproxy.redis
    pmproxy.redis.responses.wait [wait time for responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: microsec
        value 546028367374
    pmproxy.redis.responses.error [number of error responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: count
        value 1164
    [...]
    pmproxy.redis.requests.inflight.bytes [bytes allocated for inflight requests]
        Data Type: 64-bit int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: byte
        value 0
    
    pmproxy.redis.requests.inflight.total [inflight requests]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: count
        value 0
    [...]

    インフライトのリクエスト数を表示するには、pmproxy.redis.requests.inflight.total メトリックスと pmproxy.redis.requests.inflight.bytes メトリックスを参照して、現在のすべてのインフライトの Redis リクエストで占有されているバイト数を表示します。

    通常、redis 要求キューは 0 ですが、大きな pmlogger ファームの使用量に基づいて構築できます。これによりスケーラビリティーが制限され、pmproxy クライアントのレイテンシーが高くなる可能性があります。

  • pminfo コマンドを実行すると、パフォーマンスメトリックスの詳細が表示されます。たとえば、redis.* メトリックスを表示するには、次のコマンドを使用します。

    $ pminfo -ftd redis
    redis.redis_build_id [Build ID]
        Data Type: string  InDom: 24.0 0x6000000
        Semantics: discrete  Units: count
        inst [0 or "localhost:6379"] value "87e335e57cffa755"
    redis.total_commands_processed [Total number of commands processed by the server]
        Data Type: 64-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: counter  Units: count
        inst [0 or "localhost:6379"] value 595627069
    [...]
    
    redis.used_memory_peak [Peak memory consumed by Redis (in bytes)]
        Data Type: 32-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: instant  Units: count
        inst [0 or "localhost:6379"] value 572234920
    [...]

    ピークメモリー使用量を表示するには、redis.used_memory_peak メトリックスを参照してください。

関連情報

第6章 pmlogger でのパフォーマンスデータのロギング

PCP ツールを使用してパフォーマンスのメトリック値をログに記録すると、後で再生できます。これにより、遡及的なパフォーマンス解析を実行できます。

pmlogger ツールを使用すると、以下が可能になります。

  • 選択したメトリックのアーカイブログをシステムに作成する
  • システムに記録されるメトリックとその頻度を指定する

6.1. pmlogconf で pmlogger 設定ファイルの変更

pmlogger サービスの実行中、PCP はホストでメトリックのデフォルトセットをログに記録します。

pmlogconf ユーティリティーを使用してデフォルト設定を確認します。pmlogger 設定ファイルが存在しない場合は、pmlogconf がデフォルトのメトリック値で作成します。

前提条件

手順

  1. pmlogger 設定ファイルを作成または変更します。

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. pmlogconf プロンプトに従い、関連するパフォーマンスメトリックのグループを有効または無効にし、有効な各グループのロギング間隔を制御します。

関連情報

6.2. pmlogger の設定ファイルの手動編集

指定したメトリックと間隔でカスタマイズしたロギング設定を作成する場合は、pmlogger 設定ファイルを手動で編集します。デフォルトの pmlogger 設定ファイルは /var/lib/pcp/config/pmlogger/config.default です。設定ファイルでは、プライマリーのロギングインスタンスによって記録されるメトリックを指定します。

手動の設定では、以下が可能になります。

  • 自動設定のリストに記載されていないメトリックを記録する。
  • カスタムロギングの周波数を選択する。
  • アプリケーションのメトリックを使用して PMDA を追加する。

前提条件

手順

  • /var/lib/pcp/config/pmlogger/config.default ファイルを開いて編集し、特定のメトリックを追加します。

    # It is safe to make additions from here on ...
    #
    
    log mandatory on every 5 seconds {
        xfs.write
        xfs.write_bytes
        xfs.read
        xfs.read_bytes
    }
    
    log mandatory on every 10 seconds {
        xfs.allocs
        xfs.block_map
        xfs.transactions
        xfs.log
    
    }
    
    [access]
    disallow * : all;
    allow localhost : enquire;

関連情報

6.3. pmlogger サービスの有効化

ローカルマシンでメトリック値のログを記録するには、pmlogger サービスを開始して有効にする必要があります。

この手順では、pmlogger サービスを有効にする方法を説明します。

前提条件

手順

  • pmlogger サービスを開始して、有効にします。

    # systemctl start pmlogger
    
    # systemctl enable pmlogger

検証手順

  • pmlogger サービスが有効になっているかどうかを確認します。

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents, 1 client
    pmda: root pmcd proc xfs linux mmv kvm jbd2
    pmlogger: primary logger: /var/log/pcp/pmlogger/workstation/20190827.15.54

関連情報

6.4. メトリック収集のためのクライアントシステムの設定

この手順では、中央サーバーが、PCP を実行しているクライアントからメトリックを収集できるように、クライアントシステムを設定する方法を説明します。

前提条件

手順

  1. pcp-system-tools パッケージをインストールします。

    # dnf install pcp-system-tools
  2. pmcd の IP アドレスを設定します。

    # echo "-i 192.168.4.62" >>/etc/pcp/pmcd/pmcd.options

    192.168.4.62 を、クライアントがリッスンする IP アドレスに置き換えます。

    デフォルトでは、pmcd は、ローカルホストをリッスンします。

  3. パブリック zone を永続的に追加するように、ファイアウォールを設定します。

    # firewall-cmd --permanent --zone=public --add-port=44321/tcp
    success
    
    # firewall-cmd --reload
    success
  4. SELinux ブール値を設定します。

    # setsebool -P pcp_bind_all_unreserved_ports on
  5. pmcd サービスおよび pmlogger サービスを有効にします。

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

検証手順

  • 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))

関連情報

6.5. データ収集用の中央サーバーの設定

この手順では、PCP を実行しているクライアントからメトリックを収集する中央サーバーを作成する方法を説明します。

前提条件

手順

  1. pcp-system-tools パッケージをインストールします。

    # dnf install pcp-system-tools
  2. 以下の内容で /etc/pcp/pmlogger/control.d/remote ファイルを作成してください。

    # DO NOT REMOVE OR EDIT THE FOLLOWING LINE
    $version=1.1
    
    192.168.4.13 n n PCP_ARCHIVE_DIR/rhel7u4a -r -T24h10m -c config.rhel7u4a
    192.168.4.14 n n PCP_ARCHIVE_DIR/rhel6u10a -r -T24h10m -c config.rhel6u10a
    192.168.4.62 n n PCP_ARCHIVE_DIR/rhel8u1a -r -T24h10m -c config.rhel8u1a
    192.168.4.69 n n PCP_ARCHIVE_DIR/rhel9u3a -r -T24h10m -c config.rhel9u3a

    192.168.4.13192.168.4.14192.168.4.62、および 192.168.4.69 を、クライアントの IP アドレスに置き換えます。

  3. pmcd サービスおよび pmlogger サービスを有効にします。

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

検証手順

  • 各ディレクトリーから最新のアーカイブファイルにアクセスできることを確認します。

    # for i in /var/log/pcp/pmlogger/rhel*/*.0; do pmdumplog -L $i; done
    Log Label (Log Format Version 2)
    Performance metrics from host rhel6u10a.local
      commencing Mon Nov 25 21:55:04.851 2019
      ending     Mon Nov 25 22:06:04.874 2019
    Archive timezone: JST-9
    PID for pmlogger: 24002
    Log Label (Log Format Version 2)
    Performance metrics from host rhel7u4a
      commencing Tue Nov 26 06:49:24.954 2019
      ending     Tue Nov 26 07:06:24.979 2019
    Archive timezone: CET-1
    PID for pmlogger: 10941
    [..]

    /var/log/pcp/pmlogger/ ディレクトリーのアーカイブファイルは、詳細な分析とグラフ作成に使用できます。

関連情報

6.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/remote

      remote を希望のファイル名に置き換えます。

      注記
      プライマリー pmlogger インスタンスは、接続先の pmcd と同じホストで実行している必要があります。1 つのセントラルホストがリモートホストで実行している pmcd インスタンスに接続された複数の pmlogger インスタンスでデータを収集している場合は、プライマリーインスタンスは必要ありません。また、設定でプライマリーインスタンスが必要ない場合もあります。

ファイルには、ログに記録するホストごとに 1 行が含まれている必要があります。自動的に作成されるプライマリーロガーインスタンスのデフォルトの形式は次のようになります。

# === LOGGER CONTROL SPECIFICATIONS ===
#
#Host   	 P?  S?    directory   		 args

# local primary logger
LOCALHOSTNAME    y   n    PCP_ARCHIVE_DIR/LOCALHOSTNAME    -r -T24h10m -c config.default -v 100Mb

フィールドの詳細は以下のとおりです。

ホスト
ログに記録するホスト名
P?
“Primary?” の略です。 このフィールドは、ホストがプライマリーロガーインスタンスである (y) か、そうでない (n) かを示します。設定内のすべてのファイルにわたってプライマリーロガーは 1 つだけ存在でき、接続先の pmcd と同じホスト上で実行している必要があります。
S?
“Socks?” の略です。 このフィールドは、このロガーインスタンスがファイアウォール経由で pmcd に接続するために SOCKS プロトコルを使用する必要がある (y) か、必要がない (n) かを示します。
directory
この行に関連付けられたすべてのアーカイブがこのディレクトリーに作成されます。
args

pmlogger に渡される引数。

args フィールドのデフォルト値は次のとおりです。

-r
アーカイブのサイズと増加率を報告します。
T24h10m
各日のログ記録を終了するタイミングを指定します。これは通常、pmlogger_daily.service が実行する時間です。デフォルト値の 24h10m は、ログ記録が開始してから遅くとも 24 時間 10 分後に終了することを示します。
-c config.default
使用する設定ファイルを指定します。これは基本的に、記録するメトリクスを定義します。
-v 100Mb
1 つのデータボリュームがいっぱいになり、別のボリュームが作成されるサイズを指定します。新しいアーカイブに切り替わった後、以前に記録されたものは pmlogger_daily または pmlogger_check のいずれかによって圧縮されます。

関連情報

  • pmlogger(1) の man ページ
  • pmlogger_daily(1) の man ページ
  • pmlogger_check(1) の man ページ
  • pmlogger.control(5) の man ページ
  • pmlogrewrite(1) の man ページ

6.7. pmrep で PCP ログアーカイブの再生

メトリックデータの記録後、PCP ログアーカイブを再生できます。ログをテキストファイルにエクスポートして、スプレッドシートにインポートするには、pcp2csvpcp2xmlpmrep または pmlogsummary などの PCP ユーティリティーを使用します。

pmrep ツールを使用すると、以下のことが可能になります。

  • ログファイルを表示する
  • 選択した PCP ログアーカイブを解析し、値を ASCII テーブルにエクスポートする
  • アーカイブログ全体をデプロイメントするか、コマンドラインで個別のメトリックを指定して、ログからメトリック値のみを選択する

前提条件

手順

  • メトリックのデータを表示します。

    $ pmrep --start @3:00am --archive 20211128 --interval 5seconds --samples 10 --output csv disk.dev.write
    Time,"disk.dev.write-sda","disk.dev.write-sdb"
    2021-11-28 03:00:00,,
    2021-11-28 03:00:05,4.000,5.200
    2021-11-28 03:00:10,1.600,7.600
    2021-11-28 03:00:15,0.800,7.100
    2021-11-28 03:00:20,16.600,8.400
    2021-11-28 03:00:25,21.400,7.200
    2021-11-28 03:00:30,21.200,6.800
    2021-11-28 03:00:35,21.000,27.600
    2021-11-28 03:00:40,12.400,33.800
    2021-11-28 03:00:45,9.800,20.600

    上記の例では、5 秒 間隔でアーカイブに収集された disk.dev.write メトリックスのデータをコンマ区切り値の形式で表示します。

    注記

    この例の 20211128 を、データを表示する pmlogger アーカイブを含むファイル名に置き換えます。

関連情報

6.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 ビットファイルオフセット

前提条件

手順

  1. 任意のテキストエディターで /etc/pcp.conf ファイルを開き、PCP アーカイブバージョンを設定します。

    PCP_ARCHIVE_VERSION=3
  2. pmlogger サービスを再起動して、設定の変更を適用します。

    # systemctl restart pmlogger.service
  3. 新しい設定を使用して、新しい 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

関連情報

第7章 Performance Co-Pilot によるパフォーマンスの監視

Performance Co-Pilot (PCP) は、システムレベルのパフォーマンス測定を監視、視覚化、保存、および分析するためのツール、サービス、およびライブラリーのスイートです。

システム管理者は、Red Hat Enterprise Linux 9 の PCP アプリケーションを使用して、システムのパフォーマンスを監視できます。

7.1. pmda-postfix での postfix の監視

この手順では、pmda-postfix を使用して postfix メールサーバーのパフォーマンスメトリックを監視する方法を説明します。これは、1 秒間に受信した電子メールの数を確認するのに役立ちます。

前提条件

手順

  1. 以下のパッケージをインストールします。

    1. pcp-system-tools をインストールします。

      # dnf install pcp-system-tools
    2. pmda-postfix パッケージをインストールして、postfix を監視します。

      # dnf install pcp-pmda-postfix postfix
    3. ロギングデーモンをインストールします。

      # dnf install rsyslog
    4. テスト用にメールクライアントをインストールします。

      # dnf install mutt
  2. postfix サービスおよび rsyslog サービスを有効にします。

    # systemctl enable postfix rsyslog
    # systemctl restart postfix rsyslog
  3. SELinux ブール値を有効にして、pmda-postfix が必要なログファイルにアクセスできるようにします。

    # setsebool -P pcp_read_generic_logs=on
  4. PMDA をインストールします。

    # cd /var/lib/pcp/pmdas/postfix/
    
    # ./Install
    
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Waiting for pmcd to terminate ...
    Starting pmcd ...
    Check postfix metrics have appeared ... 7 metrics and 58 values

検証手順

  • pmda-postfix 操作を確認します。

    echo testmail | mutt root
  • 利用可能なメトリックを確認します。

    # pminfo postfix
    
    postfix.received
    postfix.sent
    postfix.queues.incoming
    postfix.queues.maildrop
    postfix.queues.hold
    postfix.queues.deferred
    postfix.queues.active

関連情報

7.2. PCP Charts アプリケーションで PCP ログアーカイブを視覚的にトレース

メトリックデータの記録後、PCP ログアーカイブをグラフとして再生できます。メトリックは、PCP ログアーカイブのメトリックデータを履歴データのソースとして使用する代替オプションを持つ 1 台または複数のライブホストから提供されます。PCP Charts アプリケーションインターフェイスをカスタマイズしてパフォーマンスメトリックのデータを表示するには、ラインプロット、バーグラフ、または使用状況グラフを使用します。

PCP Charts アプリケーションを使用すると、以下が可能になります。

  • PCP Charts アプリケーションのデータを再生し、グラフを使用して、システムのライブデータとともに遡及データを視覚化する。
  • パフォーマンスメトリック値をグラフに描画する。
  • 複数のチャートを同時に表示する。

前提条件

手順

  1. コマンドラインで PCP Charts アプリケーションを起動します。

    # pmchart

    図7.1 PCP Charts アプリケーション

    pmchart の起動

    pmtime サーバー設定は下部にあります。start ボタンおよび pause ボタンを使用すると、以下を制御できます。

    • PCP がメトリックデータをポーリングする間隔
    • 履歴データのメトリックの日付および時間
  2. File をクリックしてから、New Chart をクリックして、ホスト名またはアドレスを指定して、ローカルマシンおよびリモートマシンの両方からメトリックを選択します。高度な設定オプションには、チャートの軸値を手動で設定する機能、およびプロットの色を手動で選択する機能が含まれます。
  3. PCP Charts アプリケーションで作成したビューを記録します。

    以下は、PCP Charts アプリケーションで作成したイメージを撮影したり、ビューを記録するためのオプションです。

    • File をクリックしてから Export をクリックして、現在のビューのイメージを保存します。
    • Record をクリックしてから Start をクリックし、録画を開始します。Record をクリックしてから Stop をクリックし、録画を停止します。録画の停止後、記録されたメトリックは後で表示できるようにアーカイブが作成されます。
  4. 必要に応じて、PCP Charts アプリケーションでは、ビュー と呼ばれるメインの設定ファイルによって、1 つ以上のチャートに関連付けられたメタデータを保存できます。このメタデータでは、使用されるメトリックや、チャート列など、チャート側面をすべて記述します。File をクリックしてから Save View をクリックして、カスタム view 設定を保存し、後で view 設定を読み込みます。

    以下の PCP Charts アプリケーションビューの設定ファイルの例では、指定の XFS ファイルシステム loop1 に対して読み書きされた合計バイト数を示す積み上げチャートグラフを説明します。

    #kmchart
    version 1
    
    chart title "Filesystem Throughput /loop1" style stacking antialiasing off
        plot legend "Read rate"   metric xfs.read_bytes   instance  "loop1"
        plot legend "Write rate"  metric xfs.write_bytes  instance  "loop1"

関連情報

7.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 ドライバーがインストールされている。

手順

  1. PCP をインストールします。

    # dnf install pcp-zeroconf
  2. pyodbc ドライバーに必要なパッケージをインストールします。

    # dnf install python3-pyodbc
  3. mssql エージェントをインストールします。

    1. PCP の Microsoft SQL Server ドメインエージェントをインストールします。

      # dnf install pcp-pmda-mssql
    2. /etc/pcp/mssql/mssql.conf ファイルを編集して、mssql エージェントの SQL サーバーアカウントのユーザー名およびパスワードを設定します。設定するアカウントに、パフォーマンスデータに対するアクセス権限があることを確認します。

      username: user_name
      password: user_password

      user_name を SQL Server アカウントに置き換え、user_password をこのアカウントの SQL Server ユーザーパスワードに置き換えます。

  4. エージェントをインストールします。

    # cd /var/lib/pcp/pmdas/mssql
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check mssql metrics have appeared ... 168 metrics and 598 values
    [...]

検証手順

  • pcp コマンドを使用して、SQL Server PMDA (mssql) が読み込まれて実行されていることを確認します。

    $ pcp
    Performance Co-Pilot configuration on rhel.local:
    
    platform: Linux rhel.local 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/rhel.local/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/rhel.local/pmie.log
  • PCP が SQL Server から収集できるメトリックの完全なリストを表示します。

    # pminfo mssql
  • メトリックのリストを表示した後は、トランザクションのレートを報告できます。たとえば、5 秒間の時間枠で、1 秒あたりの全体的なトランザクション数を報告するには、以下のコマンドを実行します。

    # pmval -t 1 -T 5 mssql.databases.transactions
  • pmchart コマンドを使用して、システムでこれらのメトリックのグラフィックチャートを表示します。詳細は、Visually tracing PCP log archives with the PCP Charts application を参照してください。

関連情報

7.4. sadc アーカイブから PCP アーカイブの生成

sysstat が提供する sadf ツールを使用して、ネイティブの sadc アーカイブから PCP アーカイブを生成できます。

前提条件

  • sadc アーカイブが作成されました。

    # /usr/lib64/sa/sadc 1 5 -

    この例では、sadc は 5 秒間隔でシステムデータを 1 回サンプリングします。出力ファイルは、標準システムアクティビティーの日次データファイルにデータを書き込む sadc になる - として指定されます。このファイルの名前は saDD で、デフォルトで /var/log/sa ディレクトリーにあります。

手順

  • sadc アーカイブから PCP アーカイブを生成します。

    # sadf -l -O pcparchive=/tmp/recording -2

    この例では、-2 オプションを使用すると 2 日前に記録されたsadc アーカイブから PCP アーカイブを sadf が生成します。

検証手順

PCP コマンドを使用すると、ネイティブ PCP アーカイブの場合と同様に、sadc アーカイブから生成された PCP アーカイブを調べて分析できます。以下に例を示します。

  • sadc アーカイブから生成された PCP アーカイブのメトリックのリストを表示するには、次のコマンドを実行します。

    $ pminfo --archive /tmp/recording
    Disk.dev.avactive
    Disk.dev.read
    Disk.dev.write
    Disk.dev.blkread
    [...]
  • アーカイブのタイムスペースと、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
  • パフォーマンスメトリックの値をグラフにプロットするには、次のコマンドを実行します。

    $ pmchart --archive /tmp/recording

第8章 PCP を使用した XFS のパフォーマンス分析

XFS PMDA は、pcp パッケージの一部として提供され、インストール時にデフォルトで有効になります。これは、Performance Co-Pilot (PCP) で XFS ファイルシステムのパフォーマンスメトリックデータを収集するために使用されます。

PCP を使用して、XFS ファイルシステムのパフォーマンスを分析できます。

8.1. XFS PMDA の手動インストール

XFS PMDA が pcp 設定出力に記載されていない場合は、PMDA エージェントを手動でインストールします。

この手順では、PMDA エージェントを手動でインストールする方法を説明します。

前提条件

手順

  1. xfs ディレクトリーに移動します。

    # cd /var/lib/pcp/pmdas/xfs/
  2. 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

検証手順

  • pmcd プロセスがホストで実行しており、設定リストに XFS PMDA が有効として記載されていることを確認します。

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

8.2. pminfo を使用した XFS パフォーマンスメトリックの検証

PCP は XFS PMDA を有効にして、マウントされた各 XFS ファイルシステムに対して特定の XFS メトリックの報告を可能にします。これにより、特定のマウントされたファイルシステムの問題を特定して、パフォーマンスを評価することが容易になります。

pminfo コマンドは、マウントされた各 XFS ファイルシステムの各デバイスに対する XFS メトリックを提供します。

この手順では、XFS PMDA が提供する利用可能なすべてのメトリックのリストを表示します。

前提条件

手順

  • XFS PMDA が提供する利用可能なメトリックのリストを表示します。

    # pminfo xfs
  • 個別のメトリックの情報を表示します。以下の例は、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]
    • xfs.read_bytes メトリックの長い説明を表示します。

      # pminfo --helptext xfs.read_bytes
      
      xfs.read_bytes
      Help:
      This is the number of bytes read via read(2) system calls to files in
      XFS file systems. It can be used in conjunction with the read_calls
      count to calculate the average size of the read operations to file in
      XFS file systems.
    • xfs.read_bytes メトリックの現在のパフォーマンス値を取得します。

      # pminfo --fetch xfs.read_bytes
      
      xfs.read_bytes
          value 4891346238
    • pminfo で、デバイスごとの XFS メトリックを取得します。

      # pminfo --fetch --oneline xfs.perdev.read xfs.perdev.write
      
      xfs.perdev.read [number of XFS file system read operations]
      inst [0 or "loop1"] value 0
      inst [0 or "loop2"] value 0
      
      xfs.perdev.write [number of XFS file system write operations]
      inst [0 or "loop1"] value 86
      inst [0 or "loop2"] value 0

8.3. pmstore を使用した XFS パフォーマンスメトリックのリセット

PCP を使用すると、特に特定のメトリックが、xfs.control.reset メトリックなどの制御変数として動作する場合は、そのメトリックの値を変更できます。メトリックの値を変更するには、pmstore ツールを使用します。

この手順では、pmstore ツールを使用して XFS メトリックをリセットする方法を説明します。

前提条件

手順

  1. メトリックの値を表示します。

    $ pminfo -f xfs.write
    
    xfs.write
        value 325262
  2. すべての XFS メトリックをリセットします。

    # pmstore xfs.control.reset 1
    
    xfs.control.reset old value=0 new value=1

検証手順

  • メトリックをリセットした後に情報を表示します。

    $ pminfo --fetch xfs.write
    
    xfs.write
        value 0

8.4. XFS の PCP メトリックグループ

以下の表は、XFS で利用可能な PCP メトリックグループについて説明しています。

表8.1 XFS のメトリックグループ

メトリックグループ

提供されたメトリック

xfs.*

読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。

xfs.allocs.*

xfs.alloc_btree.*

ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。

xfs.block_map.*

xfs.bmap_btree.*

メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。

xfs.dir_ops.*

作成、エントリー削除、getdent の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。

xfs.transactions.*

メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。

xfs.inode_ops.*

オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。

xfs.log.*

xfs.log_tail.*

XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。

xfs.xstrat.*

XFS フラッシュデーモンによりフラッシュされたファイルデータのバイト数と、ディスク上の連続および非連続の領域にフラッシュされたバッファーの数のカウンター。

xfs.attr.*

すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。

xfs.quota.*

XFS ファイルシステムでのクォータ操作のメトリック。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。

xfs.buffer.*

XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。

xfs.btree.*

XFS btree の操作に関するメトリック。

xfs.control.reset

XFS 統計のメトリックカウンターをリセットするのに使用される設定メトリック。コントロールメトリックは、pmstore ツールを使用して切り替えられます。

8.5. XFS のデバイスごとの PCP メトリックグループ

以下の表は、XFS で利用可能なデバイスごとの PCP メトリックグループについて説明しています。

表8.2 XFS のデバイスごとの PCP メトリックグループ

メトリックグループ

提供されたメトリック

xfs.perdev.*

読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。

xfs.perdev.block_map.*

xfs.perdev.bmap_btree.*

メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。

xfs.perdev.dir_ops.*

作成、エントリー削除、getdent の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。

xfs.perdev.transactions.*

メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。

xfs.perdev.inode_ops.*

オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。

xfs.perdev.log.*

xfs.perdev.log_tail.*

XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。

xfs.perdev.xstrat.*

XFS フラッシュデーモンによりフラッシュされたファイルデータのバイト数と、ディスク上の連続および非連続の領域にフラッシュされたバッファーの数のカウンター。

xfs.perdev.attr.*

すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。

xfs.perdev.quota.*

XFS ファイルシステムでのクォータ操作のメトリック。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。

xfs.perdev.buffer.*

XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。

xfs.perdev.btree.*

XFS btree の操作に関するメトリック。

第9章 PCP メトリックのグラフィカル表示の設定

pcpgrafanapcp redispcp bpftrace、および pcp vector を組み合わせて使用すると、ライブデータまたは Performance Co-Pilot (PCP) によって収集されたデータをグラフィカルに表示できます。

9.1. PCP の pcp-zeroconf での設定

この手順では、pcp-zeroconf パッケージでシステムに PCP を設定する方法を説明します。pcp-zeroconf パッケージがインストールされると、システムはメトリックのデフォルトセットをアーカイブファイルに記録します。

手順

  • pcp-zeroconf パッケージをインストールします。

    # dnf install pcp-zeroconf

検証手順

  • pmlogger サービスがアクティブであることを確認し、メトリックのアーカイブを開始します。

    # pcp | grep pmlogger
     pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12

関連情報

9.2. grafana-server の設定

Grafana は、ブラウザーからアクセスできるグラフを生成します。grafana-server は、Grafana ダッシュボードのバックエンドサーバーです。これは、デフォルトですべてのインターフェイスでリッスンし、Web ブラウザーからアクセスする Web サービスを提供します。grafana-pcp プラグインは、バックエンドの pmproxy プロトコルと対話します。

この手順では、grafana-server を設定する方法を説明します。

前提条件

手順

  1. 以下のパッケージをインストールします。

    # dnf install grafana grafana-pcp
  2. 以下のサービスを再起動して有効にします。

    # systemctl restart grafana-server
    # systemctl enable grafana-server
  3. Grafana サービスへのネットワークトラフィック用にサーバーのファイアウォールを開きます。

    # firewall-cmd --permanent --add-service=grafana
    success
    
    # firewall-cmd --reload
    success

検証手順

  • grafana-server がリッスンし、要求に応答していることを確認します。

    # ss -ntlp | grep 3000
    LISTEN  0  128  *:3000  *:*  users:(("grafana-server",pid=19522,fd=7))
  • grafana-pcp プラグインがインストールされていることを確認します。

    # grafana-cli plugins ls | grep performancecopilot-pcp-app
    
    performancecopilot-pcp-app @ 3.1.0

関連情報

  • pmproxy(1) および grafana-server の man ページ

9.3. Grafana Web UI へのアクセス

この手順では、Grafana Web インターフェイスにアクセスする方法を説明します。

Grafana Web インターフェイスを使用すると、以下が可能になります。

  • PCP Redis、PCP bpftrace、および PCP Vector データソースを追加します。
  • ダッシュボードの作成
  • 有用なメトリックの概要の表示
  • PCP Redis でのアラートの作成

前提条件

  1. PCP が設定されている。詳細は、PCP の pcp-zeroconf での設定 を参照してください。
  2. grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。

手順

  1. クライアントシステムで http://192.0.2.0:3000 リンクを使用してブラウザーを開き、ポート 3000grafana-server にアクセスします。

    192.0.2.0 をマシン IP に置き換えます。

  2. 最初のログインでは、Email or usernamePassword の両方のフィールドに admin と入力します。

    Grafana は、新しいパスワード を設定してセキュアなアカウントを作成するようにプロンプトを表示します。後で設定する場合は、Skip をクリックします。

  3. メニューで    grafana gear icon    Configuration アイコンにカーソルを合わせてから、Plugins をクリックします。
  4. プラグイン タブで、Search by name or type テキストボックスに performance co-pilot と入力し、Performance Co-Pilot (PCP) プラグインをクリックします。
  5. Plugins / Performance Co-Pilot ペインで、Enable をクリックします。
  6. Grafana grafana home page whirl icon アイコンをクリックします。Grafana Home ページが表示されます。

    図9.1 Home Dashboard

    grafana home dashboard
    注記

    画面上部の隅には同様の grafana top corner settings icon アイコンがありますが、これは一般的な ダッシュボード設定 を制御します。

  7. Grafana Home ページで、Add your first data source をクリックして PCP Redis、PCP bpftrace、および PCP Vector データソースを追加します。データソースの追加に関する詳細は、以下を参照してください。

  8. オプション: メニューで、admin プロファイル    grafana logout option icon    アイコンにカーソルを合わせ、Edit ProfileChange Password を含む Preferences を変更するか、Sign out します。

関連情報

  • grafana-cli および grafana-server の man ページ

9.4. Grafana のセキュアな接続の設定

Grafana と Performance Co-Pilot (PCP) コンポーネントの間にセキュアな接続を確立できます。これらのコンポーネント間にセキュアな接続を確立すると、収集および監視対象のデータへの、権限のない第三者によるアクセスや変更を防ぐことができます。

前提条件

  • PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
  • grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。
  • クライアントの秘密鍵が /etc/grafana/grafana.key ファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。

    秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。

  • TLS クライアント証明書が /etc/grafana/grafana.crt ファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。

手順

  1. root ユーザーとして、/etc/grafana/grana.ini ファイルを開き、[server] セクションの次のオプションを調整して、以下の内容を反映させます。

    protocol = https
    cert_key = /etc/grafana/grafana.key
    cert_file = /etc/grafana/grafana.crt
  2. 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
  3. Grafana サービスを再起動して有効にし、設定の変更を適用します。

    # systemctl restart grafana-server
    # systemctl enable grafana-server

検証

  1. クライアントシステムで、https://192.0.2.0:3000 のリンクを使用してブラウザーを開き、ポート 3000 の grafana-server マシンにアクセスします。192.0.2.0 は、マシンの IP に置き換えます。
  2. アドレスバーの横に鍵アイコン    lock icon    が表示されていることを確認します。

    注記

    プロトコルが http に設定されている場合に HTTPS 接続を試行すると、ERR_SSL_PROTOCOL_ERROR エラーが発生します。プロトコルが https に設定されている場合に HTTP 接続を試行すると、Grafana サーバーは "Client sent an HTTP request to an HTTPS server" というメッセージで応答します。

9.5. PCP Redis の設定

PCP Redis データソースを使用して以下を行います。

  • データアーカイブの表示
  • pmseries 言語を使用したクエリー時系列
  • 複数のホストにまたがるデータの分析

前提条件

  1. PCP が設定されている。詳細は、PCP の pcp-zeroconf での設定 を参照してください。
  2. grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。
  3. メール転送エージェント (sendmail または postfix など) がインストールされ、設定されている。

手順

  1. redis パッケージをインストールします。

    # dnf install redis
  2. 以下のサービスを開始して有効にします。

    # systemctl start pmproxy redis
    # systemctl enable pmproxy redis
  3. grafana-server を再起動します。

    # systemctl restart grafana-server

検証手順

  • pmproxy および redis が動作していることを確認します。

    # pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df

    redis パッケージがインストールされていない場合は、このコマンドはデータを返しません。

関連情報

  • pmseries(1) の man ページ

9.6. PCP Redis のセキュアな接続の設定

パフォーマンスコパイロット (PCP)、Grafana、および PCP redis の間にセキュアな接続を確立できます。これらのコンポーネント間にセキュアな接続を確立すると、収集および監視対象のデータへの、権限のない第三者によるアクセスや変更を防ぐことができます。

前提条件

  • PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
  • grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。
  • 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 ファイルに保存されている。別のパスを使用する場合は、この手順の該当するステップのパスを変更してください。

手順

  1. root ユーザーとして /etc/redis/redis.conf ファイルを開き、次のプロパティーを反映するように TLS/SSL オプションを調整します。

    port 0
    tls-port 6379
    tls-cert-file /etc/redis/redis.crt
    tls-key-file /etc/redis/redis.key
    tls-client-key-file /etc/redis/client.key
    tls-client-cert-file /etc/redis/client.crt
    tls-ca-cert-file /etc/redis/ca.crt
  2. 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
  3. redis サーバーを再起動して、設定の変更を適用します。

    # systemctl restart redis

検証

  • TLS 設定が機能していることを確認します。

    # redis-cli --tls --cert /etc/redis/client.crt \
        --key /etc/redis/client.key \
        --cacert /etc/redis/ca.crt <<< "PING"
    PONG

    TLS 設定が失敗すると、次のエラーメッセージが表示される場合があります。

    Could not negotiate a TLS connection: Invalid CA Certificate File/Directory

9.7. PCP Redis データソースでのパネルおよびアラートの作成

PCP Redis データソースを追加した後に、ダッシュボードに有用なメトリックの概要を表示し、負荷グラフを視覚化するためのクエリーを追加して、システムに問題が発生した場合にその問題を表示する上で役立つアラートを作成できます。

前提条件

  1. PCP Redis が設定されている。詳細は PCP Redis の設定 を参照してください。
  2. grafana-server にアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。

手順

  1. Grafana Web UI にログインします。
  2. Grafana Home ページで、Add your first data source をクリックします。
  3. Add data source ペインで、Filter by name or type のテキストボックスに redis と入力してから PCP Redis をクリックします。
  4. Data Sources / PCP Redis ペインで、以下を実行します。

    1. URL フィールドに http://localhost:44322 を追加し、Save & Test をクリックします。
    2. Dashboards tabImportPCP Redis: Host Overview をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。

      図9.2 PCP Redis: ホストの概要

      PCP redis ホストの概要
  5. 新しいパネルを追加します。

    1. メニューで、    grafana plus sign    Create iconDashboardAdd new panel icon の順にマウスを合わせ、パネルを追加します。
    2. Query タブで、選択した default オプションではなく、クエリーリストから PCP Redis を選択し、A のテキストフィールドで kernel.all.load などのメトリックを入力して、カーネル負荷グラフを可視化します。
    3. 必要に応じて、Panel titleDescription を追加し、Settings から他のオプションを更新します。
    4. Save をクリックして変更を適用し、ダッシュボードを保存します。Dashboard name を追加します。
    5. Apply をクリックして変更を適用し、ダッシュボードに戻ります。

      図9.3 PCP Redis クエリーパネル

      pcp redis クエリーパネル
  6. アラートルールを作成します。

    1. PCP Redis query panel で    redis alert icon    Alert をクリックしてから、Create Alert をクリックします。
    2. RuleNameEvaluate query、および For フィールドを編集して、アラートの Conditions を指定します。
    3. Save をクリックして変更を適用し、ダッシュボードを保存します。Apply をクリックして変更を適用し、ダッシュボードに戻ります。

      図9.4 PCP Redis パネルでのアラートの作成

      pcp redis クエリーアラートパネル
    4. 必要に応じて、同じパネルでスクロールダウンし、Delete アイコンをクリックして、作成したルールを削除します。
    5. オプション: メニューで    alerting bell icon    Alerting アイコンをクリックし、作成されたアラートルールをさまざまなアラートステータスで表示したり、アラートルールを編集したり、Alert Rules タブから既存のルールを一時停止したりします。

      作成したアラートルールの通知チャネルを追加して Grafana からアラート通知を受信するには、アラートの通知チャネルの追加 を参照してください。

9.8. アラートの通知チャネルの追加

通知チャネルを追加すると、アラートルールの条件が満たされ、システムにさらなる監視が必要になると、Grafana からアラート通知を受け取ることができます。

サポートされている通知機能のリストからいずれかのタイプを選択すると、これらのアラートを受け取ることができます。通知機能には、DingDingDiscordEmailGoogle Hangouts ChatHipChatKafka REST ProxyLINEMicrosoft TeamsOpsGeniePagerDutyPrometheus AlertmanagerPushoverSensuSlackTelegramThreema GatewayVictorOps、および webhook が含まれます。

前提条件

  1. grafana-server にアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。
  2. アラートルールが作成されている。詳細は、PCP Redis データソースでのパネルおよびアラートの作成 を参照してください。
  3. SMTP を設定し、grafana/grafana.ini ファイルに有効な送信者のメールアドレスを追加します。

    # vi /etc/grafana/grafana.ini
    
    [smtp]
    enabled = true
    from_address = abc@gmail.com

    abc@gmail.com を有効なメールアドレスに置き換えます。

  4. grafana-server を再起動します。

    # systemctl restart grafana-server.service

手順

  1. メニューから    alerting bell icon    アラートアイコンContact PointsNew contact point の順にクリックします。
  2. New contact point 詳細ビューで、次の操作を実行します。

    1. Name テキストボックスに、名前を入力します。
    2. Contact point type (Email など) を選択し、メールアドレスを入力します。区切り文字 ; を使用すると、多数のメールアドレスを追加できます。
    3. オプション: Optional Email settings および Notification settings を設定します。
  3. Save contact point をクリックします。
  4. アラートルールで通知チャネルを選択します。

    1. メニューから Notification policies アイコンを選択し、+ New specific policy をクリックします。
    2. 先ほど作成した Contact point を選択します。
    3. Save policy ボタンをクリックします。

9.9. PCP コンポーネント間の認証の設定

Simple Authentication Security Layer (SASL) フレームワークを介して PCP によってサポートされる scram-sha-256 認証メカニズムを使用して認証を設定できます。

手順

  1. scram-sha-256 認証メカニズムの sasl フレームワークをインストールします。

    # dnf install cyrus-sasl-scram cyrus-sasl-lib
  2. pmcd.conf ファイルに、サポートされている認証メカニズムとユーザーデータベースのパスを指定します。

    # vi /etc/sasl2/pmcd.conf
    
    mech_list: scram-sha-256
    
    sasldb_path: /etc/pcp/passwd.db
  3. 新しいユーザーを作成します。

    # useradd -r metrics

    metrics をユーザー名に置き換えます。

  4. 作成したユーザーをユーザーデータベースに追加します。

    # saslpasswd2 -a pmcd metrics
    
    Password:
    Again (for verification):

    作成したユーザーを追加するには、メトリック アカウントのパスワードを入力する必要があります。

  5. ユーザーデータベースのパーミッションを設定します。

    # chown root:pcp /etc/pcp/passwd.db
    # chmod 640 /etc/pcp/passwd.db
  6. pmcd サービスを再起動します。

    # systemctl restart pmcd

検証手順

  • sasl 設定を確認します。

    # pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

関連情報

9.10. PCP bpftrace のインストール

PCP bpftrace エージェントをインストールして、システムをイントロスペクトし、カーネルおよびユーザー空間トレースポイントからメトリックを収集します。

bpftrace エージェントは bpftrace スクリプトを使用してメトリックを収集します。bpftrace スクリプトは、強化された Berkeley Packet Filter (eBPF) を使用します。

この手順では、pcp bpftrace をインストールする方法を説明します。

前提条件

  1. PCP が設定されている。詳細は、PCP の pcp-zeroconf での設定 を参照してください。
  2. grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。
  3. scram-sha-256 認証メカニズムが設定されている。詳細は、PCP コンポーネント間の認証の設定 を参照してください。

手順

  1. pcp-pmda-bpftrace パッケージをインストールします。

    # dnf install pcp-pmda-bpftrace
  2. bpftrace.conf ファイルを編集し、{setting-up-authentication-between-pcp-components} で作成したユーザーを追加します。

    # vi /var/lib/pcp/pmdas/bpftrace/bpftrace.conf
    
    [dynamic_scripts]
    enabled = true
    auth_enabled = true
    allowed_users = root,metrics

    metrics をユーザー名に置き換えます。

  3. bpftrace PMDA をインストールします。

    # cd /var/lib/pcp/pmdas/bpftrace/
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bpftrace metrics have appeared ... 7 metrics and 6 values

    pmda-bpftrace がインストールされたため、ユーザーの認証後にのみ使用できるようになりました。詳細は PCP bpftrace システム分析ダッシュボードの表示 を参照してください。

関連情報

  • pmdabpftrace(1) および bpftrace の man ページ

9.11. PCP bpftrace システム分析ダッシュボードの表示

PCP bpftrace データソースを使用すると、pmlogger またはアーカイブからの通常のデータとして利用できないソースからのライブデータにアクセスできます。

PCP bpftrace データソースでは、ダッシュボードに有用なメトリックの概要を表示できます。

前提条件

  1. PCP bpftrace がインストールされている。詳細は、PCP bpftrace のインストール を参照してください。
  2. grafana-server にアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。

手順

  1. Grafana Web UI にログインします。
  2. Grafana Home ページで、Add your first data source をクリックします。
  3. Add data source ペインで、Filter by name or type テキストボックスに bpftrace と入力して、PCP bpftrace をクリックします。
  4. Data Sources / PCP bpftrace ペインで、以下を実行します。

    1. URL フィールドに http://localhost:44322 を追加します。
    2. Basic Auth オプションを切り替えて、作成されたユーザーの認証情報を、User フィールドおよび Password フィールドに追加します。
    3. Save & Test をクリックします。

      図9.5 データソースへの PCP bpftrace の追加

      bpftrace auth
    4. Dashboards tabImportPCP bpftrace: System Analysis をクリックし、有用なメトリックの概要を含むダッシュボードを表示します。

      図9.6 PCP bpftrace: システム分析

      pcp bpftrace システム分析

9.12. PCP Vector のインストール

この手順では、pcp vector をインストールする方法を説明します。

前提条件

  1. PCP が設定されている。詳細は、PCP の pcp-zeroconf での設定 を参照してください。
  2. grafana-server が設定されている。詳細は、grafana-server の設定 を参照してください。

手順

  1. pcp-pmda-bcc パッケージをインストールします。

    # dnf install pcp-pmda-bcc
  2. bcc PMDA をインストールします。

    # cd /var/lib/pcp/pmdas/bcc
    # ./Install
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Initializing, currently in 'notready' state.
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Enabled modules:
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: ['biolatency', 'sysfork',
    [...]
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bcc metrics have appeared ... 1 warnings, 1 metrics and 0 values

関連情報

  • pmdabcc(1) の man ページ

9.13. PCP Vector Checklist の表示

PCP Vector データソースはライブメトリックを表示し、pcp メトリックを使用します。各ホストのデータを分析します。

PCP Vector データソースを追加した後に、ダッシュボードに有用なメトリックの概要を表示し、チェックリストで関連するトラブルシューティングまたは参照リンクを表示できます。

前提条件

  1. PCP Vector がインストールされている。詳細は、PCP Vector のインストール を参照してください。
  2. grafana-server にアクセスできる。詳細は、Grafana Web UI へのアクセス を参照してください。

手順

  1. Grafana Web UI にログインします。
  2. Grafana Home ページで、Add your first data source をクリックします。
  3. Add data source ペインで、Filter by name or type テキストボックスに vector と入力してから PCP Vector をクリックします。
  4. Data Sources / PCP Vector ペインで、以下を実行します。

    1. URL フィールドに http://localhost:44322 を追加し、Save & Test をクリックします。
    2. Dashboards tabImportPCP Vector: Host Overview をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。

      図9.7 PCP Vector: ホストの概要

      pcp vector ホストの概要
  5. メニューで    pcp plugin in grafana    Performance Co-Pilot プラグインにマウスを合わせ、PCP Vector Checklist をクリックします。

    PCP チェックリストで、    pcp vector checklist troubleshooting doc    ヘルプまたは    pcp vector checklist warning    警告アイコをクリックし、関連するトラブルシューティングまたは参照リンクを表示します。

    図9.8 Performance Co-Pilot / PCP Vector Checklist

    pcp vector checklist

9.14. Grafana に関する問題のトラブルシューティング

Grafana にデータが表示されない、ダッシュボードが黒くなる、または同様の問題など、Grafana の問題のトラブルシューティングが必要になる場合があります。

手順

  • 以下のコマンドを実行して、pmlogger サービスが起動していることを確認します。

    $ systemctl status pmlogger
  • 以下のコマンドを実行して、ディスクにファイルが作成または変更されているかどうかを確認します。

    $ ls /var/log/pcp/pmlogger/$(hostname)/ -rlt
    total 4024
    -rw-r--r--. 1 pcp pcp   45996 Oct 13  2019 20191013.20.07.meta.xz
    -rw-r--r--. 1 pcp pcp     412 Oct 13  2019 20191013.20.07.index
    -rw-r--r--. 1 pcp pcp   32188 Oct 13  2019 20191013.20.07.0.xz
    -rw-r--r--. 1 pcp pcp   44756 Oct 13  2019 20191013.20.30-00.meta.xz
    [..]
  • 以下のコマンドを実行して、pmproxy サービスが動作していることを確認します。

    $ systemctl status pmproxy
  • pmproxy が動作していること、時系列サポートが有効になっていること、Redis への接続が確立されていることを、/var/log/pcp/pmproxy/pmproxy.log ファイルを見て、以下のテキストが含まれていることで確認してください。

    pmproxy(1716) Info: Redis slots, command keys, schema version setup

    ここで、1716は pmproxy の PID であり、pmproxy を起動するたびに異なる値になります。

  • 以下のコマンドを実行して、Redis データベースにキーが含まれているかどうかを確認します。

    $ redis-cli dbsize
    (integer) 34837
  • 以下のコマンドを実行して、PCP メトリックが Redis データベースに存在し、pmproxy がアクセスできるかどうかを確認します。

    $ pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    
    $ pmseries "disk.dev.read[count:10]"
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
        [Mon Jul 26 12:21:10.085468000 2021] 117971 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:21:00.087401000 2021] 117758 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:20:50.085738000 2021] 116688 70e83e88d4e1857a3a31605c6d1333755f2dd17c
    [...]
    $ redis-cli --scan --pattern "*$(pmseries 'disk.dev.read')"
    
    pcp:metric.name:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:values:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:desc:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelvalue:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:instances:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelflags:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
  • 以下のコマンドを実行して、Grafana のログにエラーがあるかどうかを確認します。

    $ journalctl -e -u grafana-server
    -- Logs begin at Mon 2021-07-26 11:55:10 IST, end at Mon 2021-07-26 12:30:15 IST. --
    Jul 26 11:55:17 localhost.localdomain systemd[1]: Starting Grafana instance...
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Starting Grafana" logger=server version=7.3.6 c>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/usr/s>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/etc/g>
    [...]

第10章 Web コンソールを使用したシステムパフォーマンスの最適化

以下では、RHEL Web コンソールでパフォーマンスプロファイルを設定し、選択したタスクに対してシステムのパフォーマンスを最適化する方法を説明します。

10.1. Web コンソールでのパフォーマンスチューニングオプション

Red Hat Enterprise Linux 9 には、以下のタスクに対してシステムを最適化する複数のパフォーマンスプロファイルが同梱されています。

  • デスクトップを使用するシステム
  • スループットパフォーマンス
  • レイテンシーパフォーマンス
  • ネットワークパフォーマンス
  • 電力の低消費
  • 仮想マシン

TuneD サービスは、選択したプロファイルに一致するようにシステムオプションを最適化します。

Web コンソールでは、システムが使用するパフォーマンスプロファイルを設定できます。

10.2. Web コンソールでのパフォーマンスプロファイルの設定

実行するタスクに応じて、Web コンソールを使用して適切なパフォーマンスプロファイルを設定することでシステムパフォーマンスを最適化できます。

前提条件

手順

  1. 9 の Web コンソールにログインします。詳細は、Web コンソールへのログイン を参照してください。
  2. Overview をクリックします。
  3. Configuration セクションで、現在のパフォーマンスプロファイルをクリックします。

    Image displaying the Overview pane of the cockpit interface.

  4. Change Performance Profile ダイアログボックスで、必要なプロファイルを設定します。

    Image displaying the Change performance profile dialog box.

  5. Change Profile をクリックします。

検証手順

  • Overview タブの Configuration セクションに、選択したパフォーマンスプロファイルが表示されます。

10.3. Web コンソールを使用したローカルシステムのパフォーマンスの監視

Red Hat Enterprise Linux の Web コンソールは、トラブルシューティングに Utilization Saturation and Errors (USE) メソッドを使用します。新しいパフォーマンスメトリックページには、データの履歴ビューが時系列に整理されており、最新のデータが上部に表示されます。

Metrics and history ページでは、イベント、エラー、リソースの使用率と飽和状態のグラフィカル表示を表示できます。

前提条件

  • RHEL 8 Web コンソールをインストールし、アクセスできる。詳細は、Web コンソールのインストール を参照してください。
  • パフォーマンスメトリクスの収集を可能にする cockpit-pcp パッケージがインストールされている。

    1. Web コンソールインターフェイスからパッケージをインストールするには、以下を行います。

      1. Web コンソールに管理者権限でログインする。詳細は、Web コンソールへのログイン を参照してください。
      2. Overview ページで、View metrics and history をクリックします。
      3. cockpit-pcp のインストール ボタンをクリックします。
      4. ソフトウェアのインストール ダイアログウィンドウで、Install をクリックします。
    2. コマンドラインインターフェイスからパッケージをインストールするには、次を使用します。

      # dnf install cockpit-pcp
  • Performance Co-Pilot (PCP) サービスが有効になっている。

    # systemctl enable --now pmlogger.service pmproxy.service

手順

  1. 9 の Web コンソールにログインします。詳細は、Web コンソールへのログイン を参照してください。
  2. Overview をクリックします。
  3. Usage セクションで、View metrics and history をクリックします。

    Image displaying the Overview pane of the cockpit interface.

    Metrics and history セクションが開きます。

    • 現在のシステム設定と使用状況: Image displaying the current system configuration and usage
    • ユーザー指定の時間間隔におけるグラフィック形式のパフォーマンスメトリクス: Image displaying the performance metrics of the CPU

10.4. Web コンソールと Grafana を使用して複数のシステムのパフォーマンスを監視する

Grafana を使用すると、一度に複数のシステムからデータを収集し、収集した Performance Co-Pilot (PCP) メトリックのグラフィカル表現を確認できます。Web コンソールインターフェイスで、複数のシステムのパフォーマンスメトリックの監視およびエクスポートを設定できます。

前提条件

  • Web コンソールがインストールされており、アクセス可能である。詳細は、Web コンソールのインストールおよび有効化 を参照してください。
  • cockpit-pcp パッケージをインストールします。

    1. Web コンソールインターフェイスから:

      1. Web コンソールに管理者権限でログインする。詳細は、Web コンソールへのログイン を参照してください。
      2. 概要 ページで、詳細と履歴を表示 をクリックします。
      3. cockpit-pcp のインストール ボタンをクリックします。
      4. ソフトウェアのインストール ダイアログウィンドウで、Install をクリックします。
      5. ログアウトしてから再度ログインして、メトリクスの履歴を表示します。
    2. コマンドラインインターフェイスからパッケージをインストールするには、次を使用します。

      # dnf install cockpit-pcp
  • PCP サービスを有効にします。

    # systemctl enable --now pmlogger.service pmproxy.service
  • Grafana ダッシュボードをセットアップします。詳細は、grafana-server の設定 を参照してください。
  • redis パッケージをインストールします。

    # dnf install redis

    または、手順の後半で Web コンソールインターフェイスからパッケージをインストールすることもできます。

手順

  1. Overview ページで、Usage テーブルの View metrics and history をクリックします。
  2. Metrics settings ボタンをクリックします。
  3. Export to network スライダーをアクティブな位置に移動します。

    Metrics settings

    redis パッケージがインストールされていない場合は、Web コンソールでインストールするように求められます。

  4. pmproxy サービスを開くには、ドロップダウンリストからゾーンを選択し、Add pmproxy ボタンをクリックします。
  5. Save をクリックします。

検証

  1. Networking をクリックします。
  2. Firewall テーブルで、Edit rules and zones ボタンをクリックします。
  3. 選択したゾーンで pmproxy を検索します。
重要

監視するすべてのシステムでこの手順を繰り返します。

第11章 ディスクスケジューラーの設定

ディスクスケジューラーは、ストレージデバイスに送信された I/O 要求を順序付けます。

スケジューラーは以下の複数の方法で設定できます。

注記

Red Hat Enterprise Linux 9 では、ブロックデバイスはマルチキュースケジューリングのみに対応します。これにより、ブロックレイヤーのパフォーマンスを高速ソリッドステートドライブ (SSD) およびマルチコアシステムで適切に拡張できます。

Red Hat Enterprise Linux 7 以前のバージョンで利用できた従来のシングルキュースケジューラーが削除されました。

11.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 は、最大スループットを実現するのではなく、レイテンシーを最小限に抑えることに焦点を合わせています。

bfqcfq コードに基づいています。固定タイムスライスについて、ディスクは各プロセスに付与されることはありませんが、セクター数を測定する budget をプロセスに割り当てます。

このスケジューラーは大きなファイルをコピーする際に適しており、この場合、システムが応答しなくなることはありません。

kyber

スケジューラーは、ブロック I/O レイヤーに送信されたすべての I/O 要求のレイテンシーを計算することで、レイテンシーゴールを達成するために自身を調整します。cache-misses の場合、読み込み/同期書き込みリクエストにターゲットレイテンシーを設定できます。

このスケジューラーは、NVMe、SSD などの低レイテンシーデバイスなど、高速なデバイスに適しています。

11.2. 各種ユースケースで異なるディスクスケジューラー

システムが実行するタスクに応じて、分析タスクおよびチューニングタスクの前に、以下のディスクスケジューラーがベースラインとして推奨されます。

表11.1 各種ユースケースのディスクスケジューラー

ユースケースディスクスケジューラー

SCSI インターフェイスを備えた従来の HDD

mq-deadline または bfq を使用します。

高速ストレージで高パフォーマンスの SSD または CPU がバインドされたシステム

特にエンタープライズアプリケーションを実行する場合は none を使用します。または kyber を使用します。

デスクトップまたはインタラクティブなタスク

bfq を使用します。

仮想ゲスト

mq-deadline を使用します。マルチキューに対応しているホストバスアダプター (HBA) ドライバーでは、none を使用します。

11.3. デフォルトのディスクスケジューラー

ブロックデバイスは、別のスケジューラーを指定しない限り、デフォルトのディスクスケジューラーを使用します。

注記

NVMe (Non-volatile Memory Express) ブロックデバイスの場合、デフォルトのスケジューラーは none であり、Red Hat ではこれを変更しないことを推奨します。

カーネルは、デバイスのタイプに基づいてデフォルトのディスクスケジューラーを選択します。自動的に選択されたスケジューラーは、通常、最適な設定です。別のスケジューラーが必要な場合は、Red Hat では、udev ルールまたは TuneD アプリケーションを使用して設定することを推奨しています。選択したデバイスを一致させ、それらのデバイスのスケジューラーのみを切り替えます。

11.4. アクティブなディスクスケジューラーの決定

この手順では、特定のブロックデバイスで現在アクティブなディスクスケジューラーを確認します。

手順

  • /sys/block/device/queue/scheduler ファイルの内容を読み取ります。

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

    アクティブなスケジューラーは、角括弧 ([ ]) にリスト表示されます。

11.5. TuneD を使用したディスクスケジューラーの設定

この手順では、選択したブロックデバイスに特定のディスクスケジューラーを設定するTuneD プロファイルを作成して有効にします。この設定は、システムを再起動しても持続します。

以下のコマンドと設定で、以下の内容を置き換えます。

  • device をブロックデバイスの名前に置き換えます (例: sdf)。
  • selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例: bfq)。

前提条件

手順

  1. 必要に応じて、プロファイルのベースとなる既存のTuneDプロファイルを選択します。利用可能なプロファイルのリストは、RHEL とともに配布される TuneD プロファイル を参照してください。

    現在アクティブなプロファイルを確認するには、次のコマンドを実行します。

    $ tuned-adm active
  2. TuneD プロファイルを保持する新しいディレクトリーを作成します。

    # mkdir /etc/tuned/my-profile
  3. 選択したブロックデバイスのシステム固有の識別子を見つけます。

    $ 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
    注記

    この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。

  4. /etc/tuned/my-profile/tuned.conf 設定ファイルを作成します。このファイルで、以下のオプションを設定します。

    1. 必要に応じて、既存のプロファイルを追加します。

      [main]
      include=existing-profile
    2. WWN 識別子に一致するデバイスに対して選択したディスクスケジューラーを設定します。

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      ここでは、以下のようになります。

      • IDNAME を、使用されている識別子名に置き換えます (例:ID_WWN)。
      • device system unique id を、選択した識別子の値に置き換えます (例:0x5002538d00000000)。

        devices_udev_regex オプションで複数のデバイスに一致させるには、識別子を括弧で囲み、垂直バーで区切ります。

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. プロファイルを有効にします。

    # tuned-adm profile my-profile

検証手順

  1. TuneD プロファイルがアクティブで、適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. /sys/block/device/queue/scheduler ファイルの内容を読み取ります。

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

    アクティブなスケジューラーは、角括弧 ([]) にリスト表示されます。

11.6. udev ルールを使用したディスクスケジューラーの設定

この手順では、udev ルールを使用して、特定ブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動しても持続します。

以下のコマンドと設定で、以下の内容を置き換えます。

  • device をブロックデバイスの名前に置き換えます (例: sdf)。
  • selected-scheduler を、デバイスに設定するディスクスケジューラーに置き換えます (例: bfq)。

手順

  1. ブロックデバイスのシステム固有の識別子を見つけます。

    $ 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
    注記

    この例のコマンドは、指定したブロックデバイスに関連付けられた World Wide Name (WWN) またはシリアル番号として識別されるすべての値を返します。WWN を使用することが推奨されますが、WWN は特定のデバイスで常に利用できる訳ではなく、コマンド例で返される値は、デバイスのシステム固有の ID として使用することが許容されます。

  2. udev ルールを設定します。以下の内容で /etc/udev/rules.d/99-scheduler.rules ファイルを作成します。

    ACTION=="add|change", SUBSYSTEM=="block", ENV{IDNAME}=="device system unique id", ATTR{queue/scheduler}="selected-scheduler"

    ここでは、以下のようになります。

    • IDNAME を、使用されている識別子名に置き換えます (例:ID_WWN)。
    • device system unique id を、選択した識別子の値に置き換えます (例:0x5002538d00000000)。
  3. udev ルールを再読み込みします。

    # udevadm control --reload-rules
  4. スケジューラー設定を適用します。

    # udevadm trigger --type=devices --action=change

検証手順

  • アクティブなスケジューラーを確認します。

    # cat /sys/block/device/queue/scheduler

11.7. 特定ディスクに任意のスケジューラーを一時的に設定

この手順では、特定のブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動すると元に戻ります。

手順

  • 選択したスケジューラーの名前を、/sys/block/device/queue/scheduler ファイルに書き込みます。

    # echo selected-scheduler > /sys/block/device/queue/scheduler

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

検証手順

  • スケジューラーがデバイスでアクティブになっていることを確認します。

    # cat /sys/block/device/queue/scheduler

第12章 Samba サーバーのパフォーマンスチューニング

特定の状況で Samba のパフォーマンスを向上させることができる設定と、パフォーマンスに悪影響を与える可能性がある設定について説明します。

このセクションの一部は、Samba Wiki に公開されているドキュメント Performance Tuning に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

前提条件

  • Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。

12.1. SMB プロトコルバージョンの設定

新しい SMB バージョンごとに機能が追加され、プロトコルのパフォーマンスが向上します。最新の Windows および Windows Server オペレーティングシステムは、常に最新のプロトコルバージョンに対応しています。Samba がプロトコルの最新バージョンも使用している場合は、Samba に接続する Windows クライアントで、このパフォーマンス改善を活用できます。Samba では、server max protocol のデフォルト値が、対応している安定した SMB プロトコルの最新バージョンに設定されます。

注記

常に最新の安定した SMB プロトコルバージョンを有効にするには、server max protocol パラメーターを設定しないでください。このパラメーターを手動で設定する場合は、最新のプロトコルバージョンを有効にするために、それぞれ新しいバージョンの SMB プロトコルで設定を変更する必要があります。

次の手順では、server max protocol パラメーターでデフォルト値を使用する方法を説明します。

手順

  1. /etc/samba/smb.conf ファイルの [global] セクションから、server max protocol パラメーターを削除します。
  2. Samba 設定を再読み込みします。

    # smbcontrol all reload-config

12.2. 大量のファイルを含むディレクトリーとの共有の調整

Linux は、大文字と小文字を区別するファイル名に対応しています。このため、Samba はファイルの検索時またはアクセス時に、大文字と小文字のファイル名のディレクトリーをスキャンする必要があります。小文字または大文字のいずれかでのみ新しいファイルを作成するように共有を設定すると、パフォーマンスが向上します。

前提条件

  • Samba が、ファイルサーバーとして設定されている。

手順

  1. 共有の全ファイルの名前を小文字に変更します。

    注記

    この手順の設定を使用すると、小文字以外の名前が付けられたファイルは表示されなくなります。

  2. 共有のセクションに、以下のパラメーターを設定します。

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    パラメーターの詳細は、man ページの smb.conf(5) を参照してください。

  3. /etc/samba/smb.conf ファイルを検証します。

    # testparm
  4. Samba 設定を再読み込みします。

    # smbcontrol all reload-config

この設定が適用されと、この共有に新たに作成されるすべてのファイルの名前が小文字になります。この設定により、Samba はディレクトリーを大文字と小文字で分けたスキャンが不要になり、パフォーマンスが向上します。

12.3. パフォーマンスが低下する可能性のある設定

デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスが高くなるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf ファイルに socket options パラメーターを設定すると、このカーネル設定が上書きされます。その結果、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。

カーネルの最適化された設定を使用するには、/etc/samba/smb.conf[global] セクションから socket options パラメーターを削除します。

第13章 仮想マシンのパフォーマンスの最適化

仮想マシンでは、ホストと比べて、パフォーマンス低下が常に見られます。以下のセクションでは、この低下の理由を説明します。また、ハードウェアのインフラストラクチャーリソースを可能な限り効率的に使用できるように、RHEL 9 での仮想化によるパフォーマンスへの影響を最小限に抑える方法を説明します。

13.1. 仮想マシンのパフォーマンスに影響を及ぼすもの

仮想マシンは、ホストのユーザー空間プロセスとして実行します。したがって、ハイパーバイザーは、仮想マシンがホストシステムのリソースを使用できるように、ホストのシステムリソースを変換する必要があります。したがって、変換によりリソースの一部が消費されるため、仮想マシンのパフォーマンス効率は、ホストと同じにはなりません。

システムパフォーマンスにおける仮想化の影響

仮想マシンのパフォーマンス低下の理由には、以下のようなものがあります。

  • 仮想 CPU (vCPU) がホスト上のスレッドとして実装され、Linux スケジューラーで処理される。
  • 仮想マシンは、ホストカーネルから NUMA や Huge Page などの最適化機能を自動的に継承しない。
  • ホストのディスクおよびネットワーク I/O の設定が、仮想マシンのパフォーマンスに大きく影響する可能性がある。
  • ネットワークトラフィックは、一般的に、ソフトウェアベースのブリッジから仮想マシンに流れる。
  • ホストデバイスとそのモデルによっては、その特定のハードウェアのエミュレーションにより、オーバーヘッドが著しくなる可能性がある。

仮想化が仮想マシンのパフォーマンスに与える影響の重大度は、次のようなさまざまな要因の影響を受けます。

  • 同時に実行している仮想マシンの数
  • 各仮想マシンで使用される仮想デバイスのサイズ
  • 仮想マシンが使用するデバイスの種類

仮想マシンのパフォーマンス損失を減らす

RHEL 9 は、仮想化のパフォーマンスへの悪影響を減らすのに使用できる多くの機能を提供します。以下に例を示します。

重要

仮想マシンのパフォーマンスのチューニングは、その他の仮想化機能に悪影響を与える可能性があります。たとえば、変更した仮想マシンの移行がより困難になります。

13.2. TuneD を使用した仮想マシンのパフォーマンスの最適化

TuneD ユーティリティーは、CPU 集中型タスクや、ストレージネットワークスループットの応答などの特定のワークロードの特性に対して RHEL を調整するプロファイル配信メカニズムです。これにより、特定のユースケースで、パフォーマンスを強化し、電力消費を減らすように事前設定されたチューニングプロファイルを多数利用できます。これらのプロファイルを編集するか、新規プロファイルを作成して、仮想化環境に適したパフォーマンスソリューション (仮想化環境を含む) を作成できます。

RHEL 9 を仮想化に最適化するには、次のプロファイルを使用します。

  • RHEL 9 仮想マシンの場合は、virtual-guest プロファイルを使用します。これは、一般的に適用された throughput-performance プロファイルをベースにしていますが、仮想メモリーのスワップは減少します。
  • RHEL 9 仮想ホストの場合は、virtual-host プロファイルを使用します。これにより、ダーティーメモリーページのより集中的なライトバックが有効になり、ホストのパフォーマンスを活用できます。

手順

特定の TuneD プロファイルを有効にするには、以下を実行します。

  1. 使用可能な Tuned プロファイルをリスト表示します。

    # tuned-adm list
    
    Available profiles:
    - balanced             - General non-specialized TuneD profile
    - desktop              - Optimize for the desktop use-case
    [...]
    - virtual-guest        - Optimize for running inside a virtual guest
    - virtual-host         - Optimize for running KVM guests
    Current active profile: balanced
  2. (必要に応じて) 新しい TuneD プロファイルを作成するか、既存の TuneD プロファイルを編集します。

    詳細は TneD プロファイルのカスタマイズ を参照してください。

  3. TuneD プロファイルをアクティベートします。

    # tuned-adm profile selected-profile
    • 仮想化ホストを最適化するには、virtual-host プロファイルを使用します。

      # tuned-adm profile virtual-host
    • RHEL ゲストオペレーティングシステムで、virtual-guest プロファイルを使用します。

      # tuned-adm profile virtual-guest

13.3. libvirt デーモンの最適化

libvirt 仮想化スイートは、RHEL ハイパーバイザーの管理層として機能し、libvirt の設定は仮想化ホストに大きな影響を与えます。特に、RHEL 9 には、モノリシックまたはモジュラーの 2 つのタイプの libvirt デーモンが含まれており、使用するデーモンのタイプは、個々の仮想化ドライバーをどの程度細かく設定できるかに影響します。

13.3.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 はデフォルトで設定されています。

次のステップ

13.3.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

    このコマンドで active が表示される場合、libvirtd を使用していることになります。

  • 仮想マシンがシャットダウンしている。

手順

  1. libvirtd とそのソケットを停止します。

    $ systemctl stop libvirtd.service
    $ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket
  2. libvirtd を無効にして、システムの起動時に開始されないようにします。

    $ systemctl disable libvirtd.service
    $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket
  3. モジュラーの 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
  4. モジュラーデーモンのソケットを起動します。

    # for drv in qemu network nodedev nwfilter secret storage; do systemctl start virt${drv}d{,-ro,-admin}.socket; done
  5. オプション: リモートホストからホストに接続する必要がある場合は、仮想化プロキシーデーモンを有効にして起動します。

    1. システムで libvirtd-tls.socket サービスが有効になっているかどうかを確認します。

      # grep listen_tls /etc/libvirt/libvirtd.conf
      
      listen_tls = 0
    2. 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
    3. 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

      virtproxyd の TLS ソケットを有効にするには、libvirt で使用できるように設定された TLS 証明書がホストに必要です。詳細は、アップストリームの libvirt ドキュメント を参照してください。

検証

  1. 有効化された仮想化デーモンをアクティブにします。

    # virsh uri
    qemu:///system
  2. ホストが virtqemud モジュラーデーモンを使用していることを確認します。

    # systemctl is-active virtqemud.service
    active

    ステータスが active の場合、libvirt モジュラーデーモンは正常に有効になっています。

13.4. 仮想マシンのメモリーの設定

仮想マシンのパフォーマンスを改善するために、追加のホスト RAM を仮想マシンに割り当てることができます。同様に、仮想マシンに割り当てるメモリー量を減らして、ホストメモリーを他の仮想マシンやタスクに割り当てることができます。

これらのアクションを実行するには、Web コンソール または コマンドラインインターフェイス を使用します。

13.4.1. Web コンソールを使用した仮想マシンのメモリーの追加および削除

仮想マシンのパフォーマンスを向上させるか、仮想マシンが使用するホストリソースを解放するために、Web コンソールを使用して、仮想マシンに割り当てられたメモリーの量を調整できます。

前提条件

  • ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。

    1. 仮想マシンの設定に memballoon デバイスが含まれていることを確認します。

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      このコマンドで出力が表示され、モデルが none に設定されていない場合は、memballoon デバイスが存在します。

    2. バルーンドライバーがゲスト OS で実行していることを確認します。

      • Windows ゲストでは、ドライバーは virtio-win ドライバーパッケージの一部としてインストールされます。手順は、Installing paravirtualized KVM drivers for Windows virtual machines を参照してください。
      • Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、memballoon デバイスがあれば、アクティベートされます。
  • Web コンソールの VM プラグインが システムにインストールされている

手順

  1. 任意: 最大メモリーと、仮想マシンに現在使用されている最大メモリーの情報を取得します。これは、変更のベースラインとしても、検証のためにも機能します。

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. 仮想マシン インターフェイスで、情報を表示する仮想マシンを選択します。

    新しいページが開き、選択した仮想マシンに関する基本情報を含む Overview セクションと、仮想マシンのグラフィカルインターフェイスにアクセスするための Console セクションが表示されます。

  3. 概要ペインで、Memory 行の横にある 編集 をクリックします。

    メモリー調整 ダイアログが表示されます。

    仮想マシンのメモリー調整ダイアログボックスを表示するイメージ。
  4. 選択した仮想マシンの仮想 CPU を設定します。

    • 最大割り当て: 仮想マシンがそのプロセスに使用できるホストメモリーの最大量を設定します。VM の作成時に最大メモリーを指定することも、後で増やすこともできます。メモリーは、MiB または GiB の倍数で指定できます。

      仮想マシンをシャットダウンしてからでないと、最大メモリー割り当てを調整できません。

    • 現在の割り当て - 仮想マシンに割り当てる実際のメモリー量を設定します。この値は、最大割り当てより小さい値にすることができますが、上限を超えることはできません。値を調整して、仮想マシンで利用可能なメモリーをプロセス用に調整できます。メモリーは、MiB または GiB の倍数で指定できます。

      この値を指定しない場合、デフォルトの割り当ては最大割り当て の値になります。

  5. Save をクリックします。

    仮想マシンのメモリー割り当てが調整されます。

13.4.2. コマンドラインインターフェイスを使用した仮想マシンのメモリーの追加と削除

仮想マシンのパフォーマンスを改善したり、使用しているホストリソースを解放したりするために、CLI を使用して仮想マシンに割り当てられたメモリーの量を調整できます。

前提条件

  • ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。

    1. 仮想マシンの設定に memballoon デバイスが含まれていることを確認します。

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      このコマンドで出力が表示され、モデルが none に設定されていない場合は、memballoon デバイスが存在します。

    2. ballon ドライバーがゲスト OS で実行されていることを確認します。

      • Windows ゲストでは、ドライバーは virtio-win ドライバーパッケージの一部としてインストールされます。手順は、Installing paravirtualized KVM drivers for Windows virtual machines を参照してください。
      • Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、memballoon デバイスがあれば、アクティベートされます。

手順

  1. 任意: 最大メモリーと、仮想マシンに現在使用されている最大メモリーの情報を取得します。これは、変更のベースラインとしても、検証のためにも機能します。

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. 仮想マシンに割り当てる最大メモリーを調整します。この値を増やすと、仮想マシンのパフォーマンスが低下する可能性が向上し、値を減らすことで、仮想マシンがホスト上にあるパフォーマンスフットプリントが低減します。この変更は、停止している仮想マシンでのみ実行できるため、実行中の仮想マシンを調整するには再起動する必要があります。

    たとえば、仮想マシン 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.

    実行中の仮想マシンの最大メモリーを増やすには、仮想マシンにメモリーデバイスを割り当てます。これは、メモリーのホットプラグとも呼ばれます。詳細は、デバイスの仮想マシンへの接続 を参照してください。

    警告

    実行中の仮想マシン (メモリーのホットアンプラグとも呼ばれる) から、メモリーデバイスを削除することはサポートされておらず、Red Hat では推奨していません。

  3. 任意: 仮想マシンが現在使用しているメモリーを最大割り当てまで調整することもできます。これにより、仮想マシンの最大割り当てを変更せずに、仮想マシンが次回の再起動までホスト上にあるメモリー負荷が調整されます。

    # virsh setmem testguest --current 2048

検証

  1. 仮想マシンが使用するメモリーが更新されていることを確認します。

    # virsh dominfo testguest
    Max memory:     4194304 KiB
    Used memory:    2097152 KiB
  2. (必要に応じて) 現在の仮想マシンメモリーを調整すると、仮想マシンのメモリーバルーンの統計を取得して、そのメモリー使用量をどの程度効果的に調整するかを評価できます。

     # virsh domstats --balloon testguest
    Domain: 'testguest'
      balloon.current=365624
      balloon.maximum=4194304
      balloon.swap_in=0
      balloon.swap_out=0
      balloon.major_fault=306
      balloon.minor_fault=156117
      balloon.unused=3834448
      balloon.available=4035008
      balloon.usable=3746340
      balloon.last-update=1587971682
      balloon.disk_caches=75444
      balloon.hugetlb_pgalloc=0
      balloon.hugetlb_pgfail=0
      balloon.rss=1005456

13.4.3. virtio-mem を使用した仮想マシンメモリーの追加および削除

RHEL 9 は、virtio-mem 準仮想化メモリーデバイスを提供します。このデバイスを使用すると、仮想マシン (VM) 内のホストメモリーを動的に追加または削除できます。たとえば、virtio-mem を使用して、実行中の仮想マシン間でメモリーリソースを移動したり、現在の要件に基づいてクラウドセットアップの仮想マシンメモリーのサイズを変更したりできます。

13.4.3.1. virtio-mem の概要

virtio-mem は、仮想マシンでホストメモリーを動的に追加または削除するために使用できる準仮想化メモリーデバイスです。たとえば、このデバイスを使用して、実行中の仮想マシン間でメモリーリソースを移動したり、現在の要件に基づいてクラウドセットアップの仮想マシンメモリーのサイズを変更したりできます。

virtio-mem を使用すると、4 から数百メビバイト (MiB) の単位で、仮想マシンのメモリーを初期サイズより増やしたり、元のサイズに縮小したりできます。ただし、virtio-mem は、特にメモリーを確実にアンプラグするために、特定のゲストオペレーティングシステム設定にも依存していることに注意してください。

virtio-mem 機能の制限

virtio-mem は現在、以下の機能と互換性がありません。

  • ホスト上のリアルタイムアプリケーションのメモリーロックの使用
  • ホストでの暗号化された仮想化の使用
  • virtio-mem とホスト上での memballoon 膨張および収縮の組み合わせ
  • 仮想マシンでの virtio_mem ドライバーのアンロードまたはリロード
  • virtiofs を除く vhost-user デバイスの使用

13.4.3.2. 仮想マシンでのメモリーのオンライン化設定

virtio-mem を使用して実行中の仮想マシンにメモリーを接続する (メモリーのホットプラグとも呼ばれます) 前に、ホットプラグされたメモリーが自動的にオンライン状態に設定されるように仮想マシン (VM) オペレーティングシステムを設定する必要があります。そうしないと、ゲストオペレーティングシステムは追加メモリーを使用できなくなります。メモリーのオンライン化については、次のいずれかの設定から選択できます。

  • online_movable
  • online_kernel
  • auto-movable

これらの設定の違いについては、メモリーのオンライン化設定の比較 を参照してください。

RHEL では、メモリーのオンライン化はデフォルトで udev ルールで設定されます。ただし、virtio-mem を使用する場合は、カーネル内でメモリーのオンライン化を直接設定することを推奨します。

前提条件

  • ホストに Intel 64 または AMD64 CPU アーキテクチャーがある。
  • ホストがオペレーティングシステムとして RHEL 9.4 以降を使用している。
  • ホスト上で実行されている仮想マシンが、次のいずれかのオペレーティングシステムバージョンを使用している。

    • RHEL 8.10

      重要

      RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。

    • RHEL 9

手順

  • 仮想マシンで online_movable 設定を使用するようにメモリーオンライン化を設定するには、以下を実行します。

    1. memhp_default_state カーネルコマンドラインパラメーターを online_movable に設定します。

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_movable
    2. 仮想マシンを再起動します。
  • 仮想マシンで online_kernel 設定を使用するようにメモリーオンライン化を設定するには、以下を実行します。

    1. 以下のように、memhp_default_state カーネルコマンドラインパラメーターを online_kernel に設定します。

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online_kernel
    2. 仮想マシンを再起動します。
  • 仮想マシンで auto-movable メモリーオンライン化ポリシーを使用するには、以下の手順を実行します。

    1. memhp_default_state カーネルコマンドラインパラメーターを online に設定します。

      # grubby --update-kernel=ALL --remove-args=memhp_default_state --args=memhp_default_state=online
    2. memory_hotplug.online_policy カーネルコマンドラインパラメーターを auto-movable に設定します。

      # grubby --update-kernel=ALL --remove-args="memory_hotplug.online_policy" --args=memory_hotplug.online_policy=auto-movable
    3. オプション: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>
      • 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_awarey (yes) に設定されている場合は、アタッチされた virtio-mem デバイスを持つ NUMA ノード内でも 3:1 の比率が適用されます。パラメーターが n (no) に設定されている場合、最大 3:1 の比率はすべての NUMA ノード全体に対してのみ適用されます。

        また、比率を超えていない場合、新しくホットプラグされたメモリーは、移動可能な割り当てに対してのみ利用できます。それ以外の場合では、新しくホットプラグされたメモリーは、移動可能な割り当てと移動不可能な割り当ての両方に使用できます。

    4. 仮想マシンを再起動します。

検証

  • online_movable 設定が正しく設定されているかを確認するには、memhp_default_state カーネルパラメーターの現在の値を確認します。

    # cat /sys/devices/system/memory/auto_online_blocks
    
    online_movable
  • online_kernel 設定が正しく設定されているかを確認するには、memhp_default_state カーネルパラメーターの現在の値を確認します。

    # cat /sys/devices/system/memory/auto_online_blocks
    
    online_kernel
  • auto-movable 設定が正しく設定されているかを確認するには、以下のカーネルパラメーターを確認してください。

    • memhp_default_state:

      # cat /sys/devices/system/memory/auto_online_blocks
      
      online
    • memory_hotplug.online_policy:

      # cat /sys/module/memory_hotplug/parameters/online_policy
      
      auto-movable
    • memory_hotplug.auto_movable_ratio:

      # cat /sys/module/memory_hotplug/parameters/auto_movable_ratio
      
      301
    • memory_hotplug.auto_movable_numa_aware:

      # cat /sys/module/memory_hotplug/parameters/auto_movable_numa_aware
      
      y

13.4.3.3. Attaching a virtio-mem device to virtual machines

実行中の仮想マシンに追加のメモリーをアタッチ (メモリーのホットプラグとも呼ばれます) し、その後ホットプラグされたメモリーのサイズを変更できるようにするには、virtio-mem デバイスを使用できます。具体的には、libvirt XML 設定ファイルと virsh コマンドを使用し、virtio-mem デバイスを定義して仮想マシン (VM) に割り当てることができます。

前提条件

  • ホストに Intel 64 または AMD64 CPU アーキテクチャーがある。
  • ホストがオペレーティングシステムとして RHEL 9.4 以降を使用している。
  • ホスト上で実行されている仮想マシンが、次のいずれかのオペレーティングシステムバージョンを使用している。

    • RHEL 8.10

      重要

      RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。

    • RHEL 9
  • VM にメモリーオンライン化が設定されている。手順は、仮想マシンでのメモリーのオンライン化設定 を参照してください。

手順

  1. ターゲット仮想マシンの XML 設定に maxMemory パラメーターが含まれるようにします。

    # virsh edit testguest1
    
    <domain type='kvm'>
      <name>testguest1</name>
      ...
      <maxMemory unit='GiB'>128</maxMemory>
      ...
    </domain>

    この例では、testguest1 仮想マシンの XML 設定で、128 ギビバイト (GiB) の maxMemory パラメーターが定義されています。maxMemory サイズは、仮想マシンが使用できる最大メモリーを指定します。これには、初期メモリーとホットプラグされたメモリーの両方が含まれます。

  2. XML ファイルを作成して開き、ホスト上の virtio-mem デバイスを定義します。次に例を示します。

    # vim virtio-mem-device.xml
  3. virtio-mem デバイスの XML 定義をファイルに追加し、保存します。

    <memory model='virtio-mem'>
            <target>
                    <size unit='GiB'>48</size>
                    <node>0</node>
                    <block unit='MiB'>2</block>
                    <requested unit='GiB'>16</requested>
                    <current unit='GiB'>16</current>
            </target>
            <alias name='ua-virtiomem0'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </memory>
    <memory model='virtio-mem'>
            <target>
                    <size unit='GiB'>48</size>
                    <node>1</node>
                    <block unit='MiB'>2</block>
                    <requested unit='GiB'>0</requested>
                    <current unit='GiB'>0</current>
            </target>
            <alias name='ua-virtiomem1'/>
            <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memory>

    この例では、2 つの virtio-mem デバイスが以下のパラメーターで定義されます。

    • size: これは、デバイスの最大サイズです。この例では 48 GiB です。sizeblock サイズの倍数である必要があります。
    • node: これは、virtio-mem デバイスに割り当てられた vNUMA ノードです。
    • block: これはデバイスのブロックサイズです。これは、少なくとも Transparent Huge Page (THP) のサイズである必要があります。THP は、Intel 64 または AMD64 CPU アーキテクチャーでは 2 MiB です。通常、Intel 64 または AMD64 アーキテクチャーでは、2 MiB ブロックサイズが適切なデフォルトの選択となります。virtio-memVirtual 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 デバイスと同様に処理します。

  4. XML ファイルを使用して、定義された virtio-mem デバイスを仮想マシンにアタッチします。たとえば、virtio-mem-device.xml で定義された 2 つのデバイスを実行中の仮想マシン testguest1 に永続的にアタッチするには、次のコマンドを実行します。

    # virsh attach-device testguest1 virtio-mem-device.xml --live --config

    --live オプションは、実行中の仮想マシンにのみデバイスを接続します。再起動後に永続性は維持されません。--config オプションは、設定の変更を永続化します。--live オプションを指定せずに、デバイスをシャットダウンした仮想マシンに接続することもできます。

  5. Optional: 実行中の仮想マシンに接続されている virtio-mem デバイスの requested サイズを動的に変更するには、virsh update-memory-device コマンドを使用します。

    # virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 4GiB

    この例では、以下が適用されます。

    • testguest1 は、更新する仮想マシンです。
    • --alias ua-virtiomem0 は、以前に定義されたエイリアスで指定された virtio-mem デバイスです。
    • --requested-size 4GiB は、virtio-mem デバイスの requested サイズを 4 GiB に変更します。

      警告

      requested サイズを減らして実行中の仮想マシンからメモリーをアンプラグすると、信頼性が低下する可能性があります。このプロセスが成功するかどうかは、使用中のメモリーラインニングポリシーなど、さまざまな要因によって決まります。

      場合によっては、その時点でホットプラグされたメモリーの量を変更できないため、ゲストオペレーティングシステムが要求を正常に完了できないことがあります。

      さらに、RHEL 8.10 仮想マシンでは、実行中の仮想マシンからメモリーをアンプラグすることはデフォルトで無効になっています。

  6. オプション: シャットダウンした仮想マシンから virtio-mem デバイスを取り外すには、virsh detach-device コマンドを使用します。

    # virsh detach-device testguest1 virtio-mem-device.xml
  7. オプション: 実行中の仮想マシンから virtio-mem デバイスを取り外すには、以下を実行します。

    1. virtio-mem デバイスの requested サイズを 0 に変更します。そうしないと、実行中の仮想マシンから virtio-mem デバイスを取り外す試行が失敗します。

      # virsh update-memory-device testguest1 --alias ua-virtiomem0 --requested-size 0
    2. 実行中の仮想マシンから virtio-mem デバイスを取り外します。

      # virsh detach-device testguest1 virtio-mem-device.xml

検証

  • 仮想マシンで、利用可能な 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
    # numactl -H
    
    available: 1 nodes (0)
    node 0 cpus: 0 1 2 3 4 5 6 7
    node 0 size: 29564 MB
    node 0 free: 13351 MB
    node distances:
    node   0
      0:  10
  • 実行中の仮想マシンの XML 設定を表示して、プラグイン RAM の現在の容量をホストで表示することもできます。

    # virsh dumpxml testguest1
    
    <domain type='kvm'>
      <name>testguest1</name>
      ...
      <currentMemory unit='GiB'>31</currentMemory>
      ...
      <memory model='virtio-mem'>
          <target>
            <size unit='GiB'>48</size>
            <node>0</node>
            <block unit='MiB'>2</block>
            <requested unit='GiB'>16</requested>
            <current unit='GiB'>16</current>
          </target>
          <alias name='ua-virtiomem0'/>
          <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
      ...
    </domain>

    この例では、以下が適用されます。

    • <currentMemory unit='GiB'>31</currentMemory> は、すべてのソースから VM で利用可能な合計 RAM を表します。
    • <current unit='GiB'>16</current> は、virtio-mem デバイスが提供するプラグイン RAM の現在のサイズを表します。

13.4.3.4. メモリーのオンライン化設定の比較

実行中の RHEL 仮想マシンにメモリーをアタッチする場合 (メモリーのホットプラグとも呼ばれます)、仮想マシン (VM) のオペレーティングシステムでホットプラグされたメモリーをオンライン状態に設定する必要があります。そうしないと、システムはメモリーを使用できなくなります。

次の表は、利用可能なメモリーのオンライン化設定を選択する際の主な考慮事項をまとめたものです。

表13.1 メモリーのオンライン化設定の比較

設定名仮想マシンからのメモリーのアンプラグメモリーゾーンの不均等性が発生するリスク潜在的なユースケース目的のワークロードのメモリー要件

online_movable

ホットプラグされたメモリーを確実に取り外すことができます。

あり

比較的少量のメモリーのホットプラグ

ほとんどがユーザー空間のメモリー

auto-movable

ホットプラグされたメモリーの可動部分は確実に取り外すことができます。

最小

大量のメモリーのホットプラグ

ほとんどがユーザー空間のメモリー

online_kernel

ホットプラグされたメモリーは確実に取り外すことができません。

なし

信頼性の低いメモリーの取り外しは許容されます。

ユーザー空間またはカーネル空間のメモリー

ゾーン不均衡 とは、Linux メモリーゾーンの 1 つに、使用可能なメモリーページがないことです。ゾーン不均衡 になると、システムのパフォーマンスに悪影響を及ぼす可能性があります。たとえば、移動不可能な割り当てが原因で空きメモリーが不足すると、カーネルがクラッシュする可能性があります。通常、移動可能な割り当てには、主にユーザー空間のメモリーページが含まれ、移動不可能な割り当てには、主にカーネル空間のメモリーページが含まれています。

13.4.4. 関連情報

13.5. 仮想マシンの I/O パフォーマンスの最適化

仮想マシンの入出力 (I/O) 機能は、仮想マシンの全体的な効率を大幅に制限する可能性があります。これに対処するために、ブロック I/O パラメーターを設定して、仮想マシンの I/O を最適化できます。

13.5.1. 仮想マシンにおけるブロック I/O のチューニング

複数のブロックデバイスが、複数の仮想マシンで使用されている場合は、I/O ウェイト を変更して特定の仮想デバイスの I/O の優先度を調整することが重要になる場合があります。

デバイスの I/O ウェイトを上げると、I/O 帯域幅の優先度が高まるため、より多くのホストリソースが提供されます。同様に、デバイスのウェイトを下げると、ホストのリソースが少なくなります。

注記

各デバイスの ウェイト の値は 100 から 1000 の範囲内でなければなりません。もしくは、値を 0 にすると、各デバイスのリストからそのデバイスを削除できます。

手順

仮想マシンのブロック I/O パラメーターを表示および設定するには、以下を行います。

  1. 仮想マシンの現在の <blkio> パラメーターを表示します。

    # virsh dumpxml VM-name

    <domain>
      [...]
      <blkiotune>
        <weight>800</weight>
        <device>
          <path>/dev/sda</path>
          <weight>1000</weight>
        </device>
        <device>
          <path>/dev/sdb</path>
          <weight>500</weight>
        </device>
      </blkiotune>
      [...]
    </domain>
  2. 指定したデバイスの I/O ウェイトを編集します。

    # virsh blkiotune VM-name --device-weights device, I/O-weight

    たとえば、以下では、liftrul 仮想マシンの /dev/sda デバイスのウェイトを 500 に変更します。

    # virsh blkiotune liftbrul --device-weights /dev/sda, 500

13.5.2. 仮想マシンのディスク I/O スロットリング

複数の仮想マシンが同時に実行する場合は、過剰なディスク I/O により、システムパフォーマンスに影響が及ぶ可能性があります。KVM 仮想化のディスク I/O スロットリングでは、仮想マシンからホストマシンに送られるディスク I/O 要求に制限を設定する機能を利用できます。これにより、仮想マシンが共有リソースを過剰に使用し、その他の仮想マシンのパフォーマンスに影響を及ぼすことを防ぐことができます。

ディスク I/O スロットリングを有効にするには、仮想マシンに割り当てられた各ブロックデバイスからホストマシンに送られるディスク I/O 要求に制限を設定します。

手順

  1. virsh domblklist コマンドを使用して、指定された仮想マシン上のすべてのディスクデバイスの名前をリスト表示します。

    # virsh domblklist rollin-coal
    Target     Source
    ------------------------------------------------
    vda        /var/lib/libvirt/images/rollin-coal.qcow2
    sda        -
    sdb        /home/horridly-demanding-processes.iso
  2. スロットルする仮想ディスクがマウントされているホストブロックデバイスを見つけます。

    たとえば、前の手順の sdb 仮想ディスクをスロットリングする場合は、以下の出力では、ディスクが /dev/nvme0n1p3 パーティションにマウントされていることを示しています。

    $ lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    zram0                                         252:0    0     4G  0 disk  [SWAP]
    nvme0n1                                       259:0    0 238.5G  0 disk
    ├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
    ├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
    └─nvme0n1p3                                   259:3    0 236.9G  0 part
      └─luks-a1123911-6f37-463c-b4eb-fxzy1ac12fea 253:0    0 236.9G  0 crypt /home
  3. virsh blkiotune コマンドを使用して、ブロックデバイスの I/O 制限を設定します。

    # virsh blkiotune VM-name --parameter device,limit

    以下の例は、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

関連情報

  • ディスク I/O スロットリングは、異なる顧客に属する仮想マシンが同じホストで実行されている場合や、異なる仮想マシンに QoS 保証が提供されている場合など、さまざまな状況で役立ちます。ディスク I/O スロットリングは、低速なディスクをシミュレートするために使用することもできます。
  • I/O スロットリングは、仮想マシンに割り当てられた各ブロックデバイスに個別に適用でき、スループットおよび I/O 操作の制限に対応します。
  • Red Hat は、virsh blkdeviotune コマンドを使用した仮想マシンでの I/O スロットリングの設定はサポートしていません。RHEL 9 を VM ホストとして使用する場合にサポートされていない機能の詳細は、RHEL 9 仮想化でサポートされていない機能 を参照してください。

13.5.3. マルチキュー virtio-scsi の有効化

仮想マシンで virtio-scsi ストレージデバイスを使用する場合は、マルチキュー virtio-scsi 機能により、ストレージパフォーマンスおよびスケーラビリティーが向上します。このため、各仮想 CPU (vCPU) に別のキューを持たせることが可能になります。また仮想 CPU は、その他の vCPU に影響を及ぼすことなく使用するために、割り込みできるようになります。

手順

  • 特定の仮想マシンに対してマルチキュー virtio-scsi サポートを有効にするには、仮想マシンの XML 設定に以下を追加します。ここでの N は、vCPU キューの合計数です。

    <controller type='scsi' index='0' model='virtio-scsi'>
       <driver queues='N' />
    </controller>

13.6. 仮想マシンの CPU パフォーマンスの最適化

vCPU は、ホストマシンの物理 CPU と同様、仮想マシンのパフォーマンスにおいて極めて重要です。したがって、vCPU を最適化すると、仮想マシンのリソース効率に大きな影響を及ぼす可能性があります。vCPU を最適化するには、以下を実行します。

  1. 仮想マシンに割り当てられているホスト CPU の数を調整します。これは、CLI または Web コンソール を使用して実行できます。
  2. vCPU モデルが、ホストの CPU モデルに調整されていることを確認します。たとえば、仮想マシン testguest1 を、ホストの CPU モデルを使用するように設定するには、次のコマンドを実行します。

    # virt-xml testguest1 --edit --cpu host-model
  3. カーネルの同一ページマージ (KSM) を管理します
  4. ホストマシンが Non-Uniform Memory Access (NUMA) を使用する場合は、その仮想マシンに対して NUMA を設定 することもできます。これにより、ホストの CPU およびメモリープロセスが、仮想マシンの CPU およびメモリープロセスにできるだけ近くにマッピングされます。事実上、NUMA チューニングにより、仮想マシンに割り当てられたシステムメモリーへのより効率的なアクセスが可能になります。これにより、vCPU 処理の効果が改善されます。

    詳細は、仮想マシンで NUMA の設定 および サンプルの vCPU パフォーマンスチューニングシナリオ を参照してください。

13.6.1. コマンドラインインターフェイスを使用した仮想 CPU の追加と削除

仮想マシンの CPU パフォーマンスを増減するには、仮想マシンに割り当てられた仮想 CPU (vCPU) を追加または削除します。

実行中の仮想マシンで実行する場合、これは vCPU ホットプラグおよびホットアンプラグとも呼ばれます。ただし、RHEL 9 では vCPU のホットアンプラグに対応しておらず、Red Hat ではその使用を強く推奨していません。

前提条件

  • オプション: ターゲット仮想マシン内の vCPU の現在の状態を表示します。たとえば、仮想マシン testguest 上の仮想 CPU 数を表示するには、以下を実行します。

    # virsh vcpucount testguest
    maximum      config         4
    maximum      live           2
    current      config         2
    current      live           1

    この出力は、testguest が現在 1 vCPU を使用していることを示し、1 つ以上の vCPU をホットプラグして仮想マシンのパフォーマンスを向上できることを示しています。ただし、再起動後に使用される vCPU の testguest 数は 2 に変更され、2 以上の vCPU のホットプラグが可能になります。

手順

  1. 仮想マシンに割り当てることができる vCPU の最大数を調整します。これは、仮想マシンの次回起動時に有効になります。

    たとえば、仮想マシン testguest の vCPU の最大数を 8 に増やすには、次のコマンドを実行します。

    # virsh setvcpus testguest 8 --maximum --config

    最大値は、CPU トポロジー、ホストハードウェア、ハイパーバイザー、およびその他の要素によって制限される可能性があることに注意してください。

  2. 仮想マシンに割り当てられている現在の仮想 CPU の数を調整し、直前のステップで設定された最大数まで調整します。以下に例を示します。

    • 実行中の仮想マシン testguest にアタッチされている vCPU を 4 に増やすには、以下を実行します。

      # virsh setvcpus testguest 4 --live

      これにより、仮想マシンの次回の起動まで、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが高まります。

    • testguest 仮想マシンにアタッチされている vCPU の数を永続的に 1 に減らすには、次のコマンドを実行します。

      # virsh setvcpus testguest 1 --config

      これにより、仮想マシンの次回の起動後に、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが低下します。ただし、必要に応じて、仮想マシンに追加の vCPU をホットプラグして、一時的にパフォーマンスを向上させることができます。

検証

  • 仮想マシンの vCPU の現在の状態に変更が反映されていることを確認します。

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

13.6.2. Web コンソールを使用した仮想 CPU の管理

RHEL 9 Web コンソールを使用して、Web コンソールが接続している仮想マシンが使用する仮想 CPU を確認し、設定できます。

前提条件

手順

  1. 仮想マシン インターフェイスで、情報を表示する仮想マシンを選択します。

    新しいページが開き、選択した仮想マシンに関する基本情報を含む Overview セクションと、仮想マシンのグラフィカルインターフェイスにアクセスするための Console セクションが表示されます。

  2. 概要ペインで、vCPU の数の横にある 編集 をクリックします。

    vCPU の詳細ダイアログが表示されます。

    VM CPU 詳細ダイアログボックスを表示しているイメージ
  1. 選択した仮想マシンの仮想 CPU を設定します。

    • vCPU 数: 現在使用中の vCPU の数

      注記

      vCPU 数は、vCPU 最大値以下にする必要があります。

    • vCPU 最大値 - 仮想マシンに設定できる仮想 CPU の最大数を入力します。この値が vCPU 数 よりも大きい場合には、vCPU を追加で仮想マシンに割り当てることができます。
    • ソケット - 仮想マシンに公開するソケットの数を選択します。
    • ソケットごとのコア - 仮想マシンに公開する各ソケットのコア数を選択します。
    • コアあたりのスレッド - 仮想マシンに公開する各コアのスレッド数を選択します。

      SocketsCores per socket、および Threads per core オプションは、仮想マシンの CPU トポロジーを調整することに注意してください。これは、vCPU のパフォーマンスにメリットがあり、ゲスト OS の特定のソフトウェアの機能に影響を与える可能性があります。デプロイメントで別の設定が必要ない場合は、デフォルト値のままにします。

  2. Apply をクリックします。

    仮想マシンに仮想 CPU が設定されます。

    注記

    仮想 CPU 設定の変更は、仮想マシンの再起動後にのみ有効になります。

13.6.3. 仮想マシンでの NUMA の設定

以下の方法は、RHEL 9 ホストで、仮想マシンの Non-Uniform Memory Access (NUMA) 設定の設定に使用できます。

前提条件

  • ホストが NUMA 対応のマシンである。これを確認するには、virsh nodeinfo コマンドを使用して、NUMA cell(2) の行を確認します。

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              48
    CPU frequency:       1200 MHz
    CPU socket(s):       1
    Core(s) per socket:  12
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         67012964 KiB

    行の値が 2 以上であると、そのホストは NUMA に対応しています。

手順

使いやすさのため、自動化ユーティリティーとサービスを使用して、仮想マシンの NUMA を設定できます。ただし、手動で NUMA を設定すると、パフォーマンスが大幅に向上する可能性が高くなります。

自動方式

  • 仮想マシンの NUMA ポリシーを Preferred に設定します。たとえば、仮想マシン testguest5 に対してこれを行うには、次のコマンドを実行します。

    # virt-xml testguest5 --edit --vcpus placement=auto
    # virt-xml testguest5 --edit --numatune mode=preferred
  • ホストで NUMA の自動負荷分散を有効にします。

    # echo 1 > /proc/sys/kernel/numa_balancing
  • umad サービスを起動して、メモリーリソースで仮想マシンの CPU を自動的に調整します。

    # systemctl start numad

手動方式

  1. 特定ホストの CPU、またはある範囲の CPU に特定の vCPU スレッドをピニングします。これは、NUMA 以外のホストおよび仮想マシンでも可能で、vCPU のパフォーマンスを向上させる安全な方法として推奨されています。

    たとえば、次のコマンドでは、仮想マシン testguest6 の vCPU スレッドの 0 から 5 を、ホストの CPU 1、3、5、7、9、11 にそれぞれピニングします。

    # virsh vcpupin testguest6 0 1
    # virsh vcpupin testguest6 1 3
    # virsh vcpupin testguest6 2 5
    # virsh vcpupin testguest6 3 7
    # virsh vcpupin testguest6 4 9
    # virsh vcpupin testguest6 5 11

    その後、これが成功したかどうかを確認できます。

    # virsh vcpupin testguest6
    VCPU   CPU Affinity
    ----------------------
    0      1
    1      3
    2      5
    3      7
    4      9
    5      11
  2. vCPU スレッドのピニング後に、指定の仮想マシンに関連付けられた QEMU プロセススレッドを、特定ホスト CPU、またはある範囲の CPU に固定することもできます。たとえば、以下のコマンドは、testguest6 の QEMU プロセススレッドを CPU 13 および 15 にピニングし、これが成功したことを確認します。

    # virsh emulatorpin testguest6 13,15
    # virsh emulatorpin testguest6
    emulator: CPU Affinity
    ----------------------------------
           *: 13,15
  3. これで、特定の仮想マシンに対して割り当てられるホストの NUMA ノードを指定することができます。これにより、仮想マシンの vCPU によるホストメモリーの使用率が向上します。たとえば、次のコマンドでは、ホスト NUMA ノード 3 ~ 5 を使用するように testguest6 を設定し、これが成功したかどうかを確認します。

    # virsh numatune testguest6 --nodeset 3-5
    # virsh numatune testguest6
注記

最善のパフォーマンス結果を得るためにも、上記の手動によるチューニングメソッドをすべて使用することが推奨されます。

13.6.4. vCPU のパフォーマンスチューニングシナリオ例

最適な vCPU パフォーマンスを得るためにも、たとえば以下のシナリオのように、手動で vcpupinemulatorpin、および numatune 設定をまとめて使用することが推奨されます。

開始シナリオ

  • ホストには以下のハードウェア仕様があります。

    • 2 つの NUMA ノード
    • 各ノードにある 3 つの CPU コア
    • 各コアにある 2 スレッド

    このようなマシンの virsh nodeinfo の出力は以下のようになります。

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              12
    CPU frequency:       3661 MHz
    CPU socket(s):       2
    Core(s) per socket:  3
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         31248692 KiB
  • 既存の仮想マシンを変更して、8 つの vCPU を使用できるようにします。これは、1 つの NUMA ノードに収まらないことを意味します。

    したがって、各 NUMA ノードに 4 つの vCPU を分散し、vCPU トポロジーをホストトポロジーに可能な限り近づけるようにする必要があります。つまり、指定の物理 CPU のシブリングスレッドとして実行される vCPU は、同じコア上のホストスレッドに固定 (ピニング) される必要があります。詳細は、以下の ソリューション を参照してください。

解決方法

  1. ホストトポロジーに関する情報を取得します。

    # virsh capabilities

    この出力には、以下のようなセクションが含まれます。

    <topology>
      <cells num="2">
        <cell id="0">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="10" />
            <sibling id="1" value="21" />
          </distances>
          <cpus num="6">
            <cpu id="0" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="1" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="2" socket_id="0" core_id="2" siblings="2,5" />
            <cpu id="3" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="4" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="5" socket_id="0" core_id="2" siblings="2,5" />
          </cpus>
        </cell>
        <cell id="1">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="21" />
            <sibling id="1" value="10" />
          </distances>
          <cpus num="6">
            <cpu id="6" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="7" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="8" socket_id="1" core_id="5" siblings="8,11" />
            <cpu id="9" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="10" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="11" socket_id="1" core_id="5" siblings="8,11" />
          </cpus>
        </cell>
      </cells>
    </topology>
  2. (必要に応じて) 適用可能なツールおよびユーティリティー を使用して、仮想マシンのパフォーマンスをテストします。
  3. ホストに 1 GiB の Huge Page を設定してマウントします。

    1. ホストのカーネルコマンドラインに次の行を追加します。

      default_hugepagesz=1G hugepagesz=1G
    2. /etc/systemd/system/hugetlb-gigantic-pages.service ファイルを以下の内容で作成します。

      [Unit]
      Description=HugeTLB Gigantic Pages Reservation
      DefaultDependencies=no
      Before=dev-hugepages.mount
      ConditionPathExists=/sys/devices/system/node
      ConditionKernelCommandLine=hugepagesz=1G
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/etc/systemd/hugetlb-reserve-pages.sh
      
      [Install]
      WantedBy=sysinit.target
    3. /etc/systemd/hugetlb-reserve-pages.sh ファイルを以下の内容で作成します。

      #!/bin/sh
      
      nodes_path=/sys/devices/system/node/
      if [ ! -d $nodes_path ]; then
      	echo "ERROR: $nodes_path does not exist"
      	exit 1
      fi
      
      reserve_pages()
      {
      	echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
      }
      
      reserve_pages 4 node1
      reserve_pages 4 node2

      これにより、4 つの 1GiB の Huge Page が node1 から予約され、さらに別の 4 つの 1 GiB の Huge Page が node2 から予約されます。

    4. 前の手順で作成したスクリプトを実行ファイルにします。

      # chmod +x /etc/systemd/hugetlb-reserve-pages.sh
    5. システムの起動時に Huge Page 予約を有効にします。

      # systemctl enable hugetlb-gigantic-pages
  4. virsh edit コマンドを使用して、最適化する仮想マシンの XML 設定 (この例では super-VM) を編集します。

    # virsh edit super-vm
  5. 次の方法で仮想マシンの XML 設定を調整します。

    1. 仮想マシンが 8 つの静的 vCPU を使用するように設定します。これを行うには、<vcpu/> 要素を使用します。
    2. トポロジーでミラーリングする、対応するホスト CPU スレッドに、各 vCPU スレッドをピニングします。これを行うには、<cputune> セクションの <vcpupin/> 要素を使用します。

      上記の virsh 機能 ユーティリティーで示されているように、ホストの CPU スレッドは、各コアで連続的に順次付けされません。また、vCPU スレッドは、同じ NUMA ノード上のホストのコアの利用可能な最大セットに固定される必要があります。表の図については、以下の トポロジーの例 セクションを参照してください。

      手順 a と b の XML 設定は次のようになります。

      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
    3. 1 GiB の Huge Page を使用するように仮想マシンを設定します。

      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
    4. ホスト上で対応する NUMA ノードからメモリーを使用するように、仮想マシンの NUMA ノードを設定します。これを行うには、<numatune/> セクションの <memnode/> 要素を使用します。

      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
    5. CPU モードが host-passthrough に設定され、CPU が passthrough モードでキャッシュを使用していることを確認します。

      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>

検証

  1. 仮想マシンの XML 設定に、以下のようなセクションが含まれていることを確認します。

    [...]
      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
      <vcpu placement='static'>8</vcpu>
      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
        <numa>
          <cell id="0" cpus="0-3" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="10"/>
              <sibling id="1" value="21"/>
            </distances>
          </cell>
          <cell id="1" cpus="4-7" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="21"/>
              <sibling id="1" value="10"/>
            </distances>
          </cell>
        </numa>
      </cpu>
    </domain>
  2. (必要に応じて) アプリケーションツールおよびユーティリティー を使用して仮想マシンのパフォーマンスをテストし、仮想マシンの最適化への影響を評価します。

トポロジーの例

  • 以下の表は、ピニングされる必要のある vCPU とホスト CPU 間の接続を示しています。

    表13.2 ホストトポロジー

    CPU スレッド

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    コア

    0

    1

    2

    3

    4

    5

    ソケット

    0

    1

    NUMA ノード

    0

    1

    表13.3 仮想マシントポロジー

    vCPU スレッド

    0

    1

    2

    3

    4

    5

    6

    7

    コア

    0

    1

    2

    3

    ソケット

    0

    1

    NUMA ノード

    0

    1

    表13.4 ホストと仮想マシントポロジーの組み合わせ

    vCPU スレッド

     

    0

    1

    2

    3

     

    4

    5

    6

    7

    ホストの CPU スレッド

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    コア

    0

    1

    2

    3

    4

    5

    ソケット

    0

    1

    NUMA ノード

    0

    1

    このシナリオでは、2 つの NUMA ノードと 8 つの vCPU があります。したがって、4 つの vCPU スレッドは各ノードに固定 (ピニング) される必要があります。

    また、Red Hat では、ホストシステムの操作のために、各ノードで少なくとも 1 つの CPU スレッドを使用できるようにしておくことを推奨します。

    以下の例では、NUMA ノードにはそれぞれ 3 コアで、2 個のホスト CPU スレッドがあるため、ノード 0 のセットは、以下のように変換できます。

    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='4'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='5'/>

13.6.5. カーネルの同一ページマージの管理

Kernel Same-Page Merging (KSM) は、仮想マシン (VM) 間で同一のメモリーページを共有することにより、メモリー密度を向上させます。ただし、KSM を有効にすると CPU 使用率が増加し、ワークロードによっては全体的なパフォーマンスに悪影響を与える可能性があります。

要件に応じて、単一のセッションに対して、または永続的に KSM を有効または無効にすることができます。

注記

RHEL 9 以降では、KSM はデフォルトで無効になっています。

前提条件

  • ホストシステムへのルートアクセス。

手順

  • KSM を無効にします。

    • KSM をセッション 1 回分無効にするには、systemctl ユーティリティーを使用して ksm サービスおよび ksmtuned サービスを停止します。

      # systemctl stop ksm
      
      # systemctl stop ksmtuned
    • 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.
注記

KSM を無効にする前に仮想マシン間で共有されていたメモリーページは、そのまま共有されます。共有を停止するには、以下のコマンドを使用して、システムの PageKSM ページをすべて削除します。

# echo 2 > /sys/kernel/mm/ksm/run

KSM ページを匿名ページに置き換えると、khugepaged カーネルサービスは仮想マシンの物理メモリーに透過的なヒュージページを再ビルドします。

  • KSM を有効にします。
警告

KSM を有効にすると、CPU 使用率が増大し、CPU 全体のパフォーマンスに影響を及ぼします。

  1. ksmtuned サービスをインストールします。

    # dnf install ksmtuned

  2. サービスを起動します。

    • 単一セッションで KSM を有効にするには、systemctl ユーティリティーを使用して ksm および ksmtuned サービスを開始します。

      # systemctl start ksm
      # systemctl start ksmtuned
    • 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

13.7. 仮想マシンのネットワークパフォーマンスの最適化

仮想マシンのネットワークインターフェイスカード (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

このコマンドの出力が空白である場合は、vhost_net カーネルモジュールを有効にします。

# modprobe vhost_net
マルチキュー 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>

仮想マシンが実行中の場合は、再起動して変更を適用します。

ネットワークパケットのバッチ処理

転送パスが長い Linux の仮想マシン設定では、パケットをバッチ処理してからカーネルに送信することで、キャッシュが有効に活用される場合があります。パケットバッチ機能を設定するには、ホストで次のコマンドを実行し、tap0 を、仮想マシンが使用するネットワークインターフェイスの名前に置き換えます。

# ethtool -C tap0 rx-frames 64
SR-IOV
ホスト NIC が SR-IOV に対応している場合は、vNIC に SR-IOV デバイス割り当てを使用します。詳しくは、Managing SR-IOV devices を参照してください。

13.8. 仮想マシンのパフォーマンス監視ツール

最も多くの仮想マシンリソースを消費するものと、仮想マシンで最適化を必要とする部分を認識するために、一般的なパフォーマンス診断ツールや仮想マシン固有のパフォーマンス診断ツールを使用できます。

デフォルトの OS パフォーマンス監視ツール

標準のパフォーマンス評価には、ホストおよびゲストのオペレーティングシステムでデフォルトで提供されるユーティリティーを使用できます。

  • RHEL 9 ホストで、root として top ユーティリティーまたは システムモニター アプリケーションを使用し、出力結果から qemuvirt を見つけます。これは、仮想マシンが消費しているホストシステムのリソースのサイズを示します。

    • 監視ツールにおいて、qemu プロセスまたは virt プロセスのいずれかで、ホストの CPU またはメモリーの容量を大幅に消費していることが示されている場合は、perf ユーティリティーを使用して調査を行います。詳細は以下を参照してください。
    • また、vhost_net スレッドプロセス (例: vhost_net-1234) が、ホストの CPU 容量を過剰に消費する際に表示される場合は、multi-queue virtio-net などの 仮想ネットワークの最適化機能 を使用することを検討してください。
  • ゲストオペレーティングシステムでは、システムで利用可能なパフォーマンスユーティリティーとアプリケーションを使用して、どのプロセスが最も多くのシステムリソースを消費するかを評価します。

    • Linux システムでは、top ユーティリティーを使用できます。
    • Windows システムでは、Task Manager アプリケーションを使用できます。

perf kvm

perf ユーティリティーを使用して、RHEL 9 ホストのパフォーマンスに関する仮想化固有の統計を収集および分析できます。これを行うには、以下を行います。

  1. ホストに、perf パッケージをインストールします。

    # dnf install perf
  2. perf kvm stat コマンドの 1 つを使用して、仮想化ホストの perf 統計を表示します。

    • お使いのハイパーバイザーのリアルタイム監視には、perf kvm stat live コマンドを使用します。
    • 一定期間でハイパーバイザーの perf データをログに記録するには、perf kvm stat record コマンドを使用してロギングを有効にします。コマンドをキャンセルまたは中断した後、データは perf.data.guest ファイルに保存されます。これは、perf kvm stat report コマンドを使用して分析できます。
  3. VM-EXIT イベントとそのディストリビューションのタイプについて perf 出力を分析します。たとえば、PAUSE_INSTRUCTION イベントは頻繁に存在すべきではありませんが、以下の出力では、このイベントが頻繁に現れ、ホスト CPU が vCPU を適切に処理していないことを示しています。このようなシナリオでは、アクティブな一部の仮想マシンの電源オフ、その仮想マシンからの vCPU の削除、または vCPU のパフォーマンスの調整 を検討してください。

    # perf kvm stat report
    
    Analyze events for all VMs, all VCPUs:
    
    
                 VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time         Avg time
    
      EXTERNAL_INTERRUPT     365634    31.59%    18.04%      0.42us  58780.59us    204.08us ( +-   0.99% )
               MSR_WRITE     293428    25.35%     0.13%      0.59us  17873.02us      1.80us ( +-   4.63% )
        PREEMPTION_TIMER     276162    23.86%     0.23%      0.51us  21396.03us      3.38us ( +-   5.19% )
       PAUSE_INSTRUCTION     189375    16.36%    11.75%      0.72us  29655.25us    256.77us ( +-   0.70% )
                     HLT      20440     1.77%    69.83%      0.62us  79319.41us  14134.56us ( +-   0.79% )
                  VMCALL      12426     1.07%     0.03%      1.02us   5416.25us      8.77us ( +-   7.36% )
           EXCEPTION_NMI         27     0.00%     0.00%      0.69us      1.34us      0.98us ( +-   3.50% )
           EPT_MISCONFIG          5     0.00%     0.00%      5.15us     10.85us      7.88us ( +-  11.67% )
    
    Total Samples:1157497, Total events handled time:413728274.66us.

    perf kvm stat の出力で問題を知らせる他のイベントタイプには、以下が含まれます。

perf を使用した仮想化パフォーマンスを監視する方法は、perf-kvm man ページを参照してください。

numastat

システムの現在の NUMA 設定を表示するには、numastat ユーティリティーを使用できます。これは numactl パッケージをインストールすることで利用できます。

以下は、4 つの実行中の仮想マシンが含まれるホストを示しています。それぞれは、複数の NUMA ノードからメモリーを取得しています。これは、vCPU のパフォーマンスに対して最適なのではなく、保証調整 です。

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm)     68     16    357   6936      2      3    147    598  8128
51747 (qemu-kvm)    245     11      5     18   5172   2532      1     92  8076
53736 (qemu-kvm)     62    432   1661    506   4851    136     22    445  8116
53773 (qemu-kvm)   1393      3      1      2     12      0      0   6702  8114
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total              1769    463   2024   7462  10037   2672    169   7837 32434

一方、以下では、1 つのノードで各仮想マシンに提供されているメモリーを示しています。これは、より一層効率的です。

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm)      0      0      7      0   8072      0      1      0  8080
53736 (qemu-kvm)      0      0      7      0      0      0   8113      0  8120
53773 (qemu-kvm)      0      0      7      0      0      0      1   8110  8118
59065 (qemu-kvm)      0      0   8050      0      0      0      0      0  8051
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total                 0      0   8072      0   8072      0   8114   8110 32368

第14章 電源管理の重要性

コンピューターシステム全体の消費電力を削減することで、コストを削減できます。各システムコンポーネントのエネルギー消費を効果的に最適化するには、システムが実行するさまざまなタスクを検討し、各コンポーネントのパフォーマンスがそのジョブに対して正しいことを確認するように設定します。特定コンポーネントやシステム全体の消費電力を下げると、熱およびパフォーマンスが低下します。

適切な電源管理を行うと、以下のような結果になります

  • サーバーやコンピューティングセンターにおける熱の削減
  • 冷却、空間、ケーブル、ジェネレーター、無停電電源装置 (UPS) などの二次コストの削減
  • ノートパソコンのバッテリー寿命の延長
  • 二酸化炭素排出量の削減
  • 政府の規制や Green IT (Energy Star など) に関する法的要件に合致する
  • 新システムに関する企業ガイドラインの遵守

本セクションでは、Red Hat Enterprise Linux システムの電源管理に関する情報を説明します。

14.1. 電源管理の基本

効果的な電源管理は、以下の原則に基づいて行われます。

An idle CPU should only wake up when needed

Red 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 に同梱される仮想化技術を使用して仮想化することもできます。

14.2. 監査および分析の概要

通常、1 つのシステムで詳細な手動の監査、分析、およびチューニングを行う場合は例外となります。これは、このようなシステム調整の最後の部分から得られる利点よりも、その実行にかかる時間とコストの方が長いためです。

ただし、すべてのシステムで同じ設定を再利用できるほぼ同一のシステムでこれらのタスクを 1 回実行することは、非常に便利です。たとえば、数千ものデスクトップシステムや、マシンがほぼ同一の HPC クラスターをデプロイメントする場合を考えてください。監査と分析を行うもう 1 つの理由は、将来のシステム動作のリグレッションまたは変更を特定できる比較の基礎を提供することです。この分析の結果は、ハードウェア、BIOS、またはソフトウェアの更新が定期的に行われ、消費電力に関する予期しない事態を回避したい場合に非常に役立ちます。通常、徹底的な監査と分析により、特定システムで実際に起こっていることをより的確に把握できます。

利用可能な最新のシステムを使用しても、消費電力に関するシステムの監査と分析は比較的困難です。ほとんどのシステムは、ソフトウェアを介して電力使用量を測定するために必要な手段を提供していません。ただし、例外があります。

  • Hewlett Packard サーバーシステムの iLO 管理コンソールには、Web からアクセスできる電源管理モジュールがあります。
  • IBM は、BladeCenter 電源管理モジュールで同様のソリューションを提供します。
  • 一部の Dell システムでは、IT Assistant は電力監視機能も提供します。

他のベンダーは、サーバープラットフォームで同様の機能を提供する可能性が高くなりますが、すべてのベンダーで対応している唯一のソリューションは存在しません。多くの場合、消費電力を直接測定する必要があるのは、可能な限り節約を最大化するためだけです。

14.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 をインストールします。

ディスクとネットワークのアクティビティーの詳細情報を表示するには、次のコマンドを実行します。

# diskdevstat

PID   UID   DEV   WRITE_CNT   WRITE_MIN   WRITE_MAX   WRITE_AVG   READ_CNT   READ_MIN   READ_MAX   READ_AVG   COMMAND

3575  1000  dm-2   59          0.000      0.365        0.006        5         0.000        0.000      0.000      mozStorage #5
3575  1000  dm-2    7          0.000      0.000        0.000        0         0.000        0.000      0.000      localStorage DB
[...]


# netdevstat

PID   UID   DEV       XMIT_CNT   XMIT_MIN   XMIT_MAX   XMIT_AVG   RECV_CNT   RECV_MIN   RECV_MAX   RECV_AVG   COMMAND
3572  991  enp0s31f6    40       0.000      0.882       0.108        0         0.000       0.000       0.000     openvpn
3575  1000 enp0s31f6    27       0.000      1.363       0.160        0         0.000       0.000       0.000     Socket Thread
[...]

このコマンドでは、update_intervaltotal_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 -a コマンドを使用すると、アクティブメモリーと非アクティブメモリーを表示できます。その他の vmstat オプションの詳細は、vmstat の man ページを参照してください。

iostat

このツールは sysstat パッケージで提供されます。このツールは vmstat と似ていますが、ブロックデバイスの I/O を監視する目的でのみ使用されます。また、より詳細な出力と統計も提供します。

システム I/O を監視するには、次のコマンドを実行します。

$ iostat
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.05    0.46    1.55    0.26    0.00   95.67

Device     tps     kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
nvme0n1    53.54     899.48     616.99      3445229     2363196
dm-0       42.84     753.72     238.71      2886921      914296
dm-1        0.03       0.60       0.00         2292           0
dm-2       24.15     143.12     379.80       548193     1454712
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]
[...]

ここでは、最初の列の 253,0 は、デバイスのメジャータプルおよびマイナータプルになります。2 番目の列 (1) には、CPU に関する情報が記載されています。次に、IO プロセスを実行するプロセスのタイムスタンプと PID の列が記載されています。

6 番目の列 Q はイベントタイプを示し、7 番目の列 W は書き込み操作を示し、8 番目の列 76423384 はブロック番号であり、+ 8は要求されたブロックの数になります。

最後のフィールドの [kworker/u16:1] はプロセスの名前です。

初期設定では、プロセスが明示的に強制終了されるまで、blktrace は永続的に実行されます。-w オプションを使用して、ランタイム期間を指定します。

turbostat

これは、kernel-tools により提供されます。x86-64 プロセッサーで、プロセッサーのトポロジー、周波数、アイドル電力状態の統計、温度、および電力使用量を報告します。

この概要を表示するには、次のコマンドを実行します。

# turbostat

CPUID(0): GenuineIntel 0x16 CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:8e:a (6:142:10)
CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
[...]

デフォルトでは、tervostat は、画面全体のカウンター結果の概要を出力し、その後に 5 秒間隔でカウンター結果を出力します。-i オプションでカウンター結果の間隔を指定します。たとえば、turbostat -i 10 を実行して、10 秒間隔で結果を出力します。

Turbostat は、電力使用率またはアイドル時間に関して非効率的なサーバーを識別するのにも役立ちます。また、発生しているシステム管理割り込み (SMI) の比率を特定する場合にも便利です。また、これを使用して、電源管理の調整の効果を検証することもできます。

cpupower

IT は、プロセッサーの省電力関連機能を検証および調整するツール群です。frequency-infofrequency-setidle-infoidle-setsetinfo、および monitor オプションを指定して cpupower コマンドを使用し、プロセッサー関連の値を表示および設定します。

たとえば、利用可能な cpufreq ガバナーを表示するには、次のコマンドを実行します。

$ cpupower frequency-info --governors
analyzing CPU 0:
  available cpufreq governors: performance powersave

cpupower の詳細は、Viewing CPU related information を参照してください。

GNOME Power Manager
これは、GNOME デスクトップ環境にインストールされるデーモンです。GNOME Power Manager は、システムの電源ステータスの変更 (バッテリーから AC 電源への変更など) を通知します。また、バッテリーのステータスを報告し、バッテリー残量が少なくなると警告を表示します。

関連情報

  • man ページの powertop(1)diskdevstat(8)netdevstat(8)tuned(8)vmstat(8)iostat(1)blktrace(8)blkparse(8)、および turbostat(8)
  • man ページの cpupower(1)cpupower-set(1)cpupower-info(1)cpupower-idle(1)cpupower-frequency-set(1)cpupower-frequency-info(1)、および cpupower-monitor(1)

第15章 PowerTOP を使用した電力消費の管理

システム管理者であれば、PowerTOP ツールを使用して、消費電力を解析および管理できます。

15.1. PowerTOP の目的

PowerTOP は、消費電力に関連する問題を診断し、バッテリーの寿命を延ばす方法について提案を示すプログラムです。

PowerTOP ツールは、システムの総電力使用量の想定と、各プロセス、デバイス、カーネルワーカー、タイマー、および割り込みハンドラーの個々の電力使用量の想定を示すことができます。このツールは、CPU を頻繁にウェイクアップするカーネルおよびユーザー空間アプリケーションの特定のコンポーネントを識別することもできます。

Red Hat Enterprise Linux 9 は、PowerTOP のバージョン 2.x を使用します。

15.2. PowerTOP の使用

前提条件

  • PowerTOP を使用できるようにするには、powertop パッケージがシステムにインストールされていることを確認してください。

    # dnf install powertop

15.2.1. PowerTOP の起動

手順

  • PowerTOP を実行するには、次のコマンドを使用します。

    # powertop
重要

powertop コマンドの実行時には、ラップトップはバッテリー電源で動作します。

15.2.2. PowerTOP の調整

手順

  1. ラップトップでは、次のコマンドを実行して電力予測エンジンを調整することができます。

    # powertop --calibrate
  2. プロセス中にマシンと対話せずに、調整を終了させます。

    プロセスがさまざまなテストを実行し、輝度を切り替え、デバイスのオンとオフを切り替える操作を繰り返すため、調整には時間がかかります。

  3. 調整プロセスが完了すると、PowerTOP が通常どおり起動します。データを収集するために約 1 時間実行します。

    十分なデータが収集されると、出力テーブルの最初の列に電力予測マークが表示されます。

注記

powertop --calibrate は、ノートパソコンでのみ使用できることに注意してください。

15.2.3. 測定間隔の設定

デフォルトでは、PowerTOP は、20 秒間隔で測定します。

この測定頻度を変更する場合は、以下の手順に従います。

手順

  • --time オプションを指定して powertop コマンドを実行します。

    # powertop --time=time in seconds

15.3. PowerTOP の統計

PowerTOP は、実行中に、システムから統計を収集します。

PowerTOP の出力には、複数のタブがあります。

  • Overview
  • idle stats
  • Frequency stats
  • Device stats
  • Tunables
  • WakeUp

Tab キーおよび Shift+ Tab キーを使用して、このタブを順番に切り替えることができます。

15.3.1. Overview タブ

Overview タブでは、ウェイクアップを最も頻繁に CPU に送信するか、最も電力を消費するコンポーネントのリストを表示できます。プロセス、割り込み、デバイス、その他のリソースなど、Overview タブの項目は、使用率に従って並べ替えられます。

Overview タブで隣接する列は、以下の情報を提供します。

Usage
リソース使用の電力想定。
Events/s
1 秒あたりウェイクアップ。1 秒あたりのウェイクアップ数は、サービスまたはデバイス、ならびにカーネルのドライバーがいかに効率的に実行しているかを示します。ウェイクアップが少ないほど、消費電力が少なくなります。コンポーネントは、電力使用率をどの程度まで最適化できるかによって順序付けられます。
Category
プロセス、デバイス、タイマーなどのコンポーネントの分類。
説明
コンポーネントの説明。

適切に調整すると、最初の列にリストされているすべての項目に対する電力消費予測も表示されます。

これとは別に、Overview タブには、次のようなサマリー統計の行が含まれます。

  • 合計電力消費
  • バッテリーの残り寿命 (該当する場合)
  • 1 秒あたりの合計ウェイクアップ数、1 秒あたり GPU 操作数、および 1 秒あたりの仮想ファイルシステム操作数の概要

15.3.2. Idle stats タブ

Idle stats タブには、すべてのプロセッサーおよびコアに対する C 状態の使用率が表示されます。Frequency stats タブには、(該当する場合は) すべてのプロセッサーおよびコアに対する Turbo モードを含む P 状態の使用率が表示されます。C または P 状態の長さは、CPU 使用率がどの程度最適化されているかを示します。CPU の C 状態または P 状態が高いままになるほど (C4 が C3 よりも高くなるなど)、CPU 使用率がより最適化されます。システムがアイドル状態の時に、最高の C 状態または P 状態の常駐が 90% 以上になることが理想的と言えます。

15.3.3. Device stats タブ

Device stats タブは Overview タブと同様の情報を提供しますが、デバイス専用です。

15.3.4. Tunables タブ

Tunables タブには、低消費電力にシステムを最適化するための、PowerTOP の推奨事項が含まれます。

up キーおよび down キーを使用して提案を移動し、enter キーを使用して提案をオンまたはオフにします。

15.3.5. WakeUp タブ

WakeUp タブには、ユーザーが必要に応じて変更できるデバイスウェイクアップ設定が表示されます。

up キーおよび down キーを使用して利用可能な設定を移動し、enter キーを使用して設定を有効または無効にします。

図15.1 PowerTOP 出力

powertop2 14

関連情報

PowerTOP の詳細は、PowerTOP のホームページ を参照してください。

15.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
  • intel_pstate は、Intel P-State ドライバーが読み込まれ、アクティブモードになっている場合に返されます。
  • intel_cpufreq は、インテル P-State ドライバーが読み込まれ、パッシブモードになっている場合に返されます。
  • ACPI CPUfreq ドライバーが読み込まれている場合は、acpi-cpufreq が返されます。

Intel P-State ドライバーを使用している場合は、カーネルブートコマンドラインに以下の引数を追加して、ドライバーをパッシブモードで実行するようにします。

intel_pstate=passive

Intel P-State ドライバーを無効にして、代わりに ACPI CPUfreq ドライバーを使用するには、カーネルブートコマンドラインに次の引数を追加します。

intel_pstate=disable

15.5. HTML 出力の生成

端末の powertop の出力結果以外にも、HTML レポートを生成することもできます。

手順

  • --html オプションを指定して powertop コマンドを実行します。

    # powertop --html=htmlfile.html

    htmlfile.html パラメーターを、出力ファイルに必要な名前に置き換えます。

15.6. 電力消費の最適化

電力消費を最適化するには、powertop サービスまたは powertop2tuned ユーティリティーを使用できます。

15.6.1. powertop サービスで消費電力の最適化

powertop サービスを使用すると、システムの起動の Tunables タブから、すべての PowerTOP の提案を自動的に有効にできます。

手順

  • powertop サービスを有効にします。

    # systemctl enable powertop

15.6.2. powertop2tuned ユーティリティー

powertop2tuned ユーティリティーを使用すると、PowerTOPの提案からカスタムTuneDプロファイルを作成できます。

デフォルトでは、powertop2tuned は、/etc/tuned/ ディレクトリーにプロファイルを作成し、現在選択している TuneD プロファイルを基にしてカスタムプロファイルを作成します。安全上の理由から、すべての PowerTOP チューニングは最初に新しいプロファイルで無効になっています。

チューニングを有効にするには、以下を行います。

  • /etc/tuned/profile_name/tuned.conf ファイルでコメントを解除します。
  • --enable オプションまたは -e オプションを使用して、PowerTOP により提案されたチューニングのほとんどを可能にする新しいプロファイルを生成します。

    USB 自動サスペンドなど、既知の問題のある特定のチューニングはデフォルトで無効になっているため、手動でコメントを解除する必要があります。

15.6.3. powertop2tuned ユーティリティーで電力消費の最適化

前提条件

  • powertop2tuned ユーティリティーがシステムにインストールされている場合は、次のコマンドを実行します。

    # dnf install tuned-utils

手順

  1. カスタムプロファイルを作成するには、次のコマンドを使用します。

    # powertop2tuned new_profile_name
  2. 新しいプロファイルをアクティベートします。

    # tuned-adm profile new_profile_name

関連情報

  • powertop2tuned に対応しているオプションの完全リストを表示するには、以下を使用します。

    $ powertop2tuned --help

15.6.4. powertop.service と powertop2tuned の比較

以下の理由により、powertop2tuned を使用した電力消費の最適化は、powertop.service よりも推奨されます。

  • powertop2tuned ユーティリティーは、PowerTOPTuneD に統合したものです。これにより、両方のツールの利点を活かすことができます。
  • powertop2tuned ユーティリティーを使用すると、有効になっているチューニングをきめ細かく制御できます。
  • powertop2tuned を使用すると、潜在的に危険なチューニングは自動的に有効になりません。
  • powertop2tuned を使用すると、再起動せずにロールバックを行うことができます。

第16章 perf の使用

システム管理者は、perf ツールを使用して、システムのパフォーマンスデータを収集および分析できます。

16.1. perf の概要

perf ユーザー空間ツールは、カーネルベースのサブシステム Performance Counters for Linux (PCL) とインターフェイスします。perf は、PMU (Performance Monitoring Unit) を使用してさまざまなハードウェアおよびソフトウェアイベントを測定、記録、監視する強力なツールです。perf は tracepoint、kprobes、および uprobes にも対応しています。

16.2. perf のインストール

この手順では、perf ユーザー空間ツールをインストールします。

手順

  • perf ツールをインストールします。

    # dnf install perf

16.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 コマンドのリストを表示します。

関連情報

  • サブコマンドに --help オプションを追加すると、man ページが表示されます。

第17章 perf top を使用した、リアルタイムでの CPU 使用率のプロファイリング

perf top コマンドを使用して、さまざまな機能の CPU 使用率をリアルタイムで測定できます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

17.1. perf top の目的

perf top コマンドは、top ユーティリティーと同様に、リアルタイムシステムのプロファイリングおよび機能に使用されます。ただし、top ユーティリティーは、通常、指定のプロセスまたはスレッドが使用している CPU 時間を示しており、perf top は各関数が使用する CPU 時間を表示します。デフォルトの状態では、perf top はユーザー空間とカーネル空間のすべての CPU で使用される関数について通知します。perf top を使用するには、root アクセスが必要です。

17.2. perf top を使用した CPU 使用率のプロファイリング

この手順では、perf top をアクティブにし、CPU 使用率をリアルタイムでプロファイルします。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。
  • root アクセスがある。

手順

  • perf top モニタリングインターフェイスを起動します。

    # perf top

    監視インターフェイスは、以下のようになります。

    Samples: 8K of event 'cycles', 2000 Hz, Event count (approx.): 4579432780 lost: 0/0 drop: 0/0
    Overhead  Shared Object       Symbol
       2.20%  [kernel]            [k] do_syscall_64
       2.17%  [kernel]            [k] module_get_kallsym
       1.49%  [kernel]            [k] copy_user_enhanced_fast_string
       1.37%  libpthread-2.29.so  [.] pthread_mutex_lock 1.31% [unknown] [.] 0000000000000000 1.07% [kernel] [k] psi_task_change 1.04% [kernel] [k] switch_mm_irqs_off 0.94% [kernel] [k] fget
       0.74%  [kernel]            [k] entry_SYSCALL_64
       0.69%  [kernel]            [k] syscall_return_via_sysret
       0.69%  libxul.so           [.] 0x000000000113f9b0
       0.67%  [kernel]            [k] kallsyms_expand_symbol.constprop.0
       0.65%  firefox             [.] moz_xmalloc
       0.65%  libpthread-2.29.so  [.] __pthread_mutex_unlock_usercnt
       0.60%  firefox             [.] free
       0.60%  libxul.so           [.] 0x000000000241d1cd
       0.60%  [kernel]            [k] do_sys_poll
       0.58%  [kernel]            [k] menu_select
       0.56%  [kernel]            [k] _raw_spin_lock_irqsave
       0.55%  perf                [.] 0x00000000002ae0f3

    この例では、カーネル機能の do_syscall_64 が最も多くの CPU 時間を使用しています。

関連情報

  • man ページの perf-top(1)

17.3. perf top 出力の解釈

perf top 監視インターフェイスでは、データが以下のようなさまざまな列で表示されます。

Overhead 列
指定された関数が使用している CPU のパーセントを表示します。
共有オブジェクトのコラム
機能を使用しているプログラムまたはライブラリー名を表示します。
Symbol 列
関数名またはシンボルを表示します。カーネル空間で実行される関数は [k] によって識別され、ユーザースペースで実行される関数は [.] によって識別されます。

17.4. perf が一部の関数名を raw 関数アドレスとして表示する理由

カーネル関数の場合は、perf/proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数については、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。

実行ファイルの debuginfo パッケージがインストールされているか、実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。

注記

実行ファイルに関連付けられた debuginfo をインストールした後に、perf record コマンドを再実行する必要はありません。単に perf report を再実行してください。

17.5. デバッグおよびソースのリポジトリーの有効化

Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。

手順

  • ソースおよびデバッグ情報パッケージチャネルを有効にします。$(uname -i) の部分は、システムのアーキテクチャーに一致する値に自動的に置き換えられます。

    アーキテクチャー名

    64 ビット Intel および AMD

    x86_64

    64 ビット ARM

    aarch64

    IBM POWER

    ppc64le

    64 ビット IBM Z

    s390x

17.6. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得

デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。

前提条件

手順

  1. デバッグするアプリケーションまたはライブラリーに割り当てられた 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)
  2. GDB を終了します。q と入力して、Enter で確認します。

    (gdb) q
  3. GDB が提案するコマンドを実行して、必要な debuginfo パッケージをインストールします。

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf パッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。

  4. GDB が debuginfo パッケージを提案できない場合は、手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得 で説明されている手順に従います。

関連情報

第18章 perf stat を使用したプロセス実行中のイベントのカウント

perf stat コマンドを使用すると、プロセスの実行中にハードウェアおよびソフトウェアのイベントをカウントできます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

18.1. perf stat の目的

perf stat コマンドは指定されたコマンドを実行し、コマンドの実行中にハードウェアおよびソフトウェアのイベントの発生回数を維持し、これらのカウントの統計を生成します。イベントを指定しないと、perf stat は共通のハードウェアおよびソフトウェアのイベントセットをカウントします。

18.2. perf stat を使用したイベントのカウント

perf stat を使用すると、コマンドの実行中に発生したハードウェアおよびソフトウェアのイベントをカウントし、これらのカウントの統計を生成できます。デフォルトでは、perf stat はスレッドごとのモードで動作します。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • イベントをカウントします。

    • root アクセスなしで perf stat コマンドを実行すると、ユーザー空間で発生したイベントのみをカウントします。

      $ perf stat ls

      例18.1 perf stat の出力が root アクセスなしで実行

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    1.28 msec task-clock:u               #    0.165 CPUs utilized
                       0      context-switches:u         #    0.000 M/sec
                       0      cpu-migrations:u           #    0.000 K/sec
                     104      page-faults:u              #    0.081 M/sec
               1,054,302      cycles:u                   #    0.823 GHz
               1,136,989      instructions:u             #    1.08  insn per cycle
                 228,531      branches:u                 #  178.447 M/sec
                  11,331      branch-misses:u            #    4.96% of all branches
      
             0.007754312 seconds time elapsed
      
             0.000000000 seconds user
             0.007717000 seconds sys

      以前の例で分かるように、perf stat を root アクセスなしで実行すると、イベント名の後に :u が付けられ、これらのイベントがユーザー空間でのみカウントされていることが分かります。

    • ユーザー空間およびカーネルスペースの両方のイベントをカウントするには、perf stat の実行時に root アクセスが必要になります。

      # perf stat ls

      例18.2 root アクセスで実行された perf stat の出力

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    3.09 msec task-clock                #    0.119 CPUs utilized
                      18      context-switches          #    0.006 M/sec
                       3      cpu-migrations            #    0.969 K/sec
                     108      page-faults               #    0.035 M/sec
               6,576,004      cycles                    #    2.125 GHz
               5,694,223      instructions              #    0.87  insn per cycle
               1,092,372      branches                  #  352.960 M/sec
                  31,515      branch-misses             #    2.89% of all branches
      
             0.026020043 seconds time elapsed
      
             0.000000000 seconds user
             0.014061000 seconds sys
      • デフォルトでは、perf stat はスレッドごとのモードで動作します。CPU 全体のイベントカウントに変更するには、-a オプションを perf stat に渡します。CPU 全体のイベントをカウントするには、root アクセスが必要です。

        # perf stat -a ls

関連情報

  • man ページの perf-stat(1)

18.3. perf stat 出力の解釈

perf stat は指定されたコマンドを実行し、コマンドの実行中にイベントの発生をカウントし、これらのカウントの統計を 3 列で表示します。

  1. 指定されたイベントでカウントされた発生数
  2. カウントされたイベントの名前。
  3. 関連するメトリックが利用可能な場合、右側のコラムのハッシュ記号 (#) の後に比率またはパーセンテージが表示されます。

    たとえば、デフォルトモードで実行している場合、perf stat はサイクルと命令の両方をカウントします。したがって、右端のコラムのサイクルごとの命令を計算して表示します。デフォルトでは両方のイベントがカウントされるため、分岐ミスに関して同様の動作がすべてのブランチのパーセントとして表示されます。

18.4. 実行中のプロセスに perf stat を割り当てる

perf stat を実行中のプロセスに割り当てることができます。これにより、コマンドの実行中に、指定したプロセスでのみ発生するイベントをカウントするように perf stat に指示します。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • perf stat を実行中のプロセスに割り当てます。

    $ perf stat -p ID1,ID2 sleep seconds

    前の例では、ID が ID1 and ID2 のプロセス内のイベントを、sleep コマンドで指定した seconds の秒数だけカウントします。

関連情報

  • man ページの perf-stat(1)

第19章 perf によるパフォーマンスプロファイルの記録および分析

perf ツールを使用すると、パフォーマンスデータを記録し、後で分析することができます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

19.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 サイクルをサンプルイベントとして使用し、継承モードが有効な状態でスレッドごとのモードで動作します。

19.2. root アクセスなしのパフォーマンスプロファイルの記録

root アクセスなしで perf record を使用すると、ユーザー空間のみのパフォーマンスデータのサンプリングおよび記録を行うことができます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • パフォーマンスデータのサンプルと記録:

    $ perf record command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.3. root アクセスによるパフォーマンスプロファイルの記録

root アクセスで perf record を使用して、ユーザー空間とカーネル空間の両方でパフォーマンスデータをサンプリングおよび記録できます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。
  • root アクセスがある。

手順

  • パフォーマンスデータのサンプルと記録:

    # perf record command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.4. CPU ごとのモードでのパフォーマンスプロファイルの記録

CPU ごとのモードで perf record を使用すると、監視対象の CPU のすべてのスレッドにわたって、ユーザー空間とカーネル空間の両方で同時にパフォーマンスデータをサンプリングして記録できます。デフォルトでは、CPU ごとのモードはすべてのオンライン CPU を監視します。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • パフォーマンスデータのサンプルと記録:

    # perf record -a command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.5. perf レコードで呼び出し先のデータを取得する

perf record ツールを設定して、どの関数がパフォーマンスプロファイル内の他の関数を呼び出しているかを記録することができます。これは、複数のプロセスが同じ関数を呼び出す場合にボトルネックを特定するのに役立ちます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • --call-graph オプションを使用して、パフォーマンスデータのサンプルと記録を行います。

    $ perf record --call-graph method command
    • command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。
    • method を、以下のアンワインドメソッドのいずれかに置き換えます。

      fp
      フレームポインターメソッドを使用します。GCC オプション --fomit-frame-pointer でビルドされたバイナリーの場合など、コンパイラーの最適化により、スタックをアンワインドできない可能性があります。
      dwarf
      DWARF 呼び出し情報を使用してスタックのアンワインドを行います。
      lbr
      Intel プロセッサーで最後のブランチレコードハードウェアを使用します。

関連情報

  • man ページの perf-record(1)

19.6. perf レポートを使用した perf.data の分析

perf report を使用して perf.data ファイルを表示し、分析できます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。
  • 現行ディレクトリーに perf.data ファイルがある。
  • perf.data ファイルが root アクセスで作成された場合は、root アクセスで perf report を実行する必要もあります。

手順

  • 詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report

    このコマンドは、以下のような出力を表示します。

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

関連情報

  • man ページの perf-report(1)

19.7. perf report 出力の解釈

perf report コマンドを実行して表示されるテーブルは、データを複数のコラムに分類します。

Overhead 列
その特定の関数で収集されたサンプル全体の割合を示します。
Command 列
サンプルが収集されたプロセスを通知します。
Shared Object 列
サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからのものである場合に [kernel.kallsyms] という名前が使用されます)。
Symbol 列
関数名またはシンボルを表示します。

デフォルトモードでは、関数は、オーバーヘッドの最も高いものが最初に表示される順に降順でソートされます。

19.8. 別のデバイスで読み取り可能な perf.data ファイルの生成

perf ツールを使用してパフォーマンスデータを perf.data ファイルに記録し、異なるデバイスで分析することができます。

前提条件

手順

  1. さらに調査する予定のパフォーマンスデータを取得します。

    # perf record -a --call-graph fp sleep seconds

    この例では、sleep コマンドの使用によって指定される 数でシステム全体の perf.data を生成します。また、フレームポインターの方法を使用して呼び出しグラフデータを取得します。

  2. 記録されたデータのデバッグシンボルを含むアーカイブファイルを生成します。

    # perf archive

検証手順

  • アーカイブファイルが現在のアクティブなディレクトリーで生成されたことを確認します。

    # ls perf.data*

    出力には、perf.data で始まる現在のディレクトリーのすべてのファイルが表示されます。アーカイブファイルの名前は以下のいずれかになります。

    perf.data.tar.gz

    または、以下を実行します。

    perf.data.tar.bz2

19.9. 別のデバイスで作成された perf.data ファイルの分析

perf ツールを使用して、別のデバイスで生成された perf.data ファイルを分析することができます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。
  • 使用中の現在のデバイスに、別のデバイスで生成された perf.data ファイルと関連アーカイブファイルが存在する。

手順

  1. perf.data ファイルとアーカイブファイルの両方を現在のアクティブなディレクトリーにコピーします。
  2. アーカイブファイルを ~/.debug にデプロイメントします。

    # mkdir -p ~/.debug
    # tar xf perf.data.tar.bz2 -C ~/.debug
    注記

    アーカイブファイルの名前は perf.data.tar.gz でも構いません。

  3. perf.data ファイルを開いて詳細な分析を行います。

    # perf report

19.10. perf が一部の関数名を raw 関数アドレスとして表示する理由

カーネル関数の場合は、perf/proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数については、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。

実行ファイルの debuginfo パッケージがインストールされているか、実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。

注記

実行ファイルに関連付けられた debuginfo をインストールした後に、perf record コマンドを再実行する必要はありません。単に perf report を再実行してください。

19.11. デバッグおよびソースのリポジトリーの有効化

Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。

手順

  • ソースおよびデバッグ情報パッケージチャネルを有効にします。$(uname -i) の部分は、システムのアーキテクチャーに一致する値に自動的に置き換えられます。

    アーキテクチャー名

    64 ビット Intel および AMD

    x86_64

    64 ビット ARM

    aarch64

    IBM POWER

    ppc64le

    64 ビット IBM Z

    s390x

19.12. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得

デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。

前提条件

手順

  1. デバッグするアプリケーションまたはライブラリーに割り当てられた 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)
  2. GDB を終了します。q と入力して、Enter で確認します。

    (gdb) q
  3. GDB が提案するコマンドを実行して、必要な debuginfo パッケージをインストールします。

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf パッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。

  4. GDB が debuginfo パッケージを提案できない場合は、手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得 で説明されている手順に従います。

関連情報

第20章 perf を使用したビジーな CPU の調査

システムでパフォーマンスの問題を調査する際には、perf ツールを使用して最もビジー状態の CPU を特定し、監視することで、作業に集中することができます。

20.1. perf stat でカウントされた CPU イベントの表示

perf stat を使用すると、CPU カウントアグリゲーションを無効にすることで、どの CPU イベントがカウントされたかを表示できます。この機能を使用するには、-a フラグを使用してシステム全体のモードでイベントをカウントする必要があります。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • CPU カウントアグリゲーションが無効になっているイベントをカウントします。

    # perf stat -a -A sleep seconds

    この例では、CPU0 以降の各 CPU に対して sleep コマンドを使用し、一定時間 ( 単位) に記録された一般的なハードウェアおよびソフトウェアイベントのデフォルトセット数が表示されます。そのため、cycle などのイベントを指定すると便利です。

    # perf stat -a -A -e cycles sleep seconds

20.2. perf レポートを使用して実行した CPU サンプルの表示

perf record コマンドはパフォーマンスデータをサンプルし、このデータを perf.data ファイルに保存します。このファイルは perf report コマンドで読み取ることができます。perf record コマンドは、どの CPU サンプルが発生したかを常に記録します。perf report を設定して、この情報を表示することができます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。
  • 現行ディレクトリーに perf recordperf.data ファイルが作成されている。perf.data ファイルが root アクセスで作成された場合は、root アクセスで perf report を実行する必要もあります。

手順

  • CPU でソートしながら、詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report --sort cpu
    • CPU およびコマンドでソートすると、CPU 時間が費やされている場所に関する詳細情報を表示できます。

      # perf report --sort cpu,comm

      この例では、すべての監視 CPU からのコマンドを、オーバーヘッド使用量の降順で合計オーバーヘッドでリスト表示し、コマンドが実行された CPU を特定します。

20.3. perf top を使用したプロファイリング中の特定の CPU の表示

perf top を設定して、システムのリアルタイムプロファイリング中に特定の CPU および相対使用率を表示できます。

前提条件

  • perf のインストール で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • CPU でソートしながら perf top インターフェイスを起動します。

    # perf top --sort cpu

    この例では、CPU とその各オーバーヘッドを、オーバーヘッド使用量の降順にリアルタイムでリスト表示します。

    • CPU およびコマンドでソートして、CPU 時間が費やされている場所の詳細を確認できます。

      # perf top --sort cpu,comm

      この例では、オーバーヘッド使用量の降順で合計オーバーヘッドでコマンドをリスト表示し、そのコマンドがリアルタイムに実行された CPU を特定します。

20.4. perf レコードと perf レポートを使用した特定 CPU の監視

</