Menu Close

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

Red Hat Enterprise Linux 9

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

概要

本ドキュメントは、Red Hat Enterprise Linux 9 のスループット、レイテンシー、および電力消費を、さまざまなシナリオで監視および最適化する方法を説明します。

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

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

Red Hat ドキュメントへのフィードバックの提供

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。

  • 特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第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 page.

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 に提供されるプロファイル。これは thoguhput-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 ファイルを編集し、以下の内容を追加します。

    # Isolated CPUs with the kernel’s scheduler load balancing:
    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 つのカテゴリー (静的 および 動的) の違いを説明します。

静的なチューニング
主に、事前定義された 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 プロファイルをインストールします。

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

    $ tuned-adm active
    
    Current active profile: balanced
    $ tuned-adm verify
    
    Verfication 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: balanced

関連情報

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

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

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

前提条件

手順

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

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

    # tuned-adm profile selected-profile

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

    # tuned-adm profile profile1 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
    
    Verfication 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 の無効化

この手順では、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 page.

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 つのカテゴリー (静的 および 動的) の違いを説明します。

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

ここでは、現在 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

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

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

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

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

[variables]

variable_name=value

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

${variable_name}

例2.8 変数を使用した 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.10. TuneD プロファイルの組み込み関数

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

以下を行うことができます。

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

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

${f:function_name:argument_1:argument_2}

プロファイルと tuned.conf ファイルが置かれたディレクトリーパスを展開するには、特殊な構文が必要な PROFILE_DIR 関数を使用します、

${i:PROFILE_DIR}

例2.9 変数と組み込み関数を使用した 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.11. 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.12. 新しい 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
    
    Verfication succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

関連情報

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

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

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

前提条件

手順

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

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

    [main]
    include=parent-profile

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

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

    例2.10 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
    
    Verfication 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 プロファイルを作成して有効にします。この設定は、システムを再起動しても持続します。

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

  • 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章 RHEL システムロールを使用したパフォーマンスの監視

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

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

RHEL システムロールは、Ansible ロールおよびモジュールのコレクションです。RHEL システムロールは、複数の RHEL システムをリモートで管理するための設定インターフェースを提供します。このインターフェースは、RHEL の複数のバージョンにわたるシステム設定の管理と、新しいメジャーリリースの導入を可能にします。

Red Hat Enterprise Linux 9 のインターフェースは、現在、以下のロールから構成されます。

  • 証明書の発行および更新
  • カーネル設定
  • メトリクス
  • Network Bound Disk Encryption クライアントおよび Network Bound Disk Encryption サーバー
  • ネットワーキング
  • postfix
  • SSH クライアント
  • SSH サーバー
  • システム全体の暗号化ポリシー
  • ターミナルセッションの録画

これらのロールはすべて、AppStream リポジトリーで利用可能な rhel-system-roles パッケージで提供されます。

関連情報

3.2. RHEL システムロールの用語

このドキュメントでは、以下の用語を確認できます。

Ansible Playbook
Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語です。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。
コントロールノード
Ansible がインストールされているマシン。コマンドおよび Playbook を実行でき、すべてのコントロールノードから /usr/bin/ansible または /usr/bin/ansible-playbook を起動します。Python がインストールされているすべてのコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、およびサーバーですべての Ansible を実行できます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを使用できます。
インベントリー
管理対象ノードの一覧。インベントリーファイルは「ホストファイル」とも呼ばれます。インベントリーでは、各管理対象ノードに対して IP アドレスなどの情報を指定できます。また、インベントリーは管理ノードを編成し、簡単にスケーリングできるようにグループの作成およびネスト化が可能です。インベントリーについての詳細は、「インベントリーの操作」セクションを参照してください。
管理ノード
Ansible で管理するネットワークデバイス、サーバー、またはその両方。管理対象ノードは、「ホスト」と呼ばれることもあります。Ansible が管理ノードにはインストールされません。

3.3. システムへの RHEL システムロールのインストール

RHEL システムロールを使用するには、システムに必要なパッケージをインストールします。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • コントロールノードとして使用するシステムに Ansible パッケージがインストールされている。

手順

  1. rhel-system-roles パッケージを、コントロールノードとして使用するシステムにインストールします。

    # dnf install rhel-system-roles
  2. Ansible Core パッケージをインストールします。

    # dnf install ansible-core

Ansible Core パッケージは、ansible-playbook CLI、Ansible Vault 機能、および RHEL Ansible コンテンツに必要な基本的なモジュールとフィルターを提供します。

結果として、Ansible の Playbook を作成できます。

関連情報

3.4. ロールの適用

以下の手順では、特定のロールを適用する方法を説明します。

前提条件

  • rhel-system-roles パッケージが、コントロールノードとして使用するシステムにインストールされていることを確認します。

    # dnf install rhel-system-roles
    1. Ansible Core パッケージをインストールします。

      # dnf install ansible-core

      Ansible Core パッケージは、ansible-playbook CLI、Ansible Vault 機能、および RHEL Ansible コンテンツに必要な基本的なモジュールとフィルターを提供します。

  • Ansible インベントリーを作成できることを確認します。

    インベントリーは、ホスト、ホストグループ、および Ansible Playbook で使用されるいくつかの設定パラメーターを表します。

    Playbook は通常人が判読でき、iniyamljson、およびその他のファイル形式で定義されます。

  • Ansible Playbook を作成できることを確認します。

    Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語を表します。Playbook を使用すると、リモートマシンの設定を宣言して管理したり、複数のリモートマシンをデプロイしたり、手動で順番を付けたプロセスの手順をまとめたりできます。

    Playbook は、1 つ以上の play の一覧です。すべての play には、Ansible の変数、タスク、またはロールが含まれます。

    Playbook は人が判読でき、yaml 形式で定義されます。

手順

  1. 管理するホストおよびグループを含む必要な Ansible インベントリーを作成します。以下の例は、webservers と呼ばれるホストのグループの inventory.ini というファイルを使用します。

    [webservers]
    host1
    host2
    host3
  2. 必要なロールを含む Ansible Playbook を作成します。以下の例では、Playbook の roles: オプションを使用してロールを使用する方法を示しています。

    以下の例は、特定の playroles: オプションを使用してロールを使用する方法を示しています。

    ---
    - hosts: webservers
      roles:
    
         - rhel-system-roles.network
         - rhel-system-roles.postfix
    注記

    すべてのロールには README ファイルが含まれます。このファイルには、ロールや、サポートされるパラメーター値の使用方法が記載されています。ロールのドキュメントディレクトリーで、特定ロール用の Playbook のサンプルを見つけることもできます。このようなドキュメンテーションディレクトリーは、rhel-system-roles パッケージでデフォルトで提供され、以下の場所に置かれます。

    /usr/share/doc/rhel-system-roles/SUBSYSTEM/

    SUBSYSTEM を、必要なロールの名前 (postfixmetricsnetworktlog、または ssh など) に置き換えます。

  3. 特定のホストで Playbook を実行するには、以下のいずれかを実行する必要があります。

    • hosts: host1[,host2,…​] または hosts: all を使用するように Playbook を編集して、以下のコマンドを実行します。

      # ansible-playbook name.of.the.playbook
    • インベントリーを編集して、使用するホストがグループで定義されていることを確認し、以下のコマンドを実行します。

      # ansible-playbook -i name.of.the.inventory name.of.the.playbook
    • ansible-playbook コマンドの実行時にすべてのホストを指定します。

      # ansible-playbook -i host1,host2,... name.of.the.playbook
      重要

      -i フラグは、利用可能なすべてのホストのインベントリーを指定することに注意してください。ターゲットホストが複数あるが、Playbook を実行するホストを選択する場合は、Playbook に変数を追加して、ホストを選択できるようにすることができます。以下に例を示します。

      Ansible Playbook | example-playbook.yml:
      
      
      - hosts: "{{ target_host }}"
        roles:
           - rhel-system-roles.network
           - rhel-system-roles.postfix

      Playbook 実行コマンド:

      # ansible-playbook -i host1,..hostn -e target_host=host5 example-playbook.yml

3.5. メトリックシステムロールの概要

RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した設定インターフェースを提供する Ansible ロールおよびモジュールの集合です。Metrics システムロールはローカルシステムのパフォーマンス分析サービスを設定します。これには、オプションでローカルシステムによって監視されるリモートシステムの一覧が含まれます。メトリックシステムロールを使用すると、pcp の設定とデプロイメントが Playbook によって処理されるため、pcp を個別に設定せずに pcp を使用してシステムパフォーマンスを監視できます。

表3.1 メトリックシステムロール変数

ロール変数説明使用例

metrics_monitored_hosts

ターゲットホストが分析するリモートホストの一覧。これらのホストにはターゲットホストにメトリックが記録されるため、各ホストの /var/log の下に十分なディスク領域があることを確認してください。

metrics_monitored_hosts: ["webserver.example.com", "database.example.com"]

metrics_retention_days

削除前のパフォーマンスデータの保持日数を設定します。

metrics_retention_days: 14

metrics_graph_service

pcp および grafana を介してパフォーマンスデータの視覚化のためにホストをサービスで設定できるようにするブール値フラグ。デフォルトでは false に設定されます。

metrics_graph_service: no

metrics_query_service

redis 経由で記録された pcp メトリックをクエリーするための時系列クエリーサービスでのホストの設定を可能にするブール値フラグ。デフォルトでは false に設定されます。

metrics_query_service: no

metrics_provider

メトリックを提供するために使用するメトリックコレクターを指定します。現在、サポートされている唯一のメトリックプロバイダーは pcp です。

metrics_provider: "pcp"

注記

metrics_connections で使用されるパラメーターの詳細と、Metrics システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイルを参照してください。

3.6. メトリクスシステムロールを使用した視覚化によるローカルシステムの監視

この手順では、メトリクスの RHEL システムロールを使用してローカルシステムを監視し、Grafana でデータビジュアライゼーションを同時にプロビジョニングする方法を説明します。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • 監視するマシンに rhel-system-roles パッケージがインストールされている。

手順

  1. 以下のコンテンツをインベントリーに追加して、/etc/ansible/hosts Ansible インベントリーの localhost を設定します。

    localhost ansible_connection=local
  2. 以下の内容を含む Ansible Playbook を作成します。

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
      roles:
        - rhel-system-roles.metrics
  3. Ansible Playbook の実行:

    # ansible-playbook name_of_your_playbook.yml
    注記

    metrics_graph_service のブール値が value="yes" に設定されているため、Grafana は自動的にインストールされ、データソースとして追加されたpcpでプロビジョニングされます。

  4. マシンで収集されるメトリクスを視覚化するには、「 Grafana Web UI へのアクセス」で説明されているように grafana Web インターフェースにアクセスします。

3.7. メトリックシステムロールを使用した自己監視のための個別システムの集合の設定

この手順では、Metrics システムロールを使用して、それ自体を監視するマシンの集合を設定する方法を説明します。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook の実行に使用するマシンに rhel-system-roles パッケージがインストールされている。
  • SSH 接続が確立している。

手順

  1. Playbook 経由で監視するマシンの名前または IP を、括弧で囲まれた識別グループ名で /etc/ansible/hosts Ansible インベントリーファイルに追加します。

    [remotes]
    webserver.example.com
    database.example.com
  2. 以下の内容を含む Ansible Playbook を作成します。

    ---
    - hosts: remotes
      vars:
        metrics_retention_days: 0
      roles:
        - rhel-system-roles.metrics
  3. Ansible Playbook の実行:

    # ansible-playbook name_of_your_playbook.yml -k

リモートシステムに接続するためのパスワードを求められる-k です。

3.8. メトリクスシステムロールを使用したローカルマシンを介したマシンの集合の一元監視

この手順では、grafana を介してデータの視覚化のプロビジョニングおよび redis 経由でデータのクエリーを行う間に、Metrics システムロールを使用してローカルマシンを設定し、マシンの集合を一元管理する方法を説明します。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook の実行に使用するマシンに rhel-system-roles パッケージがインストールされている。

手順

  1. 以下の内容を含む Ansible Playbook を作成します。

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
      roles:
        - rhel-system-roles.metrics
  2. Ansible Playbook の実行:

    # ansible-playbook name_of_your_playbook.yml
    注記

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

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

3.9. Metrics システムロールを使用したシステムの監視中に認証の設定

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

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook の実行に使用するマシンに rhel-system-roles パッケージがインストールされている。

手順

  1. 認証を設定する Ansible Playbook に、以下の変数を追加します。

    ---
      vars:
        metrics_username: your_username
        metrics_password: your_password
  2. Ansible Playbook の実行:

    # ansible-playbook name_of_your_playbook.yml

検証手順

  • sasl 設定を確認します。

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

    ip_adress は、ホストの IP アドレスに置き換える必要があります。

3.10. メトリクスシステムロールを使用した SQL Server のメトリクス収集の設定および有効化

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

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • 監視するマシンに rhel-system-roles パッケージがインストールされている。
  • Red Hat Enterprise Linux に Microsoft SQL Server をインストールし、SQL Server への「信頼できる」接続を確立している。「Installing SQL Server」および「create a database on Red Hat 」を参照してください。
  • Red Hat Enterprise Linux 用の SQL Server の Microsoft ODBC ドライバーがインストールされている。Red Hat Enterprise Server および Oracle Linux を参照してください。

手順

  1. 以下のコンテンツをインベントリーに追加して、/etc/ansible/hosts Ansible インベントリーの localhost を設定します。

    localhost ansible_connection=local
  2. 以下の内容が含まれる Ansible Playbook を作成します。

    ---
    - hosts: localhost
      roles:
        - role: rhel-system-roles.metrics
          vars:
            metrics_from_mssql: yes
  3. Ansible Playbook の実行:

    # ansible-playbook name_of_your_playbook.yml

検証手順

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

    # pcp
    platform: Linux rhel82-2.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/rhel82-2.local/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/rhel82-2.local/pmie.log

関連情報

  • Microsoft SQL Server での Performance Co-Pilot の使用に関する詳細は、Red Hat Developers Blog を参照してください。


[1] 本書は rhel-system-roles パッケージで自動的にインストールされます。

第4章 PCP の設定

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

本セクションでは、システムに PCP をインストールして有効にする方法を説明します。

4.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 パッケージをインストールします。詳細は、「PCP Charts アプリケーションで PCP ログアーカイブを Visually tracing」を 参照してください。

関連情報

4.2. PCP のインストールおよび有効化

PCP の使用を開始するには、必要なパッケージをすべてインストールし、PCP 監視サービスを有効にします。

この手順では、pcp パッケージを使用して PCP をインストールする方法を説明します。PCP のインストールを自動化するには、pcp-zeroconf パッケージを使用してインストールします。pcp-zeroconf を使用して PCP をインストールする方法は、「 pcp-zeroconf で PCP の設定 」を参照してください。

手順

  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

関連情報

4.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 ツールを使用してデータを解析します。

関連情報

4.4. PCP で配布されるシステムサービス

以下の表は、PCP で配布されるさまざまなシステムサービスのロールについて説明しています。

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

名前

説明

pmcd

PMCD (Performance Metric Collector Daemon)

pmie

Performance Metrics In difference Engine

pmlogger

パフォーマンスメトリックロガー。

pmproxy

リアルタイムおよびヒストリカルなパフォーマンスメトリクスのプロキシ、時系列クエリ、REST APIサービス。

4.5. PCP と共に配布されるツール

以下の表は、PCP で配布される各種ツールの使用について説明しています。

表4.2 PCP で配布されるツールの使用

名前

説明

pcp

Performance Co-Pilot インストールの現在のステータスを表示します。

pcp-atop

パフォーマンスの観点から最も重要なハードウェアリソース (CPU、メモリー、ディスク、およびネットワーク) のシステムレベルの占有を表示します。

pcp-atopsar

さまざまなシステムリソースの使用状況に関するシステムレベルのアクティビティレポートを生成します。このレポートは、pmloggerまたはpcp-atopの-wオプションを使ってあらかじめ記録された生のログファイルから生成されます。

pcp-dmcache

設定されたデバイスマッパーキャッシュターゲット(デバイスのIOP、キャッシュデバイスとメタデータデバイスの使用率、各キャッシュデバイスの読み取り/書き込みのヒット率とミス率、比率など)に関する情報を表示します。

pcp-dstat

一度に 1 台のシステムのメトリックを表示します。複数のシステムのメトリックを表示するには、--host オプションを使用します。

pcp-free

システム内の空きメモリと使用済みメモリを報告します。

pcp-htop

システム上で実行されているすべてのプロセスとそのコマンドライン引数を、topコマンドと同様の形式で表示しますが、縦横にスクロールしたり、マウスで操作したりすることができます。また、プロセスをツリー形式で表示したり、複数のプロセスを選択して一度に処理することもできます。

pcp-ipcs

呼び出したプロセスが読み取りアクセスできるIPC(Inter-Process Communication)ファシリティーの情報を表示します。

pcp-numastat

カーネルのメモリアロケータからのNUMA割り当て統計を表示します。

pcp-pidstat

システム上で動作している個々のタスクやプロセスに関する情報を表示します(CPUパーセンテージ、メモリやスタックの使用率、スケジューリング、優先度など)。デフォルトでは、ローカルホストのライブデータを報告します。

pcp-ss

pmdasockets Performance Metrics Domain Agent (PMDA) が収集したソケットの統計情報を表示します。

pcp-uptime

システムの稼働時間、現在ログオンしているユーザー数、過去1分、5分、15分のシステム負荷の平均値を表示します。

pcp-vmstat

システムパフォーマンスの概要を5秒ごとに表示します。プロセス、メモリー、ページング、ブロックIO、トラップ、CPUのアクティビティに関する情報を表示します。

pmchart

Performance Co-Pilot の機能を介して利用可能なパフォーマンスメトリック値を描画します。

pmclient

PMAPI (Performance Metrics Application Programming Interface) を使用して、高水準のシステムパフォーマンスメトリックを表示します。

pmconfig

設定パラメーターの値を表示します。

pmdbg

利用可能な Performance Co-Pilot デバッグ制御フラグとその値を表示します。

pmdiff

パフォーマンスのリグレッションを検索する際に重要と思われる変更について、指定された時間枠で、1 つまたは 2 つのアーカイブのすべてのメトリックの平均値を比較します。

pmdumplog

Performance Co-Pilot アーカイブファイルの制御、メタデータ、インデックス、および状態に関する情報を表示します。

pmdumptext

ライブまたは Performance Co-Pilot アーカイブから収集されたパフォーマンスメトリックの値を出力します。

pmerr

利用可能な Performance Co-Pilot エラーコードと、それに対応するエラーメッセージを表示します。

pmfind

ネットワークで PCP サービスを見つけます。

pmie

一連の演算式、論理式、およびルール式を定期的に評価する推論エンジン。メトリックは、ライブシステムまたは Performance Co-Pilot アーカイブファイルのいずれかから収集されます。

pmieconf

設定可能な pmie 変数を表示または設定します。

pmiectl

pmieのプライマリ以外のインスタンスを管理します。

pminfo

パフォーマンスメトリックに関する情報を表示します。メトリックは、ライブシステムまたは Performance Co-Pilot アーカイブファイルのいずれかから収集されます。

pmiostat

SCSI デバイス (デフォルト) またはデバイスマッパーデバイス (-x dm オプションを使用) の I/O 統計を報告します。

pmlc

アクティブな pmlogger インスタンスを対話的に設定します。

pmlogcheck

Performance Co-Pilot アーカイブファイルで無効なデータを特定します。

pmlogconf

pmlogger 設定ファイルを作成および変更します。

pmlogctl

pmloggerのプライマリ以外のインスタンスを管理します。

pmloglabel

Performance Co-Pilot アーカイブファイルのラベルを検証、変更、または修復します。

pmlogsummary

Performance Co-Pilot アーカイブファイルに格納されたパフォーマンスメトリックに関する統計情報を計算します。

pmprobe

パフォーマンスメトリックの可用性を決定します。

pmrep

選択した、簡単にカスタマイズ可能なパフォーマンスメトリック値に関するレポート。

pmsocks

ファイアウォールを介して Performance Co-Pilot ホストへのアクセスを許可します。

pmstat

システムパフォーマンスの簡単な概要を定期的に表示します。

pmstore

パフォーマンスメトリックの値を変更します。

pmtrace

トレースPMDAのコマンドラインインターフェースを提供します。

pmval

パフォーマンスメトリックの現在の値を表示します。

4.6. PCPデプロイメントのアーキテクチャ

Performance Co-Pilot(PCP)には、高度なセットアップを実現するための多くのオプションが用意されています。膨大な数のアーキテクチャが考えられますが、このセクションでは、Red Hatが設定した推奨のデプロイメント、サイジング要素、および構成オプションに基づいて、PCPデプロイメントをスケーリングする方法について説明します。

PCPは、PCPのデプロイメント規模に応じて、複数のデプロイメントアーキテクチャをサポートしています。

利用可能なスケーリングデプロイメントセットアップバリエーション

Localhost

各サービスは監視対象のマシン上でローカルに動作します。設定を変更せずにサービスを開始した場合、これがデフォルトのデプロイメントです。この場合、個々のノードを超えたスケーリングはできません。

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

Decentralized

ローカルホストと分散型のセットアップの唯一の違いは、集中型のRedisサービスです。このモデルでは、ホストは監視対象の各ホスト上でpmloggerサービスを実行し、ローカルのpmcdインスタンスからメトリクスを取得します。そして、ローカルのpmproxyサービスは、パフォーマンスメトリクスを中央のRedisインスタンスにエクスポートします。

図4.1 分散型ロギング

分散型ロギング
集中型ロギング - pmlogger ファーム

監視対象ホストのリソース使用量が制限されている場合、pmloggerファームというデプロイメントオプションもあります。これは集中型ロギングとも呼ばれます。この設定では、1つのロガーホストが複数のpmloggerプロセスを実行し、それぞれが異なるリモートpmcdホストからパフォーマンスメトリクスを取得するように設定されます。集中ロガーのホストはpmproxyサービスを実行するように設定され、このサービスは、結果として生じるPCPアーカイブズのログを検出し、メトリクスデータをRedisインスタンスに読み込みます。

図4.2 集中型ロギング - pmlogger ファーム

集中型ロギング - pmlogger ファーム
統合型 - 複数の pmlogger ファーム

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

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

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

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

関連情報

4.8. サイジングファクター

スケーリングに必要なサイジングファクターは以下のとおりです。

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ページ

4.9. 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 ページ

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

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

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

表4.4 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

表4.5 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 クエリーを高速化します。これにより、メモリー使用率が高くなる可能性があります。この問題 のトラブルシューティングは、「高メモリー使用量 のトラブルシューティング」を参照してください。

4.11. 例: 統合型セットアップデプロイメントの分析

以下の結果が、統合型セットアップ (複数の pmlogger ファームとも呼ばれる) で確認されました。これは、3 つの集中ロギング (pmlogger ファーム) セットアップで構成されます。各 pmlogger ファームは 100 のリモートホスト、つまり合計 300 のホストを監視していました。

pmlogger ファームのこのセットアップは、Redis サーバーがクラスターモードで動作していたことを除いて、60 秒のログ間隔での 例: 集中ロギングデプロイメントの分析 で説明した設定と同じです。

表4.6 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 クラスターのノード間通信により、ネットワーク帯域幅が高まります。

4.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 メトリックスを参照してください。

関連情報

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

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

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

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

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

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

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

前提条件

手順

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

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

関連情報

5.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;

5.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

関連情報

5.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))

関連情報

5.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/ ディレクトリーのアーカイブファイルは、詳細な分析とグラフ作成に使用できます。

関連情報

5.6. 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章 Performance Co-Pilot によるパフォーマンスの監視

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

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

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

関連情報

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

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

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

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

前提条件

手順

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

    # pmchart

    図6.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"

関連情報

6.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 コマンドを使用して、システムでこれらのメトリックのグラフィックチャートを表示します。詳細は、「PCP Charts アプリケーションで PCP ログアーカイブを Visually tracing」を 参照してください。

関連情報

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

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

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

本セクションでは、PCP を使用して XFS ファイルシステムのパフォーマンスを分析する方法を説明します。

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

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

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

前提条件

手順

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

    # cd /var/lib/pcp/pmdas/xfs/

検証手順

  • 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

関連情報

7.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

7.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

関連情報

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

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

表7.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 ツールを使用して切り替えられます。

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

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

表7.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 の操作に関するメトリック。

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

pcpgrafanapcp redispcp bpftrace、および pcp vector の組み合わせを使用すると、ライブデータまたは Performance Co-Pilot (PCP) によって収集されるデータに基づいたグラフが提供されます。

本セクションでは、PCP メトリックのグラフィカル表示を設定してアクセスする方法を説明します。

8.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

関連情報

8.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 ページ

8.3. Grafana Web UI へのアクセス

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

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

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

前提条件

  1. PCP が設定されている。詳細は、「 pcp-zeroconf で PCP の設定 」を参照してください。
  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 ページが表示されます。

    図8.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 ページ

8.4. PCP Redis の設定

本セクションでは、PCP Redis データソースを設定する方法を説明します。

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

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

前提条件

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

手順

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

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

    # systemctl start pmproxy redis
    # systemctl enable pmproxy redis
  3. メール転送エージェント (sendmail または postfix など) がインストールされ、設定されている。
  4. allow_loading_unsigned_plugins パラメーターが、grafana.ini ファイルの PCP Redis データベースに設定されていることを確認します。

    # vi /etc/grafana/grafana.ini
    
    allow_loading_unsigned_plugins = pcp-redis-datasource
  5. grafana-server を再起動します。

    # systemctl restart grafana-server

検証手順

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

    # pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df

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

関連情報

  • pmseries(1) の man ページ

8.5. 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 をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。

      図8.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. 保存 をクリックして変更を適用し、ダッシュボードを保存します。Dashboard name を追加します。
    5. Apply をクリックして変更を適用し、ダッシュボードに戻ります。

      図8.3 PCP Redis クエリーパネル

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

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

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

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

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

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

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

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

前提条件

  1. grafana-server にアクセスできる。詳細は、「 Grafana Web UI へのアクセス」を 参照してください。
  2. アラートルールが作成されている。詳細は、「 Creating panels and alert in PCP Redis data source 」を参照してください。
  3. SMTP を設定し、grafana/grafana.ini ファイルに有効な送信者のメールアドレスを追加します。

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

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

手順

  1. メニューで    alerting bell icon    Alerting iconclick Notification channelsAdd channel の順でカーソルを合わせます。
  2. Add notification channel details ペインで、以下を実行します。

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

    1. メニューで    alerting bell icon    Alerting アイコンにマウスを合わせ、Alert rules をクリックします。
    2. Alert Rules タブで、作成されたアラートルールをクリックします。
    3. Notifications タブで Send to オプションから通知チャネル名を選択し、アラートメッセージを追加します。
    4. 適用 をクリックします。

8.7. 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

関連情報

8.8. PCP bpftrace のインストール

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

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

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

前提条件

  1. PCP が設定されている。詳細は、「 pcp-zeroconf で PCP の設定 」を参照してください。
  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 ページ

8.9. 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 をクリックします。

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

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

      図8.6 PCP bpftrace: システム分析

      pcp bpftrace システム分析

8.10. PCP Vector のインストール

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

前提条件

  1. PCP が設定されている。詳細は、「 pcp-zeroconf で PCP の設定 」を参照してください。
  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 ページ

8.11. 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 をクリックして、有用なメトリックの概要を含むダッシュボードを表示します。

      図8.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    警告アイコをクリックし、関連するトラブルシューティングまたは参照リンクを表示します。

    図8.8 Performance Co-Pilot / PCP Vector Checklist

    pcp vector checklist

8.12. 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>
    [...]

第9章 ディスクスケジューラーの設定

ディスクスケジューラーは、ストレージデバイスに送信された I/O 要求を順序付けます。

スケジューラーは以下の複数の方法で設定できます。

注記

Red Hat Enterprise Linux 9 では、ブロックデバイスはマルチキュースケジューリングのみに対応します。これにより、ブロックレイヤーのパフォーマンスを高速ソリッドステートドライブ (SSD) およびマルチコアシステムで適切に拡張できます。

Red Hat Enterprise Linux 7 以前のバージョンで利用できた従来のシングルキュースケジューラーが削除されました。

9.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 などの低レイテンシーデバイスなど、高速なデバイスに適しています。

9.2. 各種ユースケースで異なるディスクスケジューラー

システムが実行するタスクに応じて、分析タスクおよびチューニングタスクの前に、以下のディスクスケジューラーがベースラインとして推奨されます。

表9.1 各種ユースケースのディスクスケジューラー

ユースケースディスクスケジューラー

SCSI インターフェースを備えた従来の HDD

mq-deadline または bfq を使用します。

高速ストレージで高パフォーマンスの SSD または CPU がバインドされたシステム

特にエンタープライズアプリケーションを実行する場合は none を使用します。または kyber を使用します。

デスクトップまたはインタラクティブなタスク

bfq を使用します。

仮想ゲスト

mq-deadline を使用します。マルチキューに対応しているホストバスアダプター (HBA) ドライバーでは、none を使用します。

9.3. デフォルトのディスクスケジューラー

ブロックデバイスは、別のスケジューラーを指定しない限り、デフォルトのディスクスケジューラーを使用します。

注記

NVMe (Non-volatile Memory Express) ブロックデバイスの場合、デフォルトのスケジューラーは none であり、Red Hat ではこれを変更しないことを推奨します。

カーネルは、デバイスのタイプに基づいてデフォルトのディスクスケジューラーを選択します。自動的に選択されたスケジューラーは、通常、最適な設定です。別のスケジューラーが必要な場合は、Red Hat では、udev ルールまたは TuneD アプリケーションを使用して設定することを推奨しています。選択したデバイスを一致させ、それらのデバイスのスケジューラーのみを切り替えます。

9.4. アクティブなディスクスケジューラーの決定

この手順では、特定のブロックデバイスで現在アクティブなディスクスケジューラーを確認します。

手順

  • /sys/block/device/queue/scheduler ファイルの内容を読み取ります。

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

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

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

9.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 などのブロックデバイス名に置き換えます。

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

9.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

9.7. 特定ディスクに任意のスケジューラーを一時的に設定

この手順では、特定のブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動すると元に戻ります。

手順

  • 選択したスケジューラーの名前を、/sys/block/device/queue/scheduler ファイルに書き込みます。

    # echo selected-scheduler > /sys/block/device/queue/scheduler

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

検証手順

  • スケジューラーがデバイスでアクティブになっていることを確認します。

    # cat /sys/block/device/queue/scheduler

第10章 Samba サーバーのパフォーマンスチューニング

本章では、特定の状況で Samba のパフォーマンスを改善できる設定と、パフォーマンスが低下する可能性のある設定を説明します。

このセクションの一部は、Samba Wiki に公開されているドキュメント「Performance Tuning」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

前提条件

  • Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。

10.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

10.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 はディレクトリーを大文字と小文字で分けたスキャンが不要になり、パフォーマンスが向上します。

10.3. パフォーマンスが低下する可能性のある設定

デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスが高くなるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf ファイルに socket options パラメーターを設定すると、このカーネル設定が上書きされます。その結果、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。

カーネルの最適化された設定を使用するには、/etc/samba/smb.conf[global] セクションから socket options パラメーターを削除します。

第11章 PowerTOP を使用した電力消費の管理

システム管理者であれば、PowerTOP ツールを使用して、消費電力を解析および管理できます。

11.1. PowerTOP の目的

PowerTOP は、消費電力に関連する問題を診断し、バッテリーの寿命を延ばす方法について提案を示すプログラムです。

PowerTOP ツールは、システムの総電力使用量の想定と、各プロセス、デバイス、カーネルワーカー、タイマー、および割り込みハンドラーの個々の電力使用量の想定を示すことができます。このツールは、CPU を頻繁にウェイクアップするカーネルおよびユーザー空間アプリケーションの特定のコンポーネントを識別することもできます。

Red Hat Enterprise Linux 9 は、PowerTOP のバージョン2.x を使用します。

11.2. PowerTOP の使用

前提条件

  • PowerTOP を使用できるようにするには、powertop パッケージがシステムにインストールされていることを確認してください。

    # dnf install powertop

11.2.1. PowerTOP の起動

手順

  • PowerTOP を実行するには、次のコマンドを使用します。

    # powertop
重要

powertop コマンドの実行時には、ラップトップはバッテリー電源で動作します。

11.2.2. PowerTOP の調整

手順

  1. ラップトップでは、次のコマンドを実行して電力予測エンジンを調整することができます。

    # powertop --calibrate
  2. プロセス中にマシンと対話せずに、調整を終了させます。

    プロセスがさまざまなテストを実行し、輝度を切り替え、デバイスのオンとオフを切り替える操作を繰り返すため、調整には時間がかかります。

  3. 調整プロセスが完了すると、PowerTOP が通常どおり起動します。データを収集するために約 1 時間実行します。

    十分なデータが収集されると、出力テーブルの最初の列に電力予測マークが表示されます。

注記

powertop --calibrate は、ノートパソコンでのみ使用できることに注意してください。

11.2.3. 測定間隔の設定

デフォルトでは、PowerTOP は、20 秒間隔で測定します。

この測定頻度を変更する場合は、以下の手順に従います。

手順

  • --time オプションを指定して powertop コマンドを実行します。

    # powertop --time=time in seconds

11.3. PowerTOP の統計

PowerTOP は、実行中に、システムから統計を収集します。

PowerTOP の出力には、複数のタブがあります。

  • Overview
  • idle stats
  • Frequency stats
  • Device stats
  • Tunables
  • WakeUp

Tab キーおよび Shift+ Tab キーを使用して、このタブを順番に切り替えることができます。

11.3.1. Overview タブ

Overview タブでは、ウェイクアップを最も頻繁に CPU に送信するか、最も電力を消費するコンポーネントの一覧を表示できます。プロセス、割り込み、デバイス、その他のリソースなど、Overview タブの項目は、使用率に従って並べ替えられます。

Overview タブで隣接する列は、以下の情報を提供します。

Usage
リソース使用の電力想定。
Events/s
1 秒あたりウェイクアップ。1 秒あたりのウェイクアップ数は、サービスまたはデバイス、ならびにカーネルのドライバーがいかに効率的に実行しているかを示します。ウェイクアップが少ないほど、消費電力が少なくなります。コンポーネントは、電力使用率をどの程度まで最適化できるかによって順序付けられます。
Category
プロセス、デバイス、タイマーなどのコンポーネントの分類。
説明
コンポーネントの説明。

適切に調整すると、最初の列にリストされているすべての項目に対する電力消費予測も表示されます。

これとは別に、Overview タブには、次のようなサマリー統計の行が含まれます。

  • 合計電力消費
  • バッテリーの残り寿命 (該当する場合)
  • 1 秒あたりの合計ウェイクアップ数、1 秒あたり GPU 操作数、および 1 秒あたりの仮想ファイルシステム操作数の概要

11.3.2. Idle stats タブ

Idle stats タブには、すべてのプロセッサーおよびコアに対する C 状態の使用率が表示されます。Frequency stats タブには、(該当する場合は) すべてのプロセッサーおよびコアに対する Turbo モードを含む P 状態の使用率が表示されます。C または P 状態の長さは、CPU 使用率がどの程度最適化されているかを示します。CPU の C 状態または P 状態が高いままになるほど (C4 が C3 よりも高くなるなど)、CPU 使用率がより最適化されます。システムがアイドル状態の時に、最高の C 状態または P 状態の常駐が 90% 以上になることが理想的と言えます。

11.3.3. Device stats タブ

Device stats タブは Overview タブと同様の情報を提供しますが、デバイス専用です。

11.3.4. Tunables タブ

Tunables タブには、低消費電力にシステムを最適化するための、PowerTOP の推奨事項が含まれます。

up キーおよび down キーを使用して提案を移動し、enter キーを使用して提案をオンまたはオフにします。

11.3.5. WakeUp タブ

WakeUp タブには、ユーザーが必要に応じて変更できるデバイスウェイクアップ設定が表示されます。

up キーおよび down キーを使用して利用可能な設定を移動し、enter キーを使用して設定を有効または無効にします。

図11.1 PowerTOP 出力

powertop2 14

関連情報

PowerTOP の詳細は、PowerTOP のホームページ を参照してください。

11.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

11.5. HTML 出力の生成

端末の powertop の出力結果以外にも、HTML レポートを生成することもできます。

手順

  • --html オプションを指定して powertop コマンドを実行します。

    # powertop --html=htmlfile.html

    htmlfile.html パラメーターを、出力ファイルに必要な名前に置き換えます。

11.6. 電力消費の最適化

電力消費を最適化するには、powertop サービスまたは powertop2tuned ユーティリティーを使用できます。

11.6.1. powertop サービスで消費電力の最適化

powertop サービスを使用すると、システムの起動の Tunables タブから、すべての PowerTOP の提案を自動的に有効にできます。

手順

  • powertop サービスを有効にします。

    # systemctl enable powertop

11.6.2. powertop2tuned ユーティリティー

powertop2tuned ユーティリティを使用すると、PowerTOPの提案からカスタムTuneDプロファイルを作成できます。

デフォルトでは、powertop2tuned は、/etc/tuned/ ディレクトリーにプロファイルを作成し、現在選択している TuneD プロファイルを基にしてカスタムプロファイルを作成します。安全上の理由から、すべての PowerTOP チューニングは最初に新しいプロファイルで無効になっています。

チューニングを有効にするには、以下を行います。

  • /etc/tuned/profile_name/tuned.conf ファイルでコメントを解除します。
  • --enable オプションまたは -e オプションを使用して、PowerTOP により提案されたチューニングのほとんどを可能にする新しいプロファイルを生成します。

    USB 自動サスペンドなど、既知の問題のある特定のチューニングはデフォルトで無効になっているため、手動でコメントを解除する必要があります。

11.6.3. powertop2tuned ユーティリティーで電力消費の最適化

前提条件

  • powertop2tuned ユーティリティーがシステムにインストールされている場合は、次のコマンドを実行します。

    # dnf install tuned-utils

手順

  1. カスタムプロファイルを作成するには、次のコマンドを使用します。

    # powertop2tuned new_profile_name
  2. 新しいプロファイルをアクティベートします。

    # tuned-adm profile new_profile_name

関連情報

  • powertop2tuned に対応しているオプションの完全リストを表示するには、以下を使用します。

    $ powertop2tuned --help

11.6.4. powertop.service と powertop2tuned の比較

以下の理由により、powertop2tuned を使用した電力消費の最適化は、powertop.service よりも推奨されます。

  • powertop2tuned ユーティリティーは、PowerTOPTuneD に統合したものです。これにより、両方のツールの利点を活かすことができます。
  • powertop2tuned ユーティリティーを使用すると、有効になっているチューニングをきめ細かく制御できます。
  • powertop2tuned を使用すると、潜在的に危険なチューニングは自動的に有効になりません。
  • powertop2tuned を使用すると、再起動せずにロールバックを行うことができます。

第12章 perf の使用

システム管理者は、perf ツールを使用して、システムのパフォーマンスデータを収集および分析できます。

12.1. perf の概要

perf ユーザー空間ツールは、カーネルベースのサブシステム Performance Counters for Linux (PCL) とインターフェースします。perf は、Performance Monitoring Unit (PMU) を使用して、さまざまなハードウェアおよびソフトウェアイベントを測定、記録、および監視する強力なツールです。perf は、トレースポイント、kprobes、および uprobe もサポートします。

12.2. perf のインストール

この手順では、perf ユーザー空間ツールをインストールします。

手順

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

    # dnf install perf

12.3. 一般的な perf コマンド

本セクションでは、一般的に使用される perf コマンドの概要を説明します。

一般的に使用される 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ページが表示されます。

第13章 CPU 使用率を最適化するためのオペレーティングシステムの設定

本セクションでは、負荷全体で CPU 使用率を最適化するようにオペレーティングシステムを設定する方法を説明します。

13.1. プロセッサーの問題を監視および診断するためのツール

以下は、プロセッサー関連のパフォーマンス問題を監視および診断するために Red Hat Enterprise Linux 9 で利用可能なツールです。

  • turbostat ツールは、指定した間隔でカウンターの結果を出力し、過剰な電力使用量、ディープスリープ状態に入れない、システム管理割り込み (SMI) が不必要に作成されるなど、サーバーでの予期しない動作を特定するのに役立ちます。
  • numactl ユーティリティーはプロセッサーとメモリー親和性を管理する数多くのオプションを提供します。numactl パッケージには、カーネルがサポートする NUMA ポリシーに簡単なプログラミングインターフェースを提供する libnuma ライブラリーが含まれており、numactl アプリケーションよりも詳細なチューニングに使用できます。
  • numastat ツールは、オペレーティングシステムおよびそのプロセスについての NUMA ノードごとのメモリー統計を表示し、プロセスのメモリーがシステム全体に分散されているか、または特定のノードで集中化されているかを表示します。このツールは、numactl パッケージで提供されます。
  • numad は NUMA アフィニティーの自動管理デーモンです。NUMA リソースの割り当てと管理を動的に改善するために、システム内の NUMA トポロジーとリソースの使用状況を監視します。
  • /proc/interrupts ファイルには割り込み要求 (IRQ) 番号、システムの各プロセッサーによって処理される同様の割り込み要求の数、送信される割り込みのタイプ、および一覧表示される割り込み要求に応答するデバイスのコンマ区切りの一覧が表示されます。
  • pqos ユーティリティーは intel-cmt-cat パッケージで利用できます。最新の Intel プロセッサーで CPU キャッシュとメモリー帯域幅を監視します。以下を監視します。

    • サイクルごとの命令 (IPC)。
    • 最終レベルのキャッシュ MISSES の数。
    • LLC で特定の CPU で実行されるプログラムのサイズ (キロバイト単位)。
    • ローカルメモリーへの帯域幅 (MBL)。
    • リモートメモリー (MBR) への帯域幅。
  • X86_energy_perf_policy ツールを使用すると、パフォーマンスと電力消費効率の相対的な重要性を定義できます。この情報は、パフォーマンスと電力消費効率の間でトレードオフするオプションを選択すると、この機能をサポートするプロセッサーに影響を与えるために使用できます。
  • taskset ツールは、util-linux パッケージで提供されます。これにより、管理者は実行中のプロセスのプロセッサー親和性を取得および設定したり、指定されたプロセッサー親和性でプロセスを起動したりできます。

関連情報

  • turbostat(8)numactl(8)numastat(8)numa(7)numad(8)pqos(8)x86_energy_perf_policy(8)、および taskset(1) の man ページ

13.2. システムトポロジーの種類

現代のコンピューティングでは、ほとんどの最近のシステムに複数のプロセッサーがあるため、CPU の意図は誤解を招くものです。システムのトポロジーは、これらのプロセッサー同士が、他のシステムリソースに接続する方法です。これにより、システムおよびアプリケーションのパフォーマンスに影響を及ぼし、システムのチューニングの考慮事項が影響を受ける可能性があります。

現代のコンピューティングで使用されるトポロジーの主なタイプを以下に示します。

SMP ( symmetric Multi-Processor) トポロジー
SMP トポロジーにより、すべてのプロセッサーが同時にメモリーにアクセスできるようになります。ただし、共有および同等のメモリーアクセスは、本質的にすべての CPU からのメモリーアクセスをシリアライズするため、SMP システムのスケーリング制約が一般的に許容できないものとして表示されます。このため、最近のサーバーシステムはすべて NUMA マシンです。
NUMA (Non-Uniform Memory Access) の固定 (ピニング)

NUMA トポロジーは、SMP トポロジーよりも最近開発されました。NUMA システムでは、複数のプロセッサーが 1 つのソケット上で物理的にグループ化されます。各ソケットには、そのメモリーへのローカルアクセスを持つメモリーとプロセッサーの専用領域があります。これらは、すべてノードと呼ばれます。同じノード上のプロセッサーは、そのノードのメモリーバンクに高速でアクセスでき、ノード上にないメモリーバンクへの低速アクセスを提供します。

そのため、ローカル以外のメモリーにアクセスするとパフォーマンスが低下します。したがって、NUMA トポロジーを使用するシステム上のパフォーマンスに敏感なアプリケーションは、アプリケーションを実行するプロセッサーと同じノードにあるメモリーにアクセスする必要があり、可能な限りリモートメモリーにアクセスしないようにしてください。

パフォーマンスに敏感するマルチスレッドアプリケーションは、特定のプロセッサーではなく特定の NUMA ノードで実行されるように設定することで、メリットが得られます。これが適切なかどうかは、システムやアプリケーションの要件によって異なります。複数のアプリケーションスレッドが同じキャッシュされたデータにアクセスする場合、同じプロセッサーでこれらのスレッドを実行するように設定することが適切な場合があります。ただし、異なるデータにアクセスし、キャッシュする複数のスレッドが同じプロセッサーで実行される場合、各スレッドは、以前のスレッドによってアクセスされたキャッシュデータをエビクトする可能性があります。これは、各スレッドがキャッシュを失い、メモリーからデータをフェッチし、これをキャッシュで置き換えていることを意味します。perf ツールを使用して、過剰な数のキャッシュミスをチェックします。

13.2.1. システムトポロジーの表示

システムのトポロジーを理解するのに便利なコマンドは複数あります。この手順では、システムトポロジーを確認する方法を説明します。

手順

  • システムトポロジーの概要を表示するには、以下のコマンドを実行します。

    $ numactl --hardware
    available: 4 nodes (0-3)
    node 0 cpus: 0 4 8 12 16 20 24 28 32 36
    node 0 size: 65415 MB
    node 0 free: 43971 MB
    [...]
  • CPU 数、スレッド数、コア数、ソケット数、NUMA ノード数などの CPU アーキテクチャーに関する情報を収集するには、以下を実行します。

    $ lscpu
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                40
    On-line CPU(s) list:   0-39
    Thread(s) per core:    1
    Core(s) per socket:    10
    Socket(s):             4
    NUMA node(s):          4
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 47
    Model name:            Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
    Stepping:              2
    CPU MHz:               2394.204
    BogoMIPS:              4787.85
    Virtualization:        VT-x
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              256K
    L3 cache:              30720K
    NUMA node0 CPU(s):     0,4,8,12,16,20,24,28,32,36
    NUMA node1 CPU(s):     2,6,10,14,18,22,26,30,34,38
    NUMA node2 CPU(s):     1,5,9,13,17,21,25,29,33,37
    NUMA node3 CPU(s):     3,7,11,15,19,23,27,31,35,39
  • システムのグラフィカル表現を表示するには、以下のコマンドを実行します。

    # dnf install hwloc-gui
    # lstopo

    図13.1 lstopo の出力

    lstopo
  • 詳細なテキスト出力を表示するには、次のコマンドを実行します。

    # dnf install hwloc
    # lstopo-no-graphics
    Machine (15GB)
      Package L#0 + L3 L#0 (8192KB)
        L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
            PU L#0 (P#0)
            PU L#1 (P#4)
           HostBridge L#0
        PCI 8086:5917
            GPU L#0 "renderD128"
            GPU L#1 "controlD64"
            GPU L#2 "card0"
        PCIBridge
            PCI 8086:24fd
              Net L#3 "wlp61s0"
        PCIBridge
            PCI 8086:f1a6
        PCI 8086:15d7
            Net L#4 "enp0s31f6"

関連情報

  • numactl(8)lscpu(1)、および lstopo(1) の man ページ

13.3. カーネルティック時間の設定

デフォルトでは、Red Hat Enterprise Linux 9 はティックレスカーネルを使用します。これは、電力使用量を低減し、新しいプロセッサーがディープスリープ状態を利用できるようにするために、アイドル状態の CPU を中断しません。

Red Hat Enterprise Linux 9 には動的ティックレスオプションもあります。これは、高パフォーマンスコンピューティングやリアルタイムのコンピューティングなどのレイテンシーに制約のあるワークロードに役立ちます。デフォルトでは、動的ティックレスオプションは無効になっています。Red Hat は、cpu-partitioning TuneD プロファイルを使用して、isolated_cores で指定されたコアの動的な tickless オプションを有効にすることを推奨します。

この手順では、動的なティックレス動作を永続的に有効にする方法を説明します。

手順

  1. 特定のコアで動的なティックレス動作を有効にするには、nohz_full パラメーターを使用して、カーネルコマンドラインでこれらのコアを指定します。16 コアシステムでは、/etc/default/grub ファイルの GRUB_CMDLINE_LINUX オプションにこのパラメーターを追加します。

    nohz_full=1-15

    これにより、コア 1 から 15 までの動的なティックレス動作が有効になり、すべての時間管理が未指定のコアのみに移動します (コア 0)。

  2. 動的なティックレス動作を永続的に有効にするには、編集したデフォルトファイルを使用して GRUB2 設定を再生成します。BIOS ファームウェアがあるシステムで、次のコマンドを実行します。

    # grub2-mkconfig -o /etc/grub2.cfg

    UEFI ファームウェアがあるシステムで、次のコマンドを実行します。

    # grub2-mkconfig -o /etc/grub2-efi.cfg
  3. システムが起動したら、rcu スレッドをレイテンシーを区別しないコア (この場合は core 0) に手動で移動します。

    # for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; done
  4. オプション: カーネルコマンドラインで isolcpus パラメーターを使用して、特定のコアをユーザー空間タスクから分離します。
  5. オプション: カーネルの write-back bdi-flush スレッドの CPU 親和性をハウスキーピングコアに設定します。

    echo 1 > /sys/bus/workqueue/devices/writeback/cpumask

検証手順

  • システムを再起動したら、dynticks が有効になっていることを確認します。

    # journalctl -xe | grep dynticks
    Mar 15 18:34:54 rhel-server kernel: NO_HZ: Full dynticks CPUs: 1-15.
  • 動的ティックレス設定が正しく機能していることを確認します。

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3

    このコマンドは、CPU 1 に 3 秒間スリープするように指示しながら、CPU 1 のティックを測定します。

  • デフォルトのカーネルタイマーの設定では、通常の CPU で 3100 ティックが表示されます。

    # perf stat -C 0 -e irq_vectors:local_timer_entry taskset -c 0 sleep 3
    
     Performance counter stats for 'CPU(s) 0':
    
                 3,107      irq_vectors:local_timer_entry
    
           3.001342790 seconds time elapsed
  • 動的ティックレスカーネルを設定すると、代わりに 4 ティックが表示されるはずです。

    # perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 sleep 3
    
     Performance counter stats for 'CPU(s) 1':
    
                     4      irq_vectors:local_timer_entry
    
           3.001544078 seconds time elapsed

関連情報

13.4. 割り込み要求の概要

割り込み要求または IRQ は、ハードウェアの一部からプロセッサーに直ちに送信されるシグナルです。システム内の各デバイスには、固有の割り込みを送信できる IRQ 番号が割り当てられます。割り込みが有効になっていると、割り込み要求を受信するプロセッサーは割り込み要求に対応するために現在のアプリケーションスレッドの実行を即時に一時停止します。

割り込みは通常の動作を停止するため、割り込み率が高くなると、システムのパフォーマンスが大幅に低下する可能性があります。割り込みの親和性を設定するか、優先度の低い割り込みをバッチ (複数の割り込みをまとめる) に送信することで、割り込みにかかる時間を低減することができます。

割り込み要求には関連するアフィニティープロパティー smp_affinity があり、割り込み要求を処理するプロセッサーを定義します。アプリケーションのパフォーマンスを向上させるには、割り込みの親和性とプロセスの親和性を同じプロセッサーまたは同じコアにあるプロセッサーに割り当てます。これにより、指定された割り込みとアプリケーションスレッドがキャッシュラインを共有できるようになります。

割り込みステアリングに対応するシステムでは、割り込み要求の smp_affinity プロパティーを変更するとハードウェアが設定され、カーネルを介入することなくハードウェアレベルで特定のプロセッサーに割り込みを処理させる決定が行われるようになります。

13.4.1. 割り込みの手動分散

BIOS が NUMA トポロジーをエクスポートする場合、irqbalance サービスは、サービスを要求するハードウェアに対してローカルとなるノードで割り込み要求を自動的に処理できます。

手順

  1. 設定する割り込み要求に対応するデバイスを確認します。
  2. プラットフォームのハードウェア仕様を見つけます。システムのチップセットが割り込みの分散に対応しているかどうかを確認します。

    1. その場合には、以下の手順に従って割り込み配信を設定できます。また、チップセットが割り込みの分散に使用するアルゴリズムを確認してください。BIOS によっては割り込み配信を設定するオプションがあります。
    2. そうでない場合は、チップセットは常にすべての割り込みを単一の静的 CPU にルーティングします。使用される CPU を設定することはできません。
  3. システムでどの Advanced Programmable Interrupt Controller (APIC) モードが使用されているかを確認します。

    $ journalctl --dmesg | grep APIC

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

    • システムが flat 以外のモードを使用している場合は、「APIC ルーティングの物理フラットへの設定」と同様の行が表示されます。
    • このようなメッセージが表示されない場合は、システムが flat モードを使用します。

      システムで x2apic モードを使用している場合は、bootloader 設定のカーネルコマンドラインに nox2apic オプションを追加して無効にできます。

      物理以外のフラットモード (flat) のみが、複数の CPU への割り込みの分散をサポートします。このモードは、CPU が最大 8 のシステムでのみ利用できます。

  4. smp_affinity マスク を計算します。smp_affinity マスク の計算方法は、「 smp_affinity マスク の設定」を 参照してください。

関連情報

  • journalctl(1) および taskset(1) の man ページ

13.4.2. smp_affinity マスクの設定

smp_affinity の値は、システム内のすべてのプロセッサーを表す 16 進数のビットマスクとして保存されます。各ビットは異なる CPU を設定します。最も大きなビットは CPU 0 です。

マスクのデフォルト値は f で、割り込み要求をシステム内のどのプロセッサーでも処理できることを意味します。この値を 1 に設定すると、プロセッサー 0 のみが割り込みを処理できます。

手順

  1. バイナリーでは、割り込みを処理する CPU に 1 の値を使用します。たとえば、割り込みを処理する CPU 0 と CPU 7 を設定するには、バイナリーコードに 0000000010000001 を使用します。

    表13.1 CPU のバイナリービット

    CPU

    15

    14

    13

    12

    11

    10

    9

    8

    7

    6

    5

    4

    3

    2

    1

    0

    バイナリー

    0

    0

    0

    0

    0

    0

    0

    0

    1

    0

    0

    0

    0

    0

    0

    1

  2. バイナリーコードを 16 進数に変換します。

    たとえば、Python を使用してバイナリーコードを変換するには、次のコマンドを実行します。

    >>> hex(int('0000000010000001', 2))
    
    '0x81'

    プロセッサーが 32 個を超えるシステムでは、32 ビットグループごとに smp_affinity 値を区切る必要があります。たとえば、64 プロセッサーシステムの最初の 32 プロセッサーのみが割り込み要求を処理できるようにするには、0xffffffff,00000000 を使用します。

  3. 特定の割り込み要求の割り込み親和性の値は、関連付けられた /proc/irq/irq_number/smp_affinity ファイルに保存されます。このファイルで smp_affinity マスクを設定します。

    # echo mask > /proc/irq/irq_number/smp_affinity

関連情報

  • journalctl(1)irqbalance(1)、および taskset(1) の man ページ

第14章 スケジューリングポリシーの調整

Red Hat Enterprise Linux では、プロセス実行の最小単位はスレッドと呼ばれます。システムスケジューラーは、スレッドを実行するプロセッサーと、スレッドの実行期間を決定します。ただし、スケジューラーの主な懸念はシステムをビジーに維持することであるため、アプリケーションのパフォーマンスに対してスレッドを最適にスケジュールしない場合があります。

たとえば、NUMA システムのアプリケーションがノード A で実行され、ノード B のプロセッサーが利用可能になるとします。プロセッサーをノード B でビジー状態に維持するために、スケジューラーはアプリケーションのスレッドのいずれかをノード B に移動します。ただし、アプリケーションスレッドは依然としてノード A のメモリーにアクセスする必要があります。ただし、スレッドがノード B で実行され、ノード A のメモリーがスレッドに対してローカルにならないため、このメモリーへのアクセスには時間がかかります。そのため、スレッドがノード B での実行を終了するには、ノード A のプロセッサーが利用可能になるまで待機してから、ローカルメモリーアクセスで元のノードでスレッドを実行するよりも時間がかかる場合があります。

14.1. スケジューリングポリシーの分類

パフォーマンス重視のアプリケーションには、多くの場合、スレッドが実行される場所を決定する手段や管理者の恩恵を受けることができます。Linux スケジューラーは、スレッドの実行場所と実行期間を決定する複数のスケジューリングポリシーを実装します。

以下は、スケジューリングポリシーの主なカテゴリーです。

Normal policies
通常スレッドは、通常の優先度のタスクに使用されます。
Realtime policies

リアルタイムポリシーは、中断なしで完了する必要のある時間的制約のあるタスクに使用されます。リアルタイムスレッドは、タイムスライスの対象ではありません。つまり、スレッドは、ブロック、終了、展開、または優先度の高いスレッドによってプリエンプションされるまで実行されます。

最も優先度の低いリアルタイムスレッドは、通常のポリシーを持つスレッドの前にスケジュールされます。詳細は、「 SCHED_FIFO を使用した静的優先度スケジューリング」および「 SCHED_ RR を使用したラウンドロビン優先度スケジューリング 」を参照してください。

関連情報

  • sched(7)sched_setaffinity(2)sched_getaffinity(2)sched_setscheduler(2)、および sched_getscheduler(2) の man ページ

14.2. SCHED_FIFO を使用した静的優先度スケジューリング

SCHED_FIFO は静的優先度スケジューリングとも呼ばれ、各スレッドに固定の優先度を定義するリアルタイムポリシーです。このポリシーにより、管理者はイベントの応答時間を改善し、レイテンシーを短縮できます。このポリシーは、時間的制約のあるタスクについて長期間実行しないようにすることが推奨されます。

SCHED_FIFO が使用されている場合、スケジューラーは SCHED_FIFO の全スレッドの一覧を優先度順にスキャンし、実行準備ができているスレッドを最も優先度の高いものとしてスケジュールします。SCHED_FIFO スレッドの優先度レベルは、1 から 99 までの任意の整数にすることができます。ここで、99 は最も高い優先度として処理されます。Red Hat は、レイテンシーの問題を特定する場合にのみ、数値を減らし、優先度を増加させることを推奨します。

警告

リアルタイムスレッドはタイムスライスの影響を受けないため、Red Hat は優先度を 99 に設定しないことを推奨します。これにより、プロセスは移行およびウォッチドッグスレッドと同じ優先レベルを維持します。スレッドが演算ループに入り、これらのスレッドがブロックされると、実行できなくなります。単一のプロセッサーを持つシステムは、この状況では最終的にハングします。

管理者は、SCHED_FIFO 帯域幅を制限し、リアルタイムのアプリケーションプログラマーがプロセッサーを単調にするリアルタイムのタスクを開始できないようにすることができます。

以下は、このポリシーで使用されるパラメーターの一部です。

/proc/sys/kernel/sched_rt_period_us
このパラメーターは、プロセッサー帯域幅の 100 パーセントとみなされる期間 (マイクロ秒単位) を定義します。デフォルト値は 1000000 μs (1 秒) です。
/proc/sys/kernel/sched_rt_runtime_us
このパラメーターは、リアルタイムスレッドを実行する時間 (マイクロ秒単位) を定義します。デフォルト値は 950000 μs (0.95 秒) です。

14.3. SCHED_RR を使ったラウンドロビン優先度スケジューリング

SCHED_RR は、SCHED_FIFO のラウンドロビン型です。このポリシーは、複数のスレッドを同じ優先レベルで実行する必要がある場合に役に立ちます。

SCHED_FIFO と同様に、SCHED_RR は、各スレッドに固定の優先度を定義するリアルタイムポリシーです。スケジューラーは、すべての SCHED_RR スレッドの一覧を優先度順にスキャンし、実行準備ができているスレッドを最も優先度の高いものとしてスケジュールします。ただし、SCHED_FIFO とは異なり、優先順位が同じスレッドは、特定のタイムスライス内のラウンドロビンスタイルでスケジュールされます。

このタイムスライスの値は、/proc/sys/kernel/sched_rr_timeslice_ms ファイルの sched_rr_timeslice_ms カーネルパラメーターでミリ秒単位で設定できます。最小値は 1 millisecond です。

14.4. SCHED_OTHER を使った通常のスケジューリング

SCHED_OTHER は、Red Hat Enterprise Linux 9 のデフォルトスケジューリングポリシーです。このポリシーは Completely Fair Scheduler (CFS) を使用して、このポリシーでスケジュールされているすべてのスレッドへの公平プロセッサーアクセスを許可します。このポリシーは、スレッドが多数ある場合や、データスループットの優先度が優先される場合に最も便利です。これは、時間とともにスレッドをより効率的にスケジュールできるためです。

このポリシーが使用されると、スケジューラーは各プロセススレッドの niceness 値に基づいて動的な優先順位リストを作成します。管理者はプロセスの niceness 値を変更できますが、スケジューラーの動的優先順位の一覧を直接変更することはできません。

14.5. スケジューラーポリシーの設定

chrt コマンドラインツールを使用してスケジューラーポリシーおよび優先順位を確認し、調整します。これは、必要なプロパティーで新規プロセスを開始したり、実行中のプロセスのプロパティーを変更したりできます。また、ランタイム時にポリシーを設定するのにも使用できます。

手順

  1. アクティブなプロセスのプロセス ID (PID) を表示します。

    # ps

    ps コマンドで --pid または -p オプションを使用して、特定の PID の詳細を表示します。

  2. 特定のプロセスのスケジューリングポリシー、PID、および優先順位を確認します。

    # chrt -p 468
    pid 468's current scheduling policy: SCHED_FIFO
    pid 468's current scheduling priority: 85
    
    # chrt -p 476
    pid 476's current scheduling policy: SCHED_OTHER
    pid 476's current scheduling priority: 0

    ここで、468476 はプロセスの PID です。

  3. プロセスのスケジューリングポリシーを設定します。

    1. たとえば、PID 1000 のプロセスを、優先度が 50SCHED_FIFO に設定するには、以下を実行します。

      # chrt -f -p 50 1000
    2. たとえば、PID 1000 のプロセスを、優先度が 0SCHED_OTHER に設定するには、以下を実行します。

      # chrt -o -p 0 1000
    3. たとえば、PID 1000 のプロセスを、優先度が 10SCHED_RR に設定するには、以下を実行します。

      # chrt -r -p 10 1000
    4. 特定のポリシーおよび優先度で新規アプリケーションを開始するには、アプリケーションの名前を指定します。

      # chrt -f 36 /bin/my-app

14.6. chrt コマンドのポリシーオプション

chrtコマンドでは、プロセスのスケジューリングポリシーを表示および設定することができます。

次の表は、プロセスのスケジューリングポリシーを設定するために使用できる、適切なポリシーオプションについて説明しています。

表14.1 chrt コマンドのポリシーオプション

短いオプション長いオプション説明

-f

--fifo

スケジュールを SCHED_FIFO に設定

-o

--other

スケジュールを SCHED_OTHER に設定

-r

--rr

スケジュールを SCHED_RR に設定します。

14.7. ブートプロセス中のサービス優先度の変更

systemd サービスを使用すると、システムの起動プロセス中に起動したサービスに対して、リアルタイムの優先度を設定できます。ユニット設定ディレクティブ は、ブートプロセス中にサービスの優先度を変更するために使用されます。

ブートプロセスの優先度の変更は、service セクションの以下のディレクティブを使用して行われます。

CPUSchedulingPolicy=
実行したプロセスの CPU スケジューリングポリシーを設定します。これは、 のポリシー、fifo ポリシー、および rr ポリシーを設定するために使用されます。
CPUSchedulingPriority=
実行したプロセスの CPU スケジューリングの優先度を設定します。利用可能な優先度の範囲は、選択した CPU スケジューリングポリシーによって異なります。リアルタイムスケジューリングポリシーでは、1 (最も低い優先度) から 99 (最も高い優先度) までの整数を使用できます。

以下の手順では、ブートプロセス中に mcelog サービスを使用してサービスの優先度を変更する方法を説明します。

前提条件

  1. tuned パッケージをインストールしている。

    # dnf install tuned
  2. tuned サービスを有効にして起動している。

    # systemctl enable --now tuned

手順

  1. 実行中のスレッドのスケジュールの優先度を表示します。

    # tuna --show_threads
                          thread       ctxt_switches
        pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
      1      OTHER     0     0xff      3181          292         systemd
      2      OTHER     0     0xff       254            0        kthreadd
      3      OTHER     0     0xff         2            0          rcu_gp
      4      OTHER     0     0xff         2            0      rcu_par_gp
      6      OTHER     0        0         9            0 kworker/0:0H-kblockd
      7      OTHER     0     0xff      1301            1 kworker/u16:0-events_unbound
      8      OTHER     0     0xff         2            0    mm_percpu_wq
      9      OTHER     0        0       266            0     ksoftirqd/0
    [...]
  2. 補助の mcelog サービス設定ディレクトリーファイルを作成し、このファイルにポリシー名と優先度を挿入します。

    # cat <<-EOF > /etc/systemd/system/mcelog.system.d/priority.conf
    
    >
    [SERVICE]
    CPUSchedulingPolicy=_fifo_
    CPUSchedulingPriority=_20_
    EOF
  3. systemd スクリプト設定を再読み込みします。

    # systemctl daemon-reload
  4. mcelog サービスを再起動します。

    # systemctl restart mcelog

検証手順

  • systemd 問題で設定した mcelog 優先度を表示します。

    # tuna -t mcelog -P
    thread       ctxt_switches
      pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
    826     FIFO    20  0,1,2,3        13            0          mcelog

関連情報

14.8. 優先順位マップ

優先度はグループで定義され、特定のカーネル機能専用のグループもあります。リアルタイムスケジューリングポリシーでは、1 (最も低い優先度) から 99 (最も高い優先度) までの整数を使用できます。

次の表は、プロセスのスケジューリングポリシーを設定する際に使用できる優先度の範囲を示しています。

表14.2 優先度範囲の説明

優先度スレッド説明

1

優先度が低いカーネルスレッド

通常、この優先度は SCHED_OTHER を上回る必要があるタスク用に予約されます。

2 - 49

利用可能

標準的なアプリケーションの優先度に使用される範囲。

50

デフォルトの hard-IRQ 値

 

51 - 98

優先度の高いスレッド

この範囲は、定期的に実行されるスレッドと、迅速な応答時間に使用します。CPU にバインドされたスレッドには割り込みが必要になるため、この範囲を使用しないでください。

99

ウォッチドッグおよび移行

最も高い優先順位で実行される必要があるシステムスレッド。

14.9. TuneD cpu-partitioning プロファイル

レイテンシーに敏感なワークロード用に Red Hat Enterprise Linux 9 を調整する場合は、cpu-partitioning TuneD プロファイルを使用することが推奨されます。

Red Hat Enterprise Linux 9 以前では、低レイテンシーの Red Hat ドキュメントで、低レイテンシーのチューニングを実現するために必要な低レベルの手順が数多く説明されていました。Red Hat Enterprise Linux 9 では、cpu-partitioning TuneD プロファイルを使用することで、低レイテンシーのチューニングをより効率的に実行できます。このプロファイルは、個々の低レイテンシーアプリケーションの要件に従って簡単にカスタマイズできます。

以下の図は、cpu-partitioning プロファイルの使用方法を示す例になります。この例では、CPU とノードのレイアウトを使用します。

図14.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 ページ

14.10. 低レイテンシーチューニングへの TuneD の cpu-partitioning プロファイルの使用

この手順では、TuneD の cpu-partitioning プロファイルを使用して、低レイテンシーになるようにシステムをチューニングする方法を説明します。これは、cpu-partitioning の図で説明されているように、cpu-partitioning と CPU レイアウトを使用できる低レイテンシーのアプリケーションの例を使用します。

この場合のアプリケーションでは、以下を使用します。

  • ネットワークからデータを読み込む 1 つの専用リーダースレッドが、CPU 2 に固定されます。
  • このネットワークデータを処理する多数のスレッドは、CPU 4-23 に固定されます。
  • 処理されたデータをネットワークに書き込む専用のライタースレッドは、CPU 3 に固定されます。

前提条件

  • dnf install tuned-profiles-cpu-partitioning コマンドを root で使用して、cpu-partitioning TuneD プロファイルをインストールしている。

手順

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

    # Isolated CPUs with the kernel’s scheduler load balancing:
    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 ページ

14.11. 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 ページ

第15章 systemd を使用してアプリケーションが使用するリソースを管理する

RHEL 9 では、cgroup 階層のシステムを systemd ユニットツリーにバインドすることにより、リソース管理設定をプロセスレベルからアプリケーションレベルに移行します。したがって、システムリソースは、systemctl コマンドを使用するか、systemd ユニットファイルを変更して管理できます。

これを実現するために、systemd はユニットファイルから、または systemctl コマンドを介して直接さまざまな設定オプションを取得します。次に、systemd は、Linux カーネルシステムコールと cgroupsnamespaces などの機能を利用して、これらのオプションを特定のプロセスグループに適用します。

注記

次のマニュアルページで、systemd の設定オプションの完全なセットを確認できます。

  • systemd.resource-control(5)
  • systemd.exec(5)

15.1. systemd を使用したシステムリソースの割り当て

システムリソースの配分を変更するには、以下の配分モデルの 1 つまたは複数を適用できます。

重み

全サブグループの重みを合計し、各サブグループに、合計に対する重み比率に応じたリソースを配分します。

たとえば、10 個の cgroup があり、それぞれの重みが 100 の場合、合計は 1000 になります。各 cgroup は、リソースの 10 分の 1 を受け取ります。

重みは通常、ステートレスリソースの配分に使用されます。たとえば、CPUWeight= オプションは、このリソース配分モデルの実装です。

制限

cgroup は、設定された量のリソースを消費できます。サブグループ制限の合計は、親 cgroup の制限を超える可能性があります。したがって、このモデルではリソースをオーバーコミットする可能性があります。

たとえば、MemoryMax= オプションは、このリソース配分モデルの実装です。

保護

cgroup のリソースの保護された量を設定できます。リソースの使用状況が保護されるリソース量を下回る場合には、カーネルは、同じリソースを取得しようしている他の cgroup が優先されるように、この cgroup にペナルティーを課します。オーバーコミットも可能です。

たとえば、MemoryLow= オプションは、このリソース配分モデルの実装です。

割り当て
リソースに上限がある場合に、絶対量を特別に割り当てます。オーバーコミットはできません。Linux でこのリソースのタイプとして、リアルタイムの予算などが例として挙げられます。
ユニットファイルオプション

リソース制御設定の設定。

たとえば、CPUAccounting=CPUQuota= などのオプションを使用して CPU リソースを設定できます。同様に、AllowedMemoryNodes=IOAccounting= などのオプションを使用して、メモリーまたは I/O リソースを設定できます。

手順

サービスのユニットファイルオプションの必要な値を変更するには、ユニットファイルの値を調整するか、systemctl コマンドを使用します。

  1. 選択したサービスに割り当てられた値を確認してください。

    # systemctl show --property <unit file option> <service name>
  2. CPU 時間割り当てポリシーのオプションで必要な値を設定します。

    # systemctl set-property <service name> <unit file option>=<value>

検証手順

  • 選択したサービスに新しく割り当てられた値を確認してください。

    # systemctl show --property <unit file option> <service name>

関連情報

  • systemd.resource-control(5)systemd.exec(5) のマニュアルページ

15.2. リソース管理における systemd のロール

systemd のコア機能は、サービスの管理と監視です。systemd システムとサービスマネージャーは、マネージドサービスがブートプロセス中に適切なタイミングで正しい順序で開始されることを保証します。基盤となるハードウェアプラットフォームを最適に使用するには、サービスをスムーズに実行する必要があります。したがって、systemd には、リソース管理ポリシーの定義や、さまざまなオプションを調整する機能もあるので、サービスのパフォーマンスが改善されます。

重要

一般に、Red Hat では、システムリソースの使用を制御するために systemd を使用することをお勧めします。特別な場合にのみ、cgroups 仮想ファイルシステムを手動で設定する必要があります。たとえば、cgroup-v2 階層に同等のものがない cgroup-v1 コントローラーを使用する必要がある場合です。

15.3. cgroups の systemd 階層の概要

バックエンドでは、systemd システムおよびサービスマネージャーは、slice ユニット、scope ユニット、および service ユニットを使用して、コントロールグループ内のプロセスを整理および構造化します。カスタムユニットファイルを作成するか、systemctl コマンドを使用して、この階層をさらに変更できます。また、systemd は、重要なカーネルリソースコントローラーの階層を /sys/fs/cgroup/ ディレクトリーに自動的にマウントします。

systemd の 3 つのユニットタイプは、リソース制御に使用します。

  • Service - ユニット設定ファイルに従って systemd が起動したプロセスまたはプロセスのグループ。サービスは、指定したプロセスをカプセル化して、1 つのセットとして起動および停止できるようにします。サービスの名前は以下の方法で指定されます。

    <name>.service
  • スコープ - 外部で作成されたプロセスのグループ。スコープは、fork() 関数を介して任意のプロセスで開始および停止されたプロセスをカプセル化し、ランタイム時に systemd で登録します。たとえば、ユーザーセッション、コンテナー、および仮想マシンはスコープとして処理されます。スコープの名前は以下のように指定されます。

    <name>.scope
  • スライス - 階層的に編成されたユニットのグループ。スライスは、スコープおよびサービスを配置する階層を編成します。実際のプロセスはスコープまたはサービスに含まれます。スライスユニットの名前はすべて、階層内の場所へのパスに対応します。ハイフン (「-」) 文字は、-.slice ルートスライスからのスライスへのパスコンポーネントの区切り文字として機能します。以下の例では、下記の点を前提としています。

    <parent-name>.slice

    parent-name.slice は、parent.slice です。これは、-.slice root スライスのサブスライスです。parent-name.slice は、parent-name-name2.slice という名前の独自のサブスライスなどを持つことができます。

サービススコープスライス ユニットは、コントロールグループ階層のオブジェクトに直接マッピングされます。これらのユニットがアクティブになると、ユニット名から構築されるグループパスを制御するように直接マッピングされます。

以下は、コントロールグループ階層の省略形の例です。

Control group /:
-.slice
├─user.slice
│ ├─user-42.slice
│ │ ├─session-c1.scope
│ │ │ ├─ 967 gdm-session-worker [pam/gdm-launch-environment]
│ │ │ ├─1035 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1054 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -background none -noreset -keeptty -verbose 3
│ │ │ ├─1212 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
│ │ │ ├─1369 /usr/bin/gnome-shell
│ │ │ ├─1732 ibus-daemon --xim --panel disable
│ │ │ ├─1752 /usr/libexec/ibus-dconf
│ │ │ ├─1762 /usr/libexec/ibus-x11 --kill-daemon
│ │ │ ├─1912 /usr/libexec/gsd-xsettings
│ │ │ ├─1917 /usr/libexec/gsd-a11y-settings
│ │ │ ├─1920 /usr/libexec/gsd-clipboard
…​
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
└─system.slice
  ├─rngd.service
  │ └─800 /sbin/rngd -f
  ├─systemd-udevd.service
  │ └─659 /usr/lib/systemd/systemd-udevd
  ├─chronyd.service
  │ └─823 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─761 /sbin/auditd
  │ └─763 /usr/sbin/sedispatch
  ├─accounts-daemon.service
  │ └─876 /usr/libexec/accounts-daemon
  ├─example.service
  │ ├─ 929 /bin/bash /home/jdoe/example.sh
  │ └─4902 sleep 1
  …​

上記の例では、サービスおよびスコープにプロセスが含まれており、独自のプロセスを含まないスライスに置かれていることを示しています。

関連情報

15.4. Systemd ユニットの一覧表示

以下の手順では、systemd システムおよびサービスマネージャーを使用してユニットを一覧表示する方法を説明します。

手順

  • システム上のアクティブなユニットをすべて一覧表示するには、# systemctl コマンドを実行します。ターミナルでは、以下の例のような出力を返します。

    # systemctl
    UNIT                                                LOAD   ACTIVE SUB       DESCRIPTION
    …​
    init.scope                                          loaded active running   System and Service Manager
    session-2.scope                                     loaded active running   Session 2 of user jdoe
    abrt-ccpp.service                                   loaded active exited    Install ABRT coredump hook
    abrt-oops.service                                   loaded active running   ABRT kernel log watcher
    abrt-vmcore.service                                 loaded active exited    Harvest vmcores for ABRT
    abrt-xorg.service                                   loaded active running   ABRT Xorg log watcher
    …​
    -.slice                                             loaded active active    Root Slice
    machine.slice                                       loaded active active    Virtual Machine and Container Slice system-getty.slice                                                                       loaded active active    system-getty.slice
    system-lvm2\x2dpvscan.slice                         loaded active active    system-lvm2\x2dpvscan.slice
    system-sshd\x2dkeygen.slice                         loaded active active    system-sshd\x2dkeygen.slice
    system-systemd\x2dhibernate\x2dresume.slice         loaded active active    system-systemd\x2dhibernate\x2dresume>
    system-user\x2druntime\x2ddir.slice                 loaded active active    system-user\x2druntime\x2ddir.slice
    system.slice                                        loaded active active    System Slice
    user-1000.slice                                     loaded active active    User Slice of UID 1000
    user-42.slice                                       loaded active active    User Slice of UID 42
    user.slice                                          loaded active active    User and Session Slice
    …​
    • UNIT - コントロールグループ階層内のユニットの位置も反映するユニットの名前です。リソース制御に関連するユニットは、スライススコープ および サービス です。
    • LOAD - ユニット設定ファイルが正しく読み込まれたかどうかを示します。ユニットファイルの読み込みに失敗した場合には、フィールドの状態が loaded ではなく error になります。ユニットの読み込みの状態は他に stub, merged, and masked などがあります。
    • ACTIVE - ユニットのアクティベーションの状態 (概要レベル)。こちらは SUB の概要レベルの状態です。
    • SUB - ユニットのアクティベーションの状態 (詳細レベル)。許容値の範囲は、ユニットタイプによって異なります。
    • DESCRIPTION - ユニットのコンテンツおよび機能の説明。
  • アクティブではないユニットを一覧表示するには、次のコマンドを実行します。

    # systemctl --all
  • 出力の情報量を制限するには、以下を実行します。

    # systemctl --type service,masked

    --type オプションでは、サービス および スライス などのユニットタイプのコンマ区切りの一覧、または 読み込み済みマスク済み などのユニットの読み込み状態が必要です。

関連情報

15.5. systemd コントロールグループ階層の表示

以下の手順では、特定の cgroups で実行しているコントロールグループ (cgroups) 階層およびプロセスを表示する方法を説明します。

手順

  • システムの cgroups 階層全体を表示するには、# systemd-cgls を実行します。

    # systemd-cgls
    Control group /:
    -.slice
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    │ │ │ ├─1040 /usr/libexec/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
    …​
    ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    └─system.slice
      …​
      ├─example.service
      │ ├─6882 /bin/bash /home/jdoe/example.sh
      │ └─6902 sleep 1
      ├─systemd-journald.service
        └─629 /usr/lib/systemd/systemd-journald
      …​

    この出力例では cgroups 階層全体を返します。この海藻は、slices で形成される最も高いレベルです。

  • cgroups 階層を、リソースコントローラー別にフィルタリングして表示するには、# systemd-cgls <resource_controller> を実行します。

    # systemd-cgls memory
    Controller memory; Control group /:
    ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
    ├─user.slice
    │ ├─user-42.slice
    │ │ ├─session-c1.scope
    │ │ │ ├─ 965 gdm-session-worker [pam/gdm-launch-environment]
    …​
    └─system.slice
      |
      …​
      ├─chronyd.service
      │ └─844 /usr/sbin/chronyd
      ├─example.service
      │ ├─8914 /bin/bash /home/jdoe/example.sh
      │ └─8916 sleep 1
      …​

    上記のコマンドの出力例では、選択したコントローラーと対話するサービスの一覧を表示します。

  • 特定のユニットと cgroups 階層の一部に関する詳細情報を表示するには、# systemctl status <system_unit> を実行します。

    # systemctl status example.service
    ● example.service - My example service
       Loaded: loaded (/usr/lib/systemd/system/example.service; enabled; vendor preset: disabled)
       Active: active (running) since Tue 2019-04-16 12:12:39 CEST; 3s ago
     Main PID: 17737 (bash)
        Tasks: 2 (limit: 11522)
       Memory: 496.0K (limit: 1.5M)
       CGroup: /system.slice/example.service
               ├─17737 /bin/bash /home/jdoe/example.sh
               └─17743 sleep 1
    Apr 16 12:12:39 redhat systemd[1]: Started My example service.
    Apr 16 12:12:39 redhat bash[17737]: The current time is Tue Apr 16 12:12:39 CEST 2019
    Apr 16 12:12:40 redhat bash[17737]: The current time is Tue Apr 16 12:12:40 CEST 2019

関連情報

15.6. プロセスの cgroup の表示

次の手順では、プロセスが属する control group (cgroup) を学習する方法について説明します。次に、cgroup をチェックして、使用するコントローラーとコントローラー固有の設定を確認できます。

手順

  1. プロセスが属する cgroup を表示するには、# cat proc/<PID>/cgroup コマンドを実行します。

    # cat /proc/2467/cgroup
    0::/system.slice/example.service

    この出力例は、対象のプロセスに関するものです。今回の例では、example.service ユニットに属する PID 2467 で識別されるプロセスです。systemd ユニットファイルの仕様で定義されているように、適切なコントロールグループにプロセスが置かれているかどうかを判断できます。

  2. cgroup が使用するコントローラーとそれぞれの設定ファイルを表示するには、cgroup ディレクトリーを確認します。

    # cat /sys/fs/cgroup/system.slice/example.service/cgroup.controllers
    memory pids
    
    # ls /sys/fs/cgroup/system.slice/example.service/
    cgroup.controllers
    cgroup.events
    …​
    cpu.pressure
    cpu.stat
    io.pressure
    memory.current
    memory.events
    …​
    pids.current
    pids.events
    pids.max
注記

cgroups のバージョン 1 階層は、コントローラーごとのモデルを使用します。したがって、/proc/PID/cgroup ファイルからの出力には、PID が属する各コントローラーの下の cgroups が表示されます。それぞれの cgroups は、/sys/fs/cgroup/<controller_name>/ のコントローラーディレクトリーにあります。

関連情報

15.7. リソース消費の監視

以下の手順では、現在実行中のコントロールグループ (cgroup) とそのリソース消費の一覧をリアルタイムで表示する方法を説明します。

手順

  1. 現在実行中の cgroups の動的アカウントを表示するには、# systemd-cgtop コマンドを実行します。

    # systemd-cgtop
    Control Group                            Tasks   %CPU   Memory  Input/s Output/s
    /                                          607   29.8     1.5G        -        -
    /system.slice                              125      -   428.7M        -        -
    /system.slice/ModemManager.service           3      -     8.6M        -        -
    /system.slice/NetworkManager.service         3      -    12.8M        -        -
    /system.slice/accounts-daemon.service        3      -     1.8M        -        -
    /system.slice/boot.mount                     -      -    48.0K        -        -
    /system.slice/chronyd.service                1      -     2.0M        -        -
    /system.slice/cockpit.socket                 -      -     1.3M        -        -
    /system.slice/colord.service                 3      -     3.5M        -        -
    /system.slice/crond.service                  1      -     1.8M        -        -
    /system.slice/cups.service                   1      -     3.1M        -        -
    /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
    /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
    /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
    /system.slice/example.service                2      -     2.0M        -        -
    /system.slice/firewalld.service              2      -    28.8M        -        -
    ...

    この出力例では、現在実行中の cgroups が、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) 別に表示されています。デフォルトでは 1 秒ごとに一覧が更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況について動的な見解が得られるようになります。

関連情報

  • systemd-cgtop(1) manual page

15.8. systemd ユニットファイルを使用してアプリケーションの制限を設定する

既存または実行中の各ユニットは systemd によって監視され、systemd はそれらのコントロールグループも作成します。ユニットの設定ファイルは /usr/lib/systemd/system/ ディレクトリーにあります。ユニットファイルを手動で変更して、プロセスのグループのハードウェアリソースへの制限を設定したり、優先順位を付けたり、アクセスを制御したりできます。

前提条件

  • root 権限があります。

手順

  1. /usr/lib/systemd/system/example.service ファイルを変更して、サービスのメモリー使用量を制限します。

    …
    [Service]
    MemoryMax=1500K
    …

    上記の設定では、コントロールグループ内のプロセスが超えることのできない最大メモリー制限が設定されています。example.service サービスは、このようなコントロールグループの一部であり、制限を課せられています。測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用できます。

  2. すべてのユニット設定ファイルを再読み込みします。

    # systemctl daemon-reload
  3. サービスを再起動します。

    # systemctl restart example.service
注記

次のマニュアルページで、systemd の設定オプションの完全なセットを確認できます。

  • systemd.resource-control(5)
  • systemd.exec(5)

検証

  1. 変更が有効になったことを確認します。

    # cat /sys/fs/cgroup/system.slice/example.service/memory.max
    1536000

    この出力例は、メモリー消費が約 1,500 KB に制限されていることを示しています。

関連情報

15.9. systemctl コマンドを使用してアプリケーションに制限を設定する

CPU アフィニティーの設定は、特定のプロセスにアクセスできる CPU を一部だけに制限する場合に役立ちます。実際には、CPU スケジューラーでは、プロセスのアフィニティーマスク上にない CPU で実行するプロセスはスケジューリングされません。

デフォルトの CPU アフィニティーマスクは、systemd が管理するすべてのサービスに適用されます。

特定の systemd サービスの CPU アフィニティーマスクを設定するには、systemd/etc/systemd/system.conf でユニットファイルオプションとマネージャー設定オプション両方として CPUAffinity= を指定します。

CPUAffinity= ユニットファイルのオプション では、CPU または CPU 範囲の一覧を設定し、アフィニティーマスクとしてマージして使用されます。

特定の systemd サービスの CPU アフィニティーマスクを設定したら、サービスを再起動して変更を適用する必要があります。

手順

CPUAffinity unit file オプションを使用して特定の systemd サービスの CPU アフィニティーマスクを設定するには以下を実行します。

  1. 選択したサービスで CPUAffinity ユニットファイルオプションの値を確認します。

    $ systemctl show --property <CPU affinity configuration option> <service name>
  2. root として、アフィニティーマスクとして使用する CPU 範囲の CPUAffinity ユニットファイルで必要な値を設定します。

    # systemctl set-property <service name> CPUAffinity=<value>
  3. サービスを再起動して変更を適用します。

    # systemctl restart <service name>
注記

次のマニュアルページで、systemd の設定オプションの完全なセットを確認できます。

  • systemd.resource-control(5)
  • systemd.exec(5)

15.10. マネージャー設定によるグローバルなデフォルトの CPU アフィニティーの設定

/etc/systemd/system.conf ファイルの CPUAffinity オプション は、プロセス ID 番号 (PID) 1 と、PID1 でフォークされた全プロセスにアフィニティーマスクを定義します。これにより、各サービスで CPUAffinity を上書きできます。

manager configuration オプションを使用して、すべての systemd サービスにデフォルトの CPU アフィニティーマスクを設定するには、次の手順に従います。

  1. /etc/systemd/system.conf ファイルの CPUAffinity= オプションの CPU 番号を設定します。
  2. 編集したファイルを保存し、systemd サービスをリロードします。

    # systemctl daemon-reload
  3. サーバーを再起動して、変更を適用します。
注記

次のマニュアルページで、systemd の設定オプションの完全なセットを確認できます。

  • systemd.resource-control(5)
  • systemd.exec(5)

15.11. systemd を使用した NUMA ポリシーの設定

Non-Uniform Memory Access (NUMA) は、コンピューターメモリーのサブシステム設計で、この設計ではメモリーのアクセス時間は、プロセッサーからの物理メモリーの場所により異なります。

CPU に近いメモリーは、別の CPU のローカルにあるメモリーや、一連の CPU 間で共有されているメモリーと比べ、レイテンシーが低くなっています (外部メモリー)。

Linux カーネルでは、NUMA ポリシーを使用して、カーネルがプロセス用に物理メモリーを割り当てる場所 (例: NUMA ノード) を制御します。

systemd は、サービスのメモリー割り当てポリシーを制御するためのユニットファイルオプション NUMAPolicy および NUMAMask を提供します。

手順

NUMAPolicy ユニットファイル オプションで NUMA メモリーポリシーを設定するには以下を実行します。

  1. 選択したサービスで NUMAPolicy ユニットファイルオプションの値を確認します。

    $ systemctl show --property <NUMA policy configuration option> <service name>
  2. root として、NUMAPolicy ユニットファイルオプションに必要なポリシータイプを設定します。

    # systemctl set-property <service name> NUMAPolicy=<value>
  3. サービスを再起動して変更を適用します。

    # systemctl restart <service name>

manager configuration オプションを使用してグローバルな NUMAPolicy を設定するには、次のようにします。

  1. /etc/systemd/system.conf ファイルで NUMAPolicy オプションを検索します。
  2. ポリシータイプを編集してファイルを保存します。
  3. systemd 設定をリロードします。

    # systemd daemon-reload
  4. サーバーを再起動します。
重要

bind などの厳密な NUMA ポリシーを設定する場合は、CPUAffinity= ユニットファイルオプションも適切に設定されていることを確認してください。

関連情報

15.12. systemd の NUMA ポリシー設定オプション

Systemd で以下のオプションを指定して、NUMA ポリシーを設定します。

NUMAPolicy

実行したプロセスの NUMA メモリーポリシーを制御します。以下のポリシー種別を使用できます。

  • default
  • preferred
  • bind
  • interleave
  • local
NUMAMask

選択した NUMA ポリシーに関連付けられた NUMA ノード一覧を制御します。

NUMAmask オプションは、以下のポリシーに指定する必要はありません。

  • default
  • local

優先ポリシーの場合、この一覧で指定できるのは単一の NUMA ノードのみです。

関連情報

  • systemd.resource-control(5)systemd.exec(5)、および set_mempolicy(2) の man ページ

15.13. systemd-run コマンドを使用した一時的な cgroup の作成

一時的な cgroups は、ランタイム時にユニット (サービスまたはスコープ) が消費するリソースに制限を設定します。

手順

  • 一時的なコントロールグループを作成するには、以下の形式で systemd-run コマンドを使用します。

    # systemd-run --unit=<name> --slice=<name>.slice <command>

    このコマンドは、一時的なサービスまたはスコープユニットを作成し、開始し、そのユニットでカスタムコマンドを実行します。

    • --unit=<name> オプションは、ユニットに名前を指定します。--unit が指定されていないと、名前は自動的に生成されます。
    • --slice=<name>.slice オプションは、サービスまたはスコープユニットを指定のスライスのメンバーにします。<name>.slice は、既存のスライスの名前 (systemctl -t slice の出力に表示) に置き換えるか、または一意の名前を指定して新規スライスを作成します。デフォルトでは、サービスおよびスコープは system.slice のメンバーとして作成されます。
    • <command> は、サービスまたはスコープユニットで実行するコマンドに置き換えます。

      以下のような、サービスまたはスコープが正常に作成され開始したことを確認するメッセージが表示されます。

      # Running as unit <name>.service
  • 必要に応じて、ランタイム情報を収集するため、プロセスが終了した後もユニットを実行したままにします。

    # systemd-run --unit=<name> --slice=<name>.slice --remain-after-exit <command>

    コマンドは、一時的なサービスユニットを作成して開始し、そのユニットでカスタムコマンドを実行します。--remain-after-exit オプションを使用すると、プロセスの終了後もサービスが実行し続けます。

関連情報

15.14. 一時的なコントロールグループの削除

systemd システムおよびサービスマネージャーを使用して、プロセスのグループのハードウェアリソースへのアクセスを制限して優先順位を付け、制御する必要がなくなった場合に、一時的なコントロールグループ (cgroup) を削除できます。

一時的な cgroups は、サービスまたはスコープユニットに含まれる全プロセスが完了すると、自動的に解放されます、

手順

  • すべてのプロセスでサービスユニットを停止するには、以下のコマンドを実行します。

    # systemctl stop name.service
  • ユニットプロセスを 1 つ以上終了するには、以下を実行します。

    # systemctl kill name.service --kill-who=PID,... --signal=<signal>

    上記のコマンドは、--kill-who オプションを使用して、終了するコントロールグループからプロセスを選択します。複数のプロセスを同時に強制終了するには、PID のコンマ区切りの一覧を指定します。--signal オプションは、指定されたプロセスに送信する POSIX シグナルのタイプを決定します。デフォルトのシグナルは SIGTERM です。

第16章 cgroups を理解する

コントロールグループ (cgroup) のカーネル機能を使用して、プロセスのハードウェアリソースの制限や優先順位を設定したりまたは分離できます。これにより、アプリケーションのリソース使用状況をより詳細に制御して、効率的に使用できます。

16.1. コントロールグループについて

コントロールグループは、プロセスを階層的に順序付けされた cgroups グループに編成できる Linux カーネル機能です。階層 (コントロールグループツリー) は、cgroups 仮想ファイルシステムに構造を提供して定義されます。デフォルトでは /sys/fs/cgroup ディレクトリーにマウントされます。systemd システムとサービスマネージャーは、cgroups を利用して、それが管理するすべてのユニットとサービスを組織化します。または、/sys/fs/cgroup/ ディレクトリーでサブディレクトリーを作成および削除することにより、cgroups 階層を手動で管理できます。

リソースコントローラー (カーネルコンポーネント) は、これらのプロセスのシステムリソース (CPU 時間、メモリー、ネットワーク帯域幅、各種組み合わせなど) を制限、優先順位付け、または割り当てることで cgroup 内のプロセスの動作を変更します。

cgroups に追加された値はプロセスアグリゲーションで、アプリケーションとユーザー間のハードウェアリソースの分割を可能にします。その結果、ユーザー環境の全体的な効率、安定性、およびセキュリティーが向上します。

コントロールグループ 1

コントロールグループバージョン 1 (cgroups-v1) はリソースごとのコントローラー階層を提供します。これは、CPU、メモリー、I/O などの各リソースに、独自のコントロールグループ階層があることを意味します。あるコントローラーが、各リソースの管理において別のものと連携できるように、別のコントロールグループ階層を組み合わせることができます。ただし、2 つのコントローラーは異なるプロセス階層に属する可能性があり、適切な調整はできません。

cgroups-v1 コントローラーは、長期間に渡って開発されているため、制御ファイルの動作と命名は均一ではありません。

コントロールグループ 2

階層の柔軟性から生じるコントローラー連携の問題は、control groups version 2 の発展につながっていました。

Control groups version 2 (cgroups-v2) では、すべてのリソースコントロールがマウントされることに対して単一のコントロールグループ階層を指定します。

コントロールファイルの動作と命名は、さまざまなコントローラーにおいて一貫性があります。

重要

RHEL 9 は、デフォルトで cgroups-v2 をマウントして利用します。

このサブセクションは、Devconf.cz 2019 プレゼンテーションにを基にしています。[2]

16.2. Linux カーネルリソースコントローラーとは

コントロールグループの機能は、カーネルリソースコントローラーで有効化します。RHEL 9 は、コントロールグループバージョン 1 (cgroups-v1) および コントロールグループバージョン 2 (cgroups-v2) のさまざまなコントローラーをサポートします。

コントロールグループサブシステムとも呼ばれるリソースコントローラーは、1 つのリソース (CPU 時間、メモリー、ネットワーク帯域幅、ディスク I/O など)を表すカーネルサブシステムです。Linux カーネルは、systemd システムおよびサービスマネージャーが自動的にマウントされるリソースコントローラーの範囲を指定します。/proc/cgroups エントリーで現在マウントされているリソースコントローラーの一覧を検索します。

cgroups-v1 では、以下のコントローラーを使用できます。

  • blkio - ブロックデバイスへの入出力アクセスに制限を設定できます。
  • cpu - コントロールグループのタスクに対して、Completely Fair Scheduler (CFS) スケジューラーのパラメーターを調整できます。これは、同じマウントで cpuacct コントローラーとともにマウントされます。
  • cpuacct - コントロールグループ内のタスクが使用する CPU リソースに関する自動レポートを作成します。これは、同じマウント上の cpu コントローラーとともにマウントされます。
  • cpuset - コントロールグループタスクが CPU の特定のサブセットでのみ実行されるように制限したり、指定メモリーノードでのみメモリーを使用できるようにタスクに指示したりできます。
  • デバイス - コントロールグループのタスクに関してデバイスへのアクセスを制御できます。
  • freezer - コントロールグループのタスクを一時停止または再開するのに使用できます。
  • memory - コントロールグループ内のタスクでメモリー使用を設定し、そのタスクによって使用されるメモリーリソースに関する自動レポートを生成するのに使用できます。
  • net_cls - 特定のコントロールグループタスクから発信されたパケットを識別できるようにするために Linux トラフィックコントローラー (tc コマンド) を有効にするクラス識別子 (classic) でネットワークパケットをタグ付けします。net_cls のサブシステム net_ filter (iptables) でも、このタグを使用して、そのようなパケットに対するアクションを実行することができます。net_filter は、ファイアウォール識別子 (fwid) でネットワークソケットをタグ付けします。これにより、(iptables コマンドで) Linux ファイアウォールが、特定のコントールグループタスクから発信されたパケットを識別できるようになります。
  • net_prio - ネットワークトラフィックの優先度を設定します。
  • pids - コントロールグループ内の多数のプロセスと子に制限を設定できます。
  • perf_event - perf パフォーマンス監視およびレポートユーティリティーにより、監視するタスクをグループ化できます。
  • rdma - コントロールグループ内のリモートダイレクトメモリーアクセス/InfiniB 固有のリソースに制限を設定できます。
  • hugetlb - コントロールグループ内のタスクで大容量の仮想メモリーページの使用を制限するのに使用できます。

cgroups-v2 では、次のモードを使用できます。

  • io - cgroups-v1blkio へのフォローアップ
  • memory - cgroups-v1メモリー へのフォローアップ
  • pids - cgroups-v1pids と同じ
  • RDMA - cgroups-v1rdma と同じ
  • cpu - cpu - cgroups-v1cpucpuacct へのフォローアップ
  • cpuset - コア機能 (cpus{,.effective}, mems{,.effective}) のみを新しいパーティション機能でサポートします。
  • perf_event - サポートは継承され、明示的な制御ファイルはありません。perf コマンドに v2 cgroup をパラメーターとして指定でき、対象の cgroup 内のタスクすべてがプロファイリングされます。
重要

リソースコントローラーは、cgroups-v1 階層または cgroups-v 2 階層のいずれかで使用できますが、両方を同時に使用することはできません。

関連情報

  • cgroups(7) の man ページ
  • /usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ ディレクトリー内のドキュメント (kernel-doc パッケージをインストールした後)。

16.3. 名前空間とは

名前空間は、ソフトウェアオブジェクトを整理および特定するための最も重要な方法の 1 つです。

名前空間は、グローバルシステムリソース (マウントポイント、ネットワークデバイス、ホスト名など) を抽象化してラップすることで、グローバルリソースごとに分離されたインスタンスを含む対象の名前空間にプロセスを表示させることができます。名前空間を使用する最も一般的なテクノロジーの 1 つとしてコンテナーが挙げられます。

特定のグローバルリソースへの変更は、その名前空間のプロセスにのみ表示され、残りのシステムまたは他の名前空間には影響しません。

プロセスがどの名前空間に所属するかを確認するには、/proc/<PID>/ns/ ディレクトリーのシンボリックリンクを確認します。

以下の表は、分離されるサポート対象の名前空間およびリソースを示しています。

名前空間分離

Mount

マウントポイント

UTS

ホスト名および NIS ドメイン名

IPC

System V IPC、POSIX メッセージキュー

PID

プロセス ID

Network

ネットワークデバイス、スタック、ポートなど。

User

ユーザーおよびグループ ID

Control groups

コントロールグループの root ディレクトリー

関連情報



[2] Linux Control Group v2 - An Introduction, Devconf.cz 2019 presentation by Waiman Long

第17章 zswap を使用したシステムパフォーマンスの向上

zswap カーネル機能を有効にすることで、システムパフォーマンスを向上させることができます。

17.1. zswap とは

このセクションでは、zswap の概要と、システムパフォーマンスを改善する方法を説明します。

zswap は、swap ページの圧縮 RAM キャッシュを提供するカーネル機能です。このメカニズムは以下のように動作します。zswap は、スワップアウトされているプロセスにあるページを取得し、動的に割り当てられた RAM ベースのメモリープールに圧縮を試みます。プールが満杯になると、zswap は LRU ベースで圧縮されたキャッシュからバッキングスワップデバイスにページをエビクトします。ページをスワップキャッシュに展開した後、zswap はプールの圧縮バージョンを解放します。

zswapの利点
  • 重要な I/O の削減
  • ワークロードパフォーマンスの大幅な改善

Red Hat Enterprise Linux 9 では、zswap はデフォルトで有効になります。

関連情報

17.2. ランタイム時の zswap の有効化

sysfs インターフェースを使用すると、システム実行時に zswap 機能を有効にできます。

前提条件

  • root 権限がある。

手順

  • zswap を有効にします。

    # echo 1 > /sys/module/zswap/parameters/enabled

検証手順

  • zswap が有効になっていることを確認します。

    # grep -r . /sys/kernel/debug/zswap
    
    duplicate_entry:0
    pool_limit_hit:13422200
    pool_total_size:6184960 (pool size in total in pages)
    reject_alloc_fail:5
    reject_compress_poor:0
    reject_kmemcache_fail:0
    reject_reclaim_fail:13422200
    stored_pages:4251 (pool size after compression)
    written_back_pages:0

17.3. zswap の永続的な有効化

zswap 機能は、zswap.enabled=1 カーネルコマンドラインパラメーターを指定して、永続的に有効にできます。

前提条件

  • root 権限がある。
  • grubby ユーティリティーまたは zipl ユーティリティーがシステムにインストールされている。

手順

  1. zswap を永続的に有効にします。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="zswap.enabled=1"
  2. システムを再起動して、変更を有効にします。

検証手順

  • zswap が有効になっていることを確認します。

    # cat /proc/cmdline
    
    BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-70.5.1.el9_0.x86_64
    root=/dev/mapper/rhel-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M
    resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root
    rd.lvm.lv=rhel/swap rhgb quiet
    zswap.enabled=1

第18章 cgroupfs を使用して cgroup を手動で管理する

cgroupfs 仮想ファイルシステムにディレクトリーを作成することにより、システム上の cgroup 階層を管理できます。ファイルシステムはデフォルトで /sys/fs/cgroup/ ディレクトリーにマウントされ、専用の制御ファイルで必要な設定を指定できます。

重要

一般に、Red Hat では、システムリソースの使用を制御するために systemd を使用することをお勧めします。特別な場合にのみ、cgroups 仮想ファイルシステムを手動で設定する必要があります。たとえば、cgroup-v2 階層に同等のものがない cgroup-v1 コントローラーを使用する必要がある場合です。

18.1. cgroups-v2 ファイルシステムでの cgroup の作成とコントローラーの有効化

ディレクトリーを作成または削除したり、cgroups 仮想ファイルシステム内のファイルに書き込んだりすることで、control groups (cgroups) を管理できます。ファイルシステムは、デフォルトで /sys/fs/cgroup/ ディレクトリーにマウントされます。cgroups コントローラーの設定を使用するには、子 cgroups に対して目的のコントローラーを有効にする必要もあります。ルート cgroup は、デフォルトで、その子 cgroupsmemory および pids コントローラーを有効にしました。したがって、Red Hat は、/sys/fs/cgroup/ ルート cgroup 内に少なくとも 2 つのレベルの子 cgroups を作成することをお勧めします。このようにして、オプションで子 cgroups から memorypids コントローラーを削除し、cgroup ファイルの組織の明確さを維持します。

前提条件

  • root 権限がある。

手順

  1. /sys/fs/cgroup/Example/ ディレクトリーを作成します。

    # mkdir /sys/fs/cgroup/Example/

    /sys/fs/cgroup/Example/ ディレクトリーはサブグループを定義します。/sys/fs/cgroup/Example/ ディレクトリーを作成すると、一部の cgroups-v2 インターフェイスファイルがディレクトリーに自動的に作成されます。/sys/fs/cgroup/Example/ ディレクトリーには、memory および pids コントローラー用のコントローラー固有のファイルも含まれます。

  2. 必要に応じて、新たに作成されたサブコントロールグループを確認します。

    # ll /sys/fs/cgroup/Example/
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.controllers
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 cgroup.events
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.freeze
    -rw-r—r--. 1 root root 0 Jun  1 10:33 cgroup.procs
    …​
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 cgroup.subtree_control
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 memory.events.local
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.high
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 memory.low
    …​
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.current
    -r—​r—​r--. 1 root root 0 Jun  1 10:33 pids.events
    -rw-r—​r--. 1 root root 0 Jun  1 10:33 pids.max

    出力例は、cgroup.procscgroup.controllers などの一般的な cgroup 制御インターフェイスファイルを示しています。これらのファイルは、有効なコントローラーに関係なく、すべてのコントロールグループに共通です。

    memory.high および pids.max などのファイルは、memory および pids コントローラーに関連し、ルートコントロールグループ(/sys/fs/cgroup/)にあり、systemd によってデフォルトで有効になります。

    デフォルトでは、新しく作成された子グループは、親 cgroup からすべての設定を継承します。この場合、ルート cgroup からの制限はありません。

  3. 目的のコントローラーが /sys/fs/cgroup/cgroup.controllers ファイルで使用可能であることを確認します。

    # cat /sys/fs/cgroup/cgroup.controllers
    cpuset cpu io memory hugetlb pids rdma
  4. 目的のコントローラーを有効にします。この例では、cpu および cpuset コントローラーです。

    # echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control
    # echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control

    これらのコマンドにより、/sys/fs/cgroup/ ルートコントロールグループ直下のサブグループに対して cpu および cpuset コントローラーが有効になります。新しく作成された Example コントロールグループを含みます。サブグループ で指定した各プロセスに対して、基準に基づいてコントロールチェックを適用できます。

    ユーザーは任意のレベルの cgroup.subtree_control ファイルの内容を読み取り、直下のサブグループで有効にするコントローラーについて把握することができます。

    注記

    デフォルトでは、ルートコントロールグループの /sys/fs/cgroup/cgroup.subtree_control ファイルには memorypids コントローラーが含まれます。

  5. Example コントロールグループの子 cgroups に必要なコントローラーを有効にします。

    # echo "+cpu +cpuset" >> /sys/fs/cgroup/Example/cgroup.subtree_control

    このコマンドにより、直下のサブコントロールグループに、(memory または pidsコントローラーではなく) CPU 時間の配分の調整に関係するコントローラー だけが設定されるようになります。

  6. /sys/fs/cgroup/Example/tasks/ ディレクトリーを作成します。

    # mkdir /sys/fs/cgroup/Example/tasks/

    /sys/fs/cgroup/Example/tasks/ ディレクトリーは、cpu および cpuset コントローラーにのみ関連するファイルを持つサブグループを定義します。これで、このコントロールグループにプロセスを割り当て、プロセスに cpu および cpuset コントローラーオプションを利用できます。

  7. 必要に応じて、子コントロールグループを検査します。

    # ll /sys/fs/cgroup/Example/tasks
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.controllers
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.events
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.freeze
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.depth
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.max.descendants
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.procs
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cgroup.stat
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.subtree_control
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.threads
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cgroup.type
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.max
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.pressure
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.effective
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.cpus.partition
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpuset.mems.effective
    -r—​r—​r--. 1 root root 0 Jun  1 11:45 cpu.stat
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 cpu.weight.nice
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 io.pressure
    -rw-r—​r--. 1 root root 0 Jun  1 11:45 memory.pressure
重要

cpu コントローラーは、該当のサブコントロールグループに、同じ CPU の CPU 時間を取り合うプロセスが 2 つ以上ある場合にのみ、有効になります。

検証手順

  • オプション: 目的のコントローラーのみがアクティブな状態で新しい cgroup を作成したことを確認します。

    # cat /sys/fs/cgroup/Example/tasks/cgroup.controllers
    cpuset cpu

18.2. CPU の重みの調整によるアプリケーションへの CPU 時間配分の制御

特定の cgroup ツリーの下にあるアプリケーションへのCPU 時間の配分を調整するには、cpuコントローラーの関連ファイルに値を割り当てる必要があります。

前提条件

  • root 権限がある。
  • CPU 時間の配分を制御するアプリケーションがある。
  • 次の例のように、/sys/fs/cgroup/ root control group 内に、child control groups グループの 2 階層を作成しました。

    …​
      ├── Example
      │   ├── g1
      │   ├── g2
      │   └── g3
    …​
  • cgroups-v2 ファイルシステムでの cgroup の作成とコントローラーの有効化 で説明したのと同様に、親コントロールグループと子コントロールグループで cpu コントローラーを有効にしました。

手順

  1. コントロールグループ内のリソース制限を実現するために、希望する CPU の重みを設定します。

    # echo "150" > /sys/fs/cgroup/Example/g1/cpu.weight
    # echo "100" > /sys/fs/cgroup/Example/g2/cpu.weight
    # echo "50" > /sys/fs/cgroup/Example/g3/cpu.weight
  2. アプリケーションの PID を g1g2、および g3 サブグループに追加します。

    # echo "33373" > /sys/fs/cgroup/Example/g1/cgroup.procs
    # echo "33374" > /sys/fs/cgroup/Example/g2/cgroup.procs
    # echo "33377" > /sys/fs/cgroup/Example/g3/cgroup.procs

    上記のコマンドの例は、目的のアプリケーションが Example/g*/ 子 cgroup のメンバーになり、それらの cgroup の設定に従って CPU 時間を分散させることを保証します。

    実行中のプロセスを持つサブ cgroups(g1g2g3)の重みは、親 cgroup のレベルで合算されます()。その後、CPU リソースはそれぞれの重みに基づいて相対的に配分されます。

    その結果、すべてのプロセスが同時に実行されると、カーネルはそれぞれの cgroup の cpu.weight ファイルに基づいて、それぞれのプロセスに比例配分の CPU 時間を割り当てます。

    サブ cgroupcpu.weight ファイルCPU 時間の割り当て

    g1

    150

    ~ 50% (150/300)

    g2

    100

    ~ 33% (100/300)

    g3

    50

    ~ 16% (50/300)

    cpu.weight コントローラーファイルの値はパーセンテージではありません。

    1 つのプロセスが実行を停止し、cgroup g2 が実行中のプロセスのない状態になると、計算では cgroup g2 が省略され、cgroups g1 および g3 の重みだけが考慮されます。

    サブ cgroupcpu.weight ファイルCPU 時間の割り当て

    g1

    150

    ~ 75% (150/200)

    g3

    50

    ~ 25% (50/200)

    重要

    サブ cgroup に複数の実行中のプロセスがある場合は、それぞれの cgroup に割り当てられる CPU 時間は、その cgroup のメンバープロセスに均等に配分されます。

検証

  1. アプリケーションが指定のコントロールグループで実行されていることを確認します。

    # cat /proc/33373/cgroup /proc/33374/cgroup /proc/33377/cgroup
    0::/Example/g1
    0::/Example/g2
    0::/Example/g3

    コマンド出力は、Example/g*/ サブcgroupsで実行される指定されたアプリケーションのプロセスを示しています。

  2. スロットリングされたアプリケーションの現在の CPU 使用率を確認します。

    # top
    top - 05:17:18 up 1 day, 18:25,  1 user,  load average: 3.03, 3.03, 3.00
    Tasks:  95 total,   4 running,  91 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 18.1 us, 81.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  0.0 st
    MiB Mem :   3737.0 total,   3233.7 free,    132.8 used,    370.5 buff/cache
    MiB Swap:   4060.0 total,   4060.0 free,      0.0 used.   3373.1 avail Mem
    
        PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
      33373 root      20   0   18720   1748   1460 R  49.5   0.0 415:05.87 sha1sum
      33374 root      20   0   18720   1756   1464 R  32.9   0.0 412:58.33 sha1sum
      33377 root      20   0   18720   1860   1568 R  16.3   0.0 411:03.12 sha1sum
        760 root      20   0  416620  28540  15296 S   0.3   0.7   0:10.23 tuned
          1 root      20   0  186328  14108   9484 S   0.0   0.4   0:02.00 systemd
          2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kthread
    ...
    注記

    わかりやすくするために、すべてのサンプルプロセスを単一の CPU で実行するように強制しました。CPU の重みは、複数の CPU で使用される場合にも同じ原則を適用します。

    PID 33373PID 33374、および PID 33377 の CPU リソースは、対応するサブ cgroups に割り当てた重み150、100、50 に基づいて割り当てられたことが分かります。重みは、各アプリケーションの CPU 時間の約 50%、33%、および 16% の配分に対応します。

18.3. cgroups-v1 のマウント

RHEL 9 は、システムの起動プロセス中に、デフォルトで cgroup-v2 仮想ファイルシステムをマウントします。cgroup-v1 機能を使用してアプリケーションのリソースを制限するには、システムを手動で設定します。

注記

cgroup-v1cgroup-v2 の両方がカーネルで完全に有効になっている。カーネルから見た場合、デフォルトのコントロールグループバージョンはありません。また、システムの起動時にマウントするかどうかは、systemd により決定します。

前提条件

  • root 権限がある。

手順

  1. systemd システムおよびサービスマネージャーによるシステムブート中に、デフォルトで cgroups-v1 をマウントするようにシステムを設定します。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

    これにより、必要なカーネルコマンドラインパラメーターが現在のブートエントリーに追加されます。

    すべてのカーネルブートエントリーに同じパラメーターを追加するには:

    # grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"
  2. システムを再起動して、変更を有効にします。

検証

  1. 必要に応じて、cgroups-v1 ファイルシステムがマウントされていることを確認します。

    # mount -l | grep cgroup
    tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,size=4096k,nr_inodes=1024,mode=755,inode64)
    cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
    cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
    cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
    cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
    cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
    cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
    cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
    cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
    cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
    cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)
    cgroup on /sys/fs/cgroup/misc type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,misc)
    cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
    cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,rdma)

    さまざまな cgroup-v1 コントローラーに対応する cgroups-v1 ファイルシステムが、/sys/fs/cgroup/ ディレクトリーに正常にマウントされました。

  2. 必要に応じて、/sys/fs/cgroup/ ディレクトリーの内容を確認します。

    # ll /sys/fs/cgroup/
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 blkio
    lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpu → cpu,cpuacct
    lrwxrwxrwx.  1 root root 11 Mar 16 09:34 cpuacct → cpu,cpuacct
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 cpu,cpuacct
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 cpuset
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 devices
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 freezer
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 hugetlb
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 memory
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 misc
    lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_cls → net_cls,net_prio
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 net_cls,net_prio
    lrwxrwxrwx.  1 root root 16 Mar 16 09:34 net_prio → net_cls,net_prio
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 perf_event
    dr-xr-xr-x. 10 root root  0 Mar 16 09:34 pids
    dr-xr-xr-x.  2 root root  0 Mar 16 09:34 rdma
    dr-xr-xr-x. 11 root root  0 Mar 16 09:34 systemd

    /sys/fs/cgroup/ ディレクトリーは、デフォルトでは root control group とも呼ばれ、cpuset などのコントローラー固有のディレクトリーが含まれています。さらに、systemd に関連するディレクトリーがいくつかあります。

18.4. cgroups-v1 を使用したアプリケーションへの CPU 制限の設定

アプリケーションが CPU 時間を過剰に消費すると、環境の全体的な健全性に悪影響を及ぼす可能性があります。/sys/fs/ 仮想ファイルシステムを使用して、コントロールグループバージョン 1 (cgroups-v1) を使用してアプリケーションへの CPU 制限を設定します。

前提条件

  • root 権限がある。
  • CPU 消費を制限するアプリケーションがある。
  • systemd システムおよびサービスマネージャーによるシステムの起動時に、デフォルトで cgroups-v1 をマウントするようにシステムを設定している。

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller"

    これにより、必要なカーネルコマンドラインパラメーターが現在のブートエントリーに追加されます。

手順

  1. CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。

    # top
    top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
    Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
    MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
    MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
     5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
     6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
        1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
      505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
    ...

    top プログラムの出力例は、PID 6955 (具体例のアプリケーション sha1sum) が CPU リソースを大量に消費することを示しています。

  2. cpu リソースコントローラーディレクトリーにサブディレクトリーを作成します。

    # mkdir /sys/fs/cgroup/cpu/Example/

    上記のディレクトリーは、特定のプロセスを配置でき、特定の CPU 制限をプロセスに適用できるコントロールグループです。同時に、一部の cgroups-v1 インターフェースファイルと cpu コントローラー固有のファイルがディレクトリーに作成されます。

  3. 必要に応じて、新しく作成されたコントロールグループを確認します。

    # ll /sys/fs/cgroup/cpu/Example/
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
    -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
    -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

    この出力例は、特定の設定や制限を表す cpuacct.usagecpu.cfs._period_us などのファイルを示しています。これは、Example コントロールグループのプロセスに設定できます。各ファイル名の前に、そのファイルが属するコントロールグループコントローラーの名前が接頭辞として追加されることに注意してください。

    デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。

  4. コントロールグループの CPU 制限を設定します。

    # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
    # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

    cpu.cfs_period_us ファイルは、制御グループの CPU リソースへのアクセスが再割り当てされる頻度について、マイクロ秒単位の期間 (ここでは「us」と表示されますが µs) を表します。上限は 1 秒で、下限は 1000 マイクロ秒です。

    cpu.cfs_quota_us ファイルは、(cpu.cfs_period_us で定義されるように) コントロールグループのすべてのプロセスを 1 期間中に実行できる合計時間をマイクロ秒単位で表します。1 期間中にコントロールグループ内のプロセスがクォータで指定された時間をすべて使いきるとすぐに、残りの期間はスロットルされて、次の期間まで実行できなくなります。下限は 1000 マイクロ秒です。

    上記のコマンド例は、CPU 時間制限を設定して、Example コントロールグループでまとめられているすべてのプロセスは、1 秒ごと (cpu.cfs_period_us に定義されている) に、0.2 秒間だけ (cpu.cfs_quota_us に定義されている) 実行できるようにしています。

  5. 必要に応じて、制限を確認します。

    # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
    1000000
    200000
  6. アプリケーションの PID を Example コントロールグループに追加します。

    # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
    
    or
    
    # echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

    上記のコマンドは、目的のアプリケーションが Example コントロールグループのメンバーとなるようするので、Example コントロールグループに設定された CPU 制限は超えません。PID は、システム内の既存のプロセスを表します。ここで PID 6955 は、プロセス sha1sum /dev/zero & に割り当てられ、cpu コントローラーの使用例を示すために使用されました。

  7. アプリケーションが指定のコントロールグループで実行されていることを確認します。

    # cat /proc/6955/cgroup
    12:cpuset:/
    11:hugetlb:/
    10:net_cls,net_prio:/
    9:memory:/user.slice/user-1000.slice/user@1000.service
    8:devices:/user.slice
    7:blkio:/
    6:freezer:/
    5:rdma:/
    4:pids:/user.slice/user-1000.slice/user@1000.service
    3:perf_event:/
    2:cpu,cpuacct:/Example
    1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

    上記の出力例は、目的のアプリケーションのプロセスが Example のコントロールグループで実行され、アプリケーションのプロセスに CPU 制限が適用されることを示しています。

  8. スロットルしたアプリケーションの現在の CPU 使用率を特定します。

    # top
    top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
    Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
    MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
    MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
     5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
     6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
      505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
     4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
    ...

    PID 6955 の CPU 消費が 99% から 20% に減少していることに注意してください。

重要

cpu.cfs_period_us および cpu.cfs_quota_us に対応する cgroups-v2 は、cpu.max ファイルです。cpu.max ファイルは、cpu コントローラーから入手できます。

第19章 「BPF コンパイラーコレクションでシステムパフォーマンスの分析」

システム管理者として BPF コンパイラーコレクション (BCC) ライブラリーで Linux オペレーティングシステムのパフォーマンスを分析するツールを作成します。ただし、他のインターフェース経由での取得は困難な場合があります。

19.1. BCC の概要

BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。この主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。

BCC により、ユーザーは eBPF の技術詳細を把握する必要がなくなり、事前に作成した eBPF プログラムを含む bcc-tools パッケージなど、多くの標準スタートポイントを利用できます。

注記

eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。プログラムがカーネルのセーフ仮想マシンで実行するため、カーネルがクラッシュしたり、ループしたり、応答しなくなることはあまりありません。

19.2. bcc-tools パッケージのインストール

このセクションでは、BCC (BPF コンパイラーコレクション) ライブラリーを含む bcc-tools パッケージをインストールする方法を説明します。

手順

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

    # dnf install bcc-tools

    BCC ツールは、/usr/share/bcc/tools/ ディレクトリーにインストールされます。

  2. 必要に応じて、ツールを検証します。

    # ll /usr/share/bcc/tools/
    ...
    -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
    -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
    -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
    -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
    drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
    -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
    -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
    -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
    ...

    上記の一覧にある doc ディレクトリーには、各ツールのドキュメントが含まれます。

19.3. bcc-tools でパフォーマンスの分析

このセクションでは、BPF コンパイラーコレクション (BCC) ライブラリーから特定の事前作成されたプログラムを使用して、イベントごとにシステムパフォーマンスを効率的かつ安全に分析する方法を説明します。BCC ライブラリーで事前作成されたプログラムセットは、追加プログラム作成の例として使用できます。

execsnoop を使用したシステムプロセスの検証

  1. ある端末で execsnoop プログラムを実行します。

    # /usr/share/bcc/tools/execsnoop
  2. 別の端末で、以下のように実行します。

    $ ls /usr/share/bcc/tools/doc/

    これにより、ls コマンドの短命プロセスが作成されます。

  3. execsnoop を実行している端末は、以下のような出力を表示します。

    PCOMM	PID    PPID   RET ARGS
    ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
    ...

    execsnoop プログラムは、新しいプロセスごとに出力行を出力するため、システムリソースを消費します。また、ls などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。

    execsnoop 出力には以下のフィールドが表示されます。

    • PCOMM - 親プロセス名。(ls)
    • PID - プロセス ID(8382)
    • ppid: 親プロセス ID。(8287)
    • RET - exec() のシステム呼び出しの戻り値 (0)。プログラムコードを新規プロセスに読み込みます。
    • ARGS - 引数を使用して開始したプログラムの場所。

execsnoop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/execsnoop_example.txt ファイルを参照してください。

exec() の詳細は、exec(3) man ページを参照してください。

opensnoop を使用した、コマンドにより開かれるファイルの追跡

  1. ある端末で opensnoop プログラムを実行します。

    # /usr/share/bcc/tools/opensnoop -n uname

    上記の出力では、uname コマンドのプロセスによってのみ開かれるファイルの内容が出力されます。

  2. 別の端末で、以下を実行します。

    $ uname

    上記のコマンドは、特定のファイルを開きます。このファイルは次のステップでキャプチャーされます。

  3. opensnoop を実行している端末は、以下のような出力を表示します。

    PID    COMM 	FD ERR PATH
    8596   uname 	3  0   /etc/ld.so.cache
    8596   uname 	3  0   /lib64/libc.so.6
    8596   uname 	3  0   /usr/lib/locale/locale-archive
    ...

    opensnoop プログラムは、システム全体で open() システム呼び出しを監視し、uname が開こうとしたファイルごとに出力行を出力します。

    opensnoop 出力には、以下のフィールドが表示されます。

    • PID - プロセス ID(8596)
    • COMM - プロセス名 (uname)
    • FD - ファイルの記述子。開いたファイルを参照するために open() が返す値。(3)
    • ERR - すべてのエラー
    • PATH - open() で開こうとしたファイルの場所。

      コマンドが、存在しないファイルを読み込もうとすると、FD コラムは -1 を返し、ERR コラムは関連するエラーに対応する値を出力します。その結果、opennoop は、適切に動作しないアプリケーションの特定に役立ちます。

opensnoop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/opensnoop_example.txt ファイルを参照してください。

open() の詳細は、open(2) man ページを参照してください。

ディスク上の I/O 操作を調べるための biotop の使用

  1. ある端末で biotop プログラムを実行します。

    # /usr/share/bcc/tools/biotop 30

    このコマンドにより、ディスク上で I/O 操作を実行する上位のプロセスを監視できます。この引数は、コマンドが 30 秒の概要を生成するようにします。

    注記

    引数を指定しないと、デフォルトでは 1 秒ごとに出力画面が更新されます。

  2. 別の端末では、以下のようになります。

    # dd if=/dev/vda of=/dev/zero

    上記のコマンドは、ローカルのハードディスクデバイスからコンテンツを読み込み、出力を /dev/zero ファイルに書き込みます。この手順では、biotop を示す特定の I/O トラフィックを生成します。

  3. biotop を実行している端末は、以下のような出力を表示します。

    PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
    9568   dd               R 252 0   vda      16294 14440636.0  3.69
    48     kswapd0          W 252 0   vda       1763 120696.0    1.65
    7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
    1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
    7515   Xorg             R 252 0   vda        280  9940.0     0.28
    7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
    9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
    8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
    7807   gnome-software   R 252 0   vda         31  2336.0     0.73
    9578   awk              R 252 0   vda         17  2228.0     0.66
    7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
    9581   pgrep            R 252 0   vda         58  1748.0     0.42
    7531   InputThread      R 252 0   vda         30  1200.0     0.48
    7504   gdbus            R 252 0   vda          3  1164.0     0.30
    1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
    1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
    ...

    biotop 出力には、以下のフィールドが表示されます。

    • PID - プロセス ID(9568)
    • COMM - プロセス名。(dd)
    • DISK - 読み取り操作を実行するディスク。(vda)
    • I/O - 実行された読み取り操作の数。(16294)
    • kbytes - 読み取り操作によって使用したバイト数 (KB)。(14,440,636)
    • AVGms - 読み取り操作の平均 I/O 時間。(3.69)

biotop の詳細、例、およびオプションを確認するには、/usr/share/bcc/tools/doc/biotop_example.txt ファイルを参照してください。

dd の詳細は、dd(1) man ページを参照してください。

xfsslower を使用した、予想外に遅いファイルシステム動作の明確化

  1. 端末で xfsslower プログラムを実行します。

    # /usr/share/bcc/tools/xfsslower 1

    上記のコマンドは、XFS ファイルシステムが、読み込み、書き込み、開く、または同期 (fsync) 操作を実行するのに費やした時間を測定します。1 引数を指定すると、1 ms よりも遅い操作のみが表示されます。

    注記

    引数を指定しないと、xfsslower はデフォルトで 10 ms よりも低速な操作を表示します。

  2. 別の端末で、たとえば以下を実行します。

    $ vim text

    上記のコマンドは、vim エディターでテキストファイルを作成し、XFS ファイルシステムと特定の対話を開始します。

  3. xfsslower を実行している端末は、前の手順でファイルを保存した場合と同様の内容を示しています。

    TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
    13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
    13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
    13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
    13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
    13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
    13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
    ...

    上記の各行はファイルシステム内の操作を表し、特定のしきい値よりも時間がかかります。xfsslower は、操作に想定以上に時間がかかるなど、ファイルシステムで発生し得る問題を表面化するのに適しています。

    xfsslower 出力には、以下のフィールドが表示されます。

    • COMM - プロセス名。(b'bash')
    • T - 操作の種類。(R)

      • Read
      • Write
      • Sync
    • OFF_KB - ファイルオフセット(KB)。(0)
    • FILENAME - 読み取り、書き込み、または同期するファイルです。

xfsslower の詳細、例、およびオプションについては、/usr/share/bcc/tools/doc/xfsslower_example.txt ファイルを参照してください。

fsync の詳細は、fsync(2) の man ページを参照してください。

第20章 Huge Page の設定

物理メモリーは、ページと呼ばれる固定サイズのブロックで管理されます。Red Hat Enterprise Linux 9 でサポートされている x86_64 アーキテクチャーでは、メモリーページのデフォルトサイズは 4 KB です。このデフォルトのページサイズは、さまざまなワークロードをサポートする Red Hat Enterprise Linux などの一般的なオペレーティングシステムに適しています。

ただし、特定のアプリケーションは、特定のケースで大きなページサイズを使用する利点を得られます。たとえば、数百メガバイトまたは数千ギガバイトの大規模で比較的固定されたデータセットで動作するアプリケーションでは、4 KB ページを使用するとパフォーマンスの問題が発生する可能性があります。このようなデータセットには大量の 4 KB ページが必要になるため、オペレーティングシステムや CPU でオーバーヘッドが発生する可能性があります。

本セクションでは、RHEL 9 で利用可能なヒュージページとその設定方法を説明します。

20.1. 利用可能な Huge Page の機能

Red Hat Enterprise Linux 9 では、大規模なデータセットと連携するアプリケーションに Huge Page を使用し、このようなアプリケーションのパフォーマンスを向上できます。

以下は、RHEL 9 でサポートされる Huge Page メソッドです。

HugeTLB pages

HugeTLB ページも静的なヒュージページと呼ばれます。HugeTLB ページを予約する方法は 2 つあります。

  • ブート時: メモリーが大幅に断片化されていないため、成功する可能性が高くなります。ただし、NUMA マシンでは、ページ数は NUMA ノード間で自動的に分割されます。HugeTLB ページの動作に影響を与えるパラメーターの詳細は、「システムの起動時に HugeTLB ページを確保するため のパラメーター」および「システムの起動時に HugeTLB ページの設定」 参照してください。
  • ランタイム時に: NUMA ノードごとにヒュージページを予約することができます。ランタイム予約がブートプロセスの早い段階で行われると、メモリーの断片化はより低くなります。HugeTLB ページの動作に影響を与えるパラメーターの詳細は、「起動時に HugeTLB ページを 確保するためのパラメーター」と、これらのパラメーターを使用してランタイム 時に HugeTLB ページを設定する方法は、「ランタイム時に HugeTLB ページの設定」を参照してください。
Transparent HugePages (THP)

THP では、カーネルはヒュージページをプロセスに自動的に割り当てるため、静的な Huge Page を手動で予約する必要はありません。以下は、THP における動作の 2 つのモードです。

  • system-wide で、カーネルはヒュージページを割り当て、プロセスが連続している仮想メモリー領域を使用しているたびに Huge Page をプロセスに割り当てようと試みます。
  • プロセスごと: ここでは、カーネルは各プロセスのメモリー領域だけに割り当てるため、madvise() システムコールを使用して指定できるヒュージページを 1 つのみに割り当てます。

    注記

    THP 機能は、2 MB ページのみに対応します。

    HugeTLB ページの動作に影響を与えるパラメーターの詳細は、「透過的な Huge Page の 有効化」および「透過的な Huge Page の 無効化」を参照して ください。

20.2. 起動時に HugeTLB ページを確保するためのパラメーター

システムの起動時に HugeTLB ページの動作に影響を与える場合は、次のパラメーターを使用します。

これらのパラメーターを使用して起動時に HugeTLB ページを設定する方法は、「システムの起動時に HugeTLB の設定 」を参照してください。

表20.1 起動時の HugeTLB ページの設定に使用されるパラメーター

パラメーター説明デフォルト値

hugepages

ブート時にカーネルに設定される永続ヒュージページの数を定義します。

NUMA システムでは、このパラメーターが定義されている Huge Page はノード間で均等に分割されます。

ランタイム時に /sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages ファイルにあるノードの値を変更することで、起動時に Huge Page を特定のノードに割り当てることができます。

デフォルト値は 0 です。

起動時にこの値を更新するには、/proc/sys/vm/nr_hugepages ファイルでこのパラメーターの値を変更します。

hugepagesz

起動時にカーネルに設定される永続ヒュージページのサイズを定義します。

有効な値は 2 MB および 1 GB です。デフォルト値は 2 MB です。

default_hugepagesz

起動時にカーネルに設定される永続 Huge Page のデフォルトのサイズを定義します。

有効な値は 2 MB および 1 GB です。デフォルト値は 2 MB です。

20.3. 起動時の HugeTLB の設定

HugeTLB サブシステムがサポートするページサイズは、アーキテクチャーによって異なります。x86_64 アーキテクチャーは、2 MB の Huge Page および 1 GB のギガンティックページをサポートします。

この手順では、システムの起動時に 1 GB ページを予約する方法を説明します。

手順

  1. 1 GB ページの HugeTLB プールを作成するには、root で、/etc/default/grub ファイルのカーネルコマンドラインオプションに次の行を追加します。

    default_hugepagesz=1G hugepagesz=1G
  2. 編集されたデフォルトファイルを使用して、GRUB2 設定を再生成します。

    1. BIOS ファームウェアを使用しているシステムの場合は次のコマンドを実行します。

      # grub2-mkconfig -o /boot/grub2/grub.cfg
    2. システムで UEFI フレームワークを使用している場合は、以下のコマンドを実行します。

      # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  3. /usr/lib/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=/usr/lib/systemd/hugetlb-reserve-pages.sh
    
    [Install]
    WantedBy=sysinit.target
  4. /usr/lib/systemd/ ディレクトリーに hugetlb-reserve-pages.sh という新しいファイルを作成し、以下の内容を追加します。

    以下の内容を追加する場合、number_of_pages を、予約する 1GB ページ数に置き換え、node を、これらのページを予約するノードの名前に置き換えます。

    #!/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 number_of_pages node

    たとえば、node0 で 2 つの1 GB ページ、node1 で 1GB のページを予約するには、number_of_pages を、node0 の場合は 2 に置き換え、node1 の場合は 1 に置き換えます。

    reserve_pages 2 node0
    reserve_pages 1 node1
  5. 実行可能なスクリプトを作成します。

    # chmod +x /usr/lib/systemd/hugetlb-reserve-pages.sh
  6. 初期のブート予約を有効にします。

    # systemctl enable hugetlb-gigantic-pages
注記
  • nr_hugepages にいつでも書き込みを行い、ランタイム時に 1 GB を超えるページを予約できます。ただし、メモリーの断片化により、このような予約が失敗する可能性があります。1 GB ページを予約する最も信頼できる方法は、システムの起動の初期段階で実行するこのhugetlb-reserve-pages.sh スクリプトを使用することです。
  • 静的 Huge Page を確保することで、システムで利用可能なメモリー量を効果的に減らすことができます。ただし、メモリーの全容量を適切に使用できなくなります。予約された Huge Page の適切なサイズプールは、これを使用するアプリケーションにとって有益になりますが、予約済み Huge Page の過度なサイズや未使用のプールは最終的にシステムパフォーマンス全体に悪影響を及ぼします。予約済みの Huge Page プールを設定する場合は、システムによってメモリーの最大容量を適切に利用できるようになります。

関連情報

  • systemd.service(5) man ページ
  • /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt file

20.4. ランタイム時に HugeTLB ページを確保するためのパラメーター

実行時に HugeTLB ページの動作に影響を与える場合は、以下のパラメーターを使用します。

これらのパラメーターを使用して起動時に HugeTLB ページを設定する方法は、「ランタイム時に HugeTLB の設定 」を参照してください。

表20.2 ランタイム時に HugeTLB ページを設定するために使用されるパラメーター

パラメーター説明ファイル名

nr_hugepages

指定された NUMA ノードに割り当てられる指定したサイズの Huge Page の数を定義します。

/sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages

nr_overcommit_hugepages

オーバーコミットメモリーを介してシステムで作成され、使用できる追加の Huge Page の最大数を定義します。

このファイルにゼロ以外の値を書き込むと、永続 Huge Page プールが使い切られると、システムはカーネルの通常のページプールから その数の Huge Page を取得することを示しています。これら超過分の Huge Page は使用されなくなるので、これらは解放され、カーネルの通常のページプールに戻ります。

/proc/sys/vm/nr_overcommit_hugepages

20.5. ランタイム時の HugeTLB の設定

この手順では、20 2048 kB Huge Page を node2 に追加する方法を説明します。

要件に基づいてページを確保するには、以下を置き換えます。

  • 20 (予約する Huge Page 数)
  • Huge Page のサイズを含めた 2048kB
  • ページを予約するノードのある node2

手順

  1. メモリー統計を表示します。

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total add
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0      0      0      0
    HugePages_Free        0      0      0      0      0
    HugePages_Surp        0      0      0      0      0
  2. 指定のサイズの Huge Page 数をノードに追加します。

    # echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages

検証手順

  • Huge Page の数が追加されていることを確認します。

    # numastat -cm | egrep 'Node|Huge'
                     Node 0 Node 1 Node 2 Node 3  Total
    AnonHugePages         0      2      0      8     10
    HugePages_Total       0      0     40      0     40
    HugePages_Free        0      0     40      0     40
    HugePages_Surp        0      0      0      0      0

関連情報

  • numastat(8) の man ページ

20.6. 透過的な HugePage の有効化

Red Hat Enterprise Linux 9 では、THP がデフォルトで有効になっています。ただし、THP を有効または無効にすることができます。

この手順では、THP を有効にする方法を説明します。

手順

  1. THP の現在の状態を確認します。

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. THP を有効にします。

    # echo always > /sys/kernel/mm/transparent_hugepage/enabled
  3. アプリケーションが、必要以上のメモリーリソースを割り当てないようにするには、システム全体の透過的な Huge Page を無効にし、madvise を介して明示的に要求するアプリケーションに対してのみ有効にします。

    # echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
注記

短期的な割り当てのレイテンシーが低くなると、有効期間の長い割り当てで最適パフォーマンスをすぐに実現するよりも優先度が高くなります。この場合は、THP を有効にしたままでも直接圧縮を無効にできます。

直接圧縮は、Huge Page の割り当て中の同期メモリー圧縮です。直接圧縮を無効にすると、メモリーの保存は保証されませんが、頻繁なページ障害の発生時にレイテンシーが高くなる可能性が減ります。ワークロードが THP から著しく異なる場合に、パフォーマンスが低下する点に注意してください。直接圧縮を無効にします。

# echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

関連情報

20.7. 透過的な Huge Page の無効化

Red Hat Enterprise Linux 9 では、THP がデフォルトで有効になっています。ただし、THP を有効または無効にすることができます。

この手順では、THP を無効にする方法を説明します。

手順

  1. THP の現在の状態を確認します。

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. THP を無効にします。

    # echo never > /sys/kernel/mm/transparent_hugepage/enabled

20.8. 翻訳されたバッファーサイズのページサイズの影響

ページテーブルからアドレスマッピングを読み取るのは、非常に時間がかかり、リソースの負荷が高くなります。そのため、CPU は、トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) と呼ばれる、最近使用されたアドレスのキャッシュで構築されます。ただし、デフォルトの TLB は、特定のアドレスマッピングのみをキャッシュできます。

要求されたアドレスマッピングが TLB ミスと呼ばれる TLB にない場合、システムはページテーブルを読み込んで、物理から仮想アドレスへのマッピングを判断する必要があります。アプリケーションメモリー要件と、アドレスマッピングのキャッシュに使用されるページサイズ間の関係により、メモリー要件が高いアプリケーションは、最小限であるアプリケーションと比べて、TLB ミスによるパフォーマンスの低下の影響が高くなる可能性があります。したがって、可能であれば TLB ミスを回避するためには重要です。

HugeTLB 機能と Transparent Huge Page 機能の両方を使用すると、アプリケーションは 4 KB よりも大きなページを使用できます。これにより、TLB に保存されているアドレスはより多くのメモリーを参照できます。これにより、TLB ミスが軽減され、アプリケーションのパフォーマンスが向上します。

第21章 SystemTap の使用

システム管理者は、SystemTap を使用して、実行中の Linux システムでバグやパフォーマンスの問題の基本的な原因を特定できます。

アプリケーション開発者は、SystemTap を使用して、Linux システムでアプリケーションがどのように動作するかを詳細に監視できます。

21.1. SystemTap の目的

SystemTap は、オペレーティングシステム (特にカーネル) の動作を詳細に観察および監視できる追跡およびプロービングのツールです。SystemTap では、netstatpstopiostat などのツールのアウトプットと同様の情報を利用できます。ただし、SystemTap では、収集した情報に対するフィルター処理と分析のオプションが強化されています。SystemTap スクリプトでは、SystemTap が収集する情報を指定します。

SystemTap は、カーネルのアクティビティーを追跡するインフラストラクチャーをユーザーに提供し、この機能を 2 つの属性で組み合わせることで、既存の Linux 監視ツールスイートを補完します。

柔軟性
SystemTap のフレームワークを使用すると、幅広いカーネル機能、システムコール、およびカーネルスペースで発生する他のイベントについて、調査および監視目的のシンプルなスクリプトを開発できます。つまり、SystemTap はツールというよりも、独自のカーネル固有のフォレンジックおよび監視ツールの開発を可能にするシステムといえます。
使いやすさ
SystemTap を使用すると、カーネルを再コンパイルしたり、システムを再起動したりせずに、カーネルのアクティビティーを監視できます。

21.2. SystemTap のインストール

SystemTap の使用を開始するには、必要なパッケージをインストールします。システムに複数のカーネルがインストールされていて、それらのカーネル上で SystemTap を使用するには、each カーネルバージョン用に一致する必要なカーなネルパッケージをインストールします。

前提条件

手順

  1. 必要な SystemTap パッケージをインストールします。

    # dnf install systemtap
  2. 必要なカーネルパッケージをインストールします。

    1. stap-prep の使用:

      # stap-prep
    2. stap-prep が機能しない場合は、必要なカーネルパッケージを手動でインストールします。

      # dnf install kernel-debuginfo-$(uname -r) kernel-debuginfo-common-$(uname -i)-$(uname -r) kernel-devel-$(uname -r)

      $(uname -i) は、システムのハードウェアプラットフォームに自動的に置き換えられ、$(uname -r) は、実行中のカーネルのバージョンに自動的に置き換えられます。

検証手順

  • SystemTap でプローブするカーネルが現在使用中の場合は、インストールが成功したかどうかをテストします。

    # stap -v -e 'probe kernel.function("vfs_read") {printf("read performed\n"); exit()}'

    SystemTap のデプロイメントが成功すると、以下のような出力になります。

    Pass 1: parsed user script and 45 library script(s) in 340usr/0sys/358real ms.
    Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 290usr/260sys/568real ms.
    Pass 3: translated to C into "/tmp/stapiArgLX/stap_e5886fa50499994e6a87aacdc43cd392_399.c" in 490usr/430sys/938real ms.
    Pass 4: compiled C into "stap_e5886fa50499994e6a87aacdc43cd392_399.ko" in 3310usr/430sys/3714real ms.
    Pass 5: starting run. 1
    read performed 2
    Pass 5: run completed in 10usr/40sys/73real ms. 3

    最後の 3 行の出力 (Pass 5 で始まる) は、以下を示しています。

    1
    SystemTap が、カーネルをプローブしてインストルメンテーションを実行するインストルメンテーションを正常に作成し、インストルメンテーションを実行しました。
    2
    SystemTap が、指定したイベント (この場合は A VFS 読み取り) を検出しました。
    3
    SystemTap が有効なハンドラーを実行しました (テキストを出力した後、エラーなしで閉じました)。

21.3. SystemTap を実行する特権

SystemTap スクリプトを実行するには、システム特権が必要ですが、一部の例では、特権のないユーザーがマシンで SystemTap インストルメンテーションを実行する必要がある場合があります。

ユーザーが root アクセスなしで SystemTap を実行できるようにするには、ユーザーを以下の両方のユーザーグループに追加します。

stapdev

このグループのメンバーは stap を使用して SystemTap スクリプトを実行したり、staprun を使用して SystemTap インストルメンテーションモジュールを実行することができます。

stap の実行では、SystemTap スクリプトがカーネルモジュールにコンパイルされ、それがカーネルに読み込まれます。これにはシステムに対する権限の昇格が必要となり、stapdev メンバーにはそれが付与されます。ただし、この権限は stapdev メンバーに有効な root アクセスも付与することになります。このため、stapdev グループのメンバーシップは、root アクセスを信頼して付与できるメンバーにのみ許可してください。

stapusr
このグループのメンバーが SystemTap インストルメンテーションモジュールの実行に使用できるのは、staprun のみです。また、これらのモジュールは、/lib/modules/kernel_version/systemtap/ ディレクトリーからのみ実行できます。このディレクトリーを所有できるのは root ユーザーのみで、書き込みが可能なのも root ユーザーのみでなければならなりません。

21.4. SystemTap スクリプトの実行

SystemTap スクリプトは、標準入力またはファイルから実行できます。

SystemTap のインストールと合わせて配布されるサンプルスクリプトは、/usr/share/systemtap/examples ディレクトリーにあります。

前提条件

  1. 「SystemTap のインストール」で説明されているように、SystemTap および関連する必須カーネルパッケージがインストールされている。https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/getting-started-with-systemtap_monitoring-and-managing-system-status-and-performance#installing-systemtap_getting-started-with-systemtap
  2. SystemTap スクリプトを通常のユーザーとして実行するには、そのユーザーを SystemTap グループに追加します。

    # usermod --append --groups
    stapdev,stapusr user-name

手順

  • SystemTap スクリプトを実行します。

    • 標準入力

      # echo "probe timer.s(1) {exit()}" | stap -

      このコマンドは、echo が標準入力に渡すスクリプトを実行するように stap に指示します。stap オプションを追加するには、- 文字の前にオプションを挿入します。たとえば、このコマンドの結果をより詳細にするには、次のコマンドを実行します。

      # echo "probe timer.s(1) {exit()}" | stap -v -
    • ファイルから:

      # stap file_name

第22章 SystemTap のクロスインストルメンテーション

SystemTap のクロスインストルメンテーションは、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを作成し、SystemTap が完全にデプロイされていない別のシステムで使用します。

22.1. SystemTap のクロスインストルメンテーション

SystemTap スクリプトを実行すると、そのスクリプトからカーネルモジュールが構築されます。SystemTap が、モジュールをカーネルに読み込みます。

通常、SystemTap スクリプトは SystemTap がデプロイされているシステムでのみ実行できます。SystemTap を 10 台のシステムで実行するには、これらすべてのシステムに SystemTap をデプロイする必要があります。場合によっては、これは実現不可能もしくは望ましくないこともあります。たとえば、企業ポリシーでは、特定のマシンでコンパイラーまたはデバッグ情報を提供するパッケージのインストールを禁止している場合があります。これにより、SystemTap のデプロイメントが妨げられます。

この状況を避けるためには、クロスインストルメンテーション を使用します。これは、あるシステム上の SystemTap スクリプトから別のシステムで使用する SystemTap インストルメンテーションモジュールを生成するプロセスです。このプロセスは、以下の利点をもたらします。

  • 各種マシンのカーネル情報パッケージを単一のホストマシンにインストールできます。

    重要

    カーネルのパッケージ化にバグがあると、インストールが妨げられる場合があります。この場合、ホストシステム および ターゲットシステムkernel-debuginfo パッケージおよび kernel-devel パッケージは一致している必要があります。バグが発生した場合は、 https://bugzilla.redhat.com/ でバグを報告します。

  • 生成された SystemTap インストルメンテーションモジュール (systemtap-runtime) を使用するために、ターゲットマシン ごとに 1 つのパッケージのみをインストールする必要があります。

    重要

    構築された インストルメンテーションモジュール が機能するには、ホストシステムターゲットシステム が同一アーキテクチャーで同じ Linux ディストリビューションを実行している必要があります。

用語
インストルメンテーションモジュール
SystemTap スクリプトから構築されるカーネルモジュールです。SystemTap モジュールは host system 上に構築され、ターゲットシステムターゲットカーネル に読み込まれます。
ホストシステム
このシステム上で (SystemTap スクリプトから) インストルメンテーションモジュールがコンパイルされ、target systems に読み込まれます。
ターゲットシステム
このシステム内で (SystemTap スクリプトから) インストルメンテーションモジュールが構築されます。
ターゲットカーネル
ターゲットシステム のカーネル。これは、インストルメンテーションモジュール を読み込み、実行するカーネルです。

22.2. SystemTap のクロスインストルメンテーションの初期化

SystemTap のクロスインストルメンテーションを初期化し、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを構築して SystemTap が完全にデプロイされていない別のシステムで使用します。

前提条件

  • SystemTap が「 Systemtap のインストール」で説明されているように、ホストシステム にインストール されている。
  • ターゲットシステムsystemtap-runtime パッケージがインストールされている。

    # dnf install systemtap-runtime
  • ホストシステムターゲットシステム の両方のアーキテクチャーが同じである。
  • ホストシステム と ターゲットシステム の両方が、同じメジャーバージョンの Red Hat Enterprise Linux(Red Hat Enterprise Linux 9 など)を実行している。
重要

カーネルのパッケージ化のバグにより、複数の kernel-debuginfo パッケージおよび kernel-devel パッケージが 1 つのシステムにインストールされない場合があります。この場合、ホストシステム および ターゲットシステム のマイナーバージョンが一致している必要があります。バグが発生した場合は、https://bugzilla.redhat.com/ で報告してください。

手順

  1. それぞれの ターゲットシステム で実行しているカーネルを特定します。

    $ uname -r

    ターゲットシステム ごとにこの手順を繰り返します。

  2. ホストシステム で、「 Systemtap のインストール」で説明されているように各 ターゲットシステム のターゲット カーネル および関連パッケージをインストール します。
  3. ホストシステム でインストルメンテーションモジュールを構築し、このモジュールをコピーして ターゲットシステム でこのモジュールを実行します。

    1. リモート実装の使用

      # stap --remote target_system script

      このコマンドは、ターゲットシステム で指定したスクリプトをリモートで実装します。これを成功させるには、ホストシステム から ターゲットシステム に SSH 接続を確立できることを確認する必要があります。

    2. 手動

      1. ホストシステム にインストルメンテーションモジュールを構築します。

        # stap -r kernel_version script -m module_name -p 4

        ここで、kernel_version は、手順 1 で判断した ターゲットカーネル のバージョンを参照します。スクリプト は、インストルメンテーションモジュール に変換するスクリプトを参照し、モジュール名 は、インストルメンテーションモジュール の希望の名前になります。-p4 オプションは、コンパイルしたモジュールを読み込み、実行しないように SystemTap に指示を出します。

      2. インストルメンテーションモジュールがコンパイルされたら、ターゲットシステムにコピーして、以下のコマンドを使用して読み込みます。

        # staprun module_name.ko

第23章 SystemTap でのネットワークアクティビティーの監視

/usr/share/systemtap/testsuite/systemtap.examples/ ディレクトリーで利用可能な SystemTap スクリプトの例を使用して、systemtap-testsuite パッケージをインストールし、システムのネットワークアクティビティーを監視して調べることができます。

23.1. SystemTap でのネットワークアクティビティーのプロファイル

nettop.stp のサンプルの SystemTap スクリプトを使用して、ネットワークアクティビティーのプロファイルを作成できます。このスクリプトは、システムでネットワークトラフィックを生成しているプロセスを追跡し、各プロセスに関する以下の情報を提供します。

PID
一覧表示されているプロセスの ID。
UID
ユーザー ID。ユーザー ID が 0 の場合は、root ユーザーを指します。
DEV
データの送受信に使用されるイーサネットデバイス (eth0、eth1 など)。
XMIT_PK
プロセスが送信したパケットの数。
RECV_PK
プロセスが受信したパケットの数。
XMIT_KB
プロセスにより送信されたデータの量 (キロバイト)。
RECV_KB
サービスが受信したデータの量 (キロバイト単位)。

前提条件

手順

  • nettop.stp スクリプトを実行します。

    # stap  --example nettop.stp

    nettop.stp スクリプトは、5 秒間隔でネットワークプロファイルのサンプリングを行います。

    nettop.stp スクリプトの出力は、以下のようになります。

    [...]
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          0       5       0       0 swapper
    11178     0 eth0          2       0       0       0 synergyc
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
     2886     4 eth0         79       0       5       0 cups-polld
    11362     0 eth0          0      61       0       5 firefox
        0     0 eth0          3      32       0       3 swapper
     2886     4 lo            4       4       0       0 cups-polld
    11178     0 eth0          3       0       0       0 synergyc
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          0       6       0       0 swapper
     2886     4 lo            2       2       0       0 cups-polld
    11178     0 eth0          3       0       0       0 synergyc
     3611     0 eth0          0       1       0       0 Xorg
      PID   UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
        0     0 eth0          3      42       0       2 swapper
    11178     0 eth0         43       1       3       0 synergyc
    11362     0 eth0          0       7       0       0 firefox
     3897     0 eth0          0       1       0       0 multiload-apple

23.2. SystemTap でネットワークソケットコードで呼び出される関数のトレース

socket-trace.stp のサンプルの SystemTap スクリプトを使用して、カーネルの net/socket.c ファイルから呼び出された関数を追跡できます。これにより、各プロセスがカーネルレベルでネットワークとどのように相互作用するかを、詳細に把握できます。

前提条件

手順

  • socket-trace.stp スクリプトを実行します。

    # stap  --example socket-trace.stp

    socket-trace.stp スクリプトの 3 秒の抜粋は、以下のようになります。

    [...]
    0 Xorg(3611): -> sock_poll
    3 Xorg(3611): <- sock_poll
    0 Xorg(3611): -> sock_poll
    3 Xorg(3611): <- sock_poll
    0 gnome-terminal(11106): -> sock_poll
    5 gnome-terminal(11106): <- sock_poll
    0 scim-bridge(3883): -> sock_poll
    3 scim-bridge(3883): <- sock_poll
    0 scim-bridge(3883): -> sys_socketcall
    4 scim-bridge(3883):  -> sys_recv
    8 scim-bridge(3883):   -> sys_recvfrom
    12 scim-bridge(3883):-> sock_from_file
    16 scim-bridge(3883):<- sock_from_file
    20 scim-bridge(3883):-> sock_recvmsg
    24 scim-bridge(3883):<- sock_recvmsg
    28 scim-bridge(3883):   <- sys_recvfrom
    31 scim-bridge(3883):  <- sys_recv
    35 scim-bridge(3883): <- sys_socketcall
    [...]

23.3. SystemTap でのネットワークパケットドロップの監視

Linux のネットワークスタックは、様々な理由でパケットを破棄する場合があります。Linux カーネルによっては、パケットが破棄される場所を追跡するトレースポイント kernel.trace("kfree_skb")` が含まれます。

dropwatch.stp SystemTap スクリプトは、kernel.trace("kfree_skb") を使用してパケットの破棄を追跡します。スクリプトは、5 秒間隔でパケットを破棄する場所を要約します。

前提条件

手順

  • dropwatch.stp スクリプトを実行します。

    # stap  --example dropwatch.stp

    dropwatch.stp スクリプトを 15 秒間実行すると、以下のような出力になります。

    Monitoring for dropped packets
    51 packets dropped at location 0xffffffff8024cd0f
    2 packets dropped at location 0xffffffff8044b472
    51 packets dropped at location 0xffffffff8024cd0f
    1 packets dropped at location 0xffffffff8044b472
    97 packets dropped at location 0xffffffff8024cd0f
    1 packets dropped at location 0xffffffff8044b472
    Stopping dropped packet monitor
    注記

    パケットドロップの場所をより意味のあるものにするには、/boot/System.map-$(uname -r) を参照してください。このファイルは、各関数の開始アドレスの一覧を表示し、dropwatch.stp スクリプトの出力内のアドレスを特定の関数名にマップできるようにします。/boot/System.map-$(uname -r) ファイルの以下のようなスニペットの場合、アドレス 0xffffffff8024cd0f は関数 unix_stream_recvmsg に、アドレス 0xffffffff8044b472 は関数 arp_rcv にマッピングされます。

    [...]
    ffffffff8024c5cd T unlock_new_inode
    ffffffff8024c5da t unix_stream_sendmsg
    ffffffff8024c920 t unix_stream_recvmsg
    ffffffff8024cea1 t udp_v4_lookup_longway
    [...]
    ffffffff8044addc t arp_process
    ffffffff8044b360 t arp_rcv
    ffffffff8044b487 t parp_redo
    ffffffff8044b48c t arp_solicit
    [...]

第24章 SystemTap でのカーネルアクティビティーのプロファイル

以下のセクションでは、関数呼び出しを監視することでカーネルアクティビティーのプロファイルを実行するスクリプトを説明します。

24.1. SystemTap での関数呼び出しのカウント

functioncallcount.stp SystemTap スクリプトを使用して、特定のカーネル関数呼び出しを数えることができます。このスクリプトを使用して、複数のカーネル関数をターゲットにすることもできます。

手順

  • functioncallcount.stp スクリプトを実行します。

    # stap --example functioncallcount.stp 'argument'

    このスクリプトは、ターゲットのカーネル関数を引数として取ります。引数のワイルドカードを使用すると、ある程度まで複数のカーネル関数を対象にできます。

    スクリプトの出力には、アルファベット順に、呼び出された関数の名前と、サンプル時間中に呼び出された回数が含まれています。

    以下の例を見てみましょう。

    # stap -w -v --example functioncallcount.stp "*@mm*.c" -c /bin/true

    ここで、

  • -w : 警告を表示しません。
  • -v : 起動したカーネルの出力を表示します。
  • -c コマンド : コマンドの実行中に関数呼び出しを数えるように SystemTap に指示します (この例では /bin/true)。

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

    [...]
    __vma_link 97
    __vma_link_file 66
    __vma_link_list 97
    __vma_link_rb 97
    __xchg 103
    add_page_to_active_list 102
    add_page_to_inactive_list 19
    add_to_page_cache 19
    add_to_page_cache_lru 7
    all_vm_events 6
    alloc_pages_node 4630
    alloc_slabmgmt 67
    anon_vma_alloc 62
    anon_vma_free 62
    anon_vma_lock 66
    anon_vma_prepare 98
    anon_vma_unlink 97
    anon_vma_unlock 66
    arch_get_unmapped_area_topdown 94
    arch_get_unmapped_exec_area 3
    arch_unmap_area_topdown 97
    atomic_add 2
    atomic_add_negative 97
    atomic_dec_and_test 5153
    atomic_inc 470
    atomic_inc_and_test 1
    [...]

24.2. SystemTap での関数呼び出しのトレース

para-callgraph.stp SystemTap スクリプトを使用して、関数呼び出しと関数戻りを追跡できます。

手順

  • para-callgraph.stp スクリプトを実行します。
# stap --example para-callgraph.stp 'argument1' 'argument2'

para-callgraph.stp スクリプトは、コマンドライン引数を 2 つ取ります。

  1. その開始または終了が追跡対象となっている関数の名前。
  2. オプションのトリガー関数。スレッド単位でのトレースを有効または無効にします。trigger function が終了していなければ、各スレッドにおける追跡は継続されます。

以下の例を見てみましょう。

# stap -wv --example para-callgraph.stp 'kernel.function("*@fs/proc.c*")' 'kernel.function("vfs_read")' -c "cat /proc/sys/vm/* || true"

ここで、

  • -w : 警告を表示しません。
  • -v : 起動したカーネルの出力を表示します。
  • -c コマンド : コマンドの実行中に関数呼び出しを数えるように SystemTap に指示します (この例では /bin/true)。

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

[...]
   267 gnome-terminal(2921): <-do_sync_read return=0xfffffffffffffff5
   269 gnome-terminal(2921):<-vfs_read return=0xfffffffffffffff5
     0 gnome-terminal(2921):->fput file=0xffff880111eebbc0
     2 gnome-terminal(2921):<-fput
     0 gnome-terminal(2921):->fget_light fd=0x3 fput_needed=0xffff88010544df54
     3 gnome-terminal(2921):<-fget_light return=0xffff8801116ce980
     0 gnome-terminal(2921):->vfs_read file=0xffff8801116ce980 buf=0xc86504 count=0x1000 pos=0xffff88010544df48
     4 gnome-terminal(2921): ->rw_verify_area read_write=0x0 file=0xffff8801116ce980 ppos=0xffff88010544df48 count=0x1000
     7 gnome-terminal(2921): <-rw_verify_area return=0x1000
    12 gnome-terminal(2921): ->do_sync_read filp=0xffff8801116ce980 buf=0xc86504 len=0x1000 ppos=0xffff88010544df48
    15 gnome-terminal(2921): <-do_sync_read return=0xfffffffffffffff5
    18 gnome-terminal(2921):<-vfs_read return=0xfffffffffffffff5
     0 gnome-terminal(2921):->fput file=0xffff8801116ce980

24.3. SystemTap でカーネルとユーザー空間で費やす時間の決定

thread-times.stp SystemTap スクリプトを使用して、指定したスレッドがカーネルまたはユーザー空間で費やす時間を指定できます。

手順

  • thread-times.stp スクリプトを実行します。

    # stap --example thread-times.stp

    このスクリプトでは、5 秒間に CPU 時間を使用している上位 20 のプロセスと、サンプル中に作成された CPU ティックの合計数が表示されます。このスクリプトの出力は、各プロセスが使用した CPU 時間のパーセント表示と、その時間がカーネルスペースかユーザースペースで費やされたかも示します。

    tid   %user %kernel (of 20002 ticks)
      0   0.00%  87.88%
    32169   5.24%   0.03%
    9815   3.33%   0.36%
    9859   0.95%   0.00%
    3611   0.56%   0.12%
    9861   0.62%   0.01%
    11106   0.37%   0.02%
    32167   0.08%   0.08%
    3897   0.01%   0.08%
    3800   0.03%   0.00%
    2886   0.02%   0.00%
    3243   0.00%   0.01%
    3862   0.01%   0.00%
    3782   0.00%   0.00%
    21767   0.00%   0.00%
    2522   0.00%   0.00%
    3883   0.00%   0.00%
    3775   0.00%   0.00%
    3943   0.00%   0.00%
    3873   0.00%   0.00%

24.4. SystemTap を使用したポーリングアプリケーションの監視

timeout.stp SystemTap スクリプトを使用して、ポーリングしているアプリケーションを特定し、監視できます。これにより、不要なポーリングや過剰なポーリングの追跡が可能になります。これにより、CPU 使用率や消費電力の改善領域を特定しやすくなります。

手順

  • timeout.stp スクリプトを実行します。

    # stap --example timeout.stp

    このスクリプトは、各アプリケーションが時間とともに以下のシステムコールを使用する回数を追跡します。

  • poll
  • select
  • epoll
  • itimer
  • futex
  • nanosleep
  • signal

この例の出力では、どのプロセスがどのシステムコールを使用したか、また何回目のシステムコールを使用したかを確認できます。

uid |   poll  select   epoll  itimer   futex nanosle  signal| process
28937 | 148793       0       0    4727   37288       0       0| firefox
22945 |      0   56949       0       1       0       0       0| scim-bridge
  0 |      0       0       0   36414       0       0       0| swapper
4275 |  23140       0       0       1       0       0       0| mixer_applet2
4191 |      0   14405       0       0       0       0       0| scim-launcher
22941 |   7908       1       0      62       0       0       0| gnome-terminal
4261 |      0       0       0       2       0    7622       0| escd
3695 |      0       0       0       0       0    7622       0| gdm-binary
3483 |      0    7206       0       0       0       0       0| dhcdbd
4189 |   6916       0       0       2       0       0       0| scim-panel-gtk
1863 |   5767       0       0       0       0       0       0| iscsid

24.5. SystemTap で最も頻繁に使用されるシステムコールの追跡

topsys.stp SystemTap スクリプトを使用すると、5 秒間隔でシステムが使用するシステムコールの上位 20 件を一覧表示できます。また、同期間に各システムコールが使用された回数も表示されます。

手順

  • topsys.stp スクリプトを実行します。

    # stap --example topsys.stp

    以下の例を見てみましょう。

    # stap -v --example topsys.stp

    ここで、-v は、起動しているカーネルの出力を表示します。

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

--------------------------------------------------------------
                  SYSCALL      COUNT
             gettimeofday       1857
                     read       1821
                    ioctl       1568
                     poll       1033
                    close        638
                     open        503
                   select        455
                    write        391
                   writev        335
                    futex        303
                  recvmsg        251
                   socket        137
            clock_gettime        124
           rt_sigprocmask        121
                   sendto        120
                setitimer        106
                     stat         90
                     time         81
                sigreturn         72
                    fstat         66
--------------------------------------------------------------

24.6. SystemTap を使用したプロセスごとのシステムコールボリュームの追跡

syscalls_by_proc.stp SystemTap スクリプトを使用すると、どのプロセスが最大量のシステムコールを実行しているかを確認できます。これは、システムコールのほとんどを実行している 20 のプロセスを表示します。

手順

  • syscalls_by_proc.stp スクリプトを実行します。

    # stap --example syscalls_by_proc.stp

    syscalls_by_proc.stp スクリプトの出力は、以下のようになります。

    Collecting data... Type Ctrl-C to exit and display results
    #SysCalls  Process Name
    1577       multiload-apple
    692        synergyc
    408        pcscd
    376        mixer_applet2
    299        gnome-terminal
    293        Xorg
    206        scim-panel-gtk
    95         gnome-power-man
    90         artsd
    85         dhcdbd
    84         scim-bridge
    78         gnome-screensav
    66         scim-launcher
    [...]

第25章 SystemTap でのディスクおよび I/O アクティビティーの監視

以下のセクションでは、ディスクおよび I/O アクティビティーを監視するスクリプトを説明します。

25.1. SystemTap でのディスクの読み取り/書き込みトラフィックの概要

disktop.stp SystemTap スクリプトを使用して、システムで最も重いディスク読み取りおよび書き込みを実行しているプロセスを特定できます。

手順

  • disktop.stp スクリプトを実行します。

    # stap --example disktop.stp

    このスクリプトでは、ディスクへの最も重い読み取りまたは書き込みを行う上位 10 プロセスが表示されます。

    この出力には、一覧表示されているプロセスごとに、以下のデータが含まれます。

    UID
    ユーザー ID。0 のユーザー ID は、root ユーザーを指します。
    PID
    一覧表示されているプロセスの ID。
    PPID
    一覧表示されているプロセスの親プロセスのプロセス ID。
    CMD
    一覧表示されているプロセスの名前。
    デバイス
    一覧表示されているプロセスが、読み取りまたは書き込みを行っているストレージデバイス。
    T
    一覧表示されているプロセスが実行するアクションの種類。W は書き込みを、R は読み取りを指します。
    BYTES
    ディスクに対して読み書きされるデータの量。

disktop.stp スクリプトの出力は、以下のようになります。

[...]
Mon Sep 29 03:38:28 2008 , Average:  19Kb/sec, Read: 7Kb, Write: 89Kb
UID      PID     PPID                       CMD   DEVICE    T    BYTES
0    26319    26294                   firefox     sda5    W        90229
0     2758     2757           pam_timestamp_c     sda5    R         8064
0     2885        1                     cupsd     sda5    W         1678
Mon Sep 29 03:38:38 2008 , Average:   1Kb/sec, Read: 7Kb, Write: 1Kb
UID      PID     PPID                       CMD   DEVICE    T    BYTES
0     2758     2757           pam_timestamp_c     sda5    R         8064
0     2885        1                     cupsd     sda5    W         1678

25.2. SystemTap での各ファイルの読み取りまたは書き込みの I/O 時間の追跡

iotime.stp SystemTap スクリプトを使用して、各プロセスが任意のファイルへの読み取りまたは書き込みを行う場合にかかる時間を監視できます。これにより、システムへの読み込みに時間がかかっているファイルを判断する上で役立ちます。

手順

  • iotime.stp スクリプトを実行します。

    # stap --example iotime.stp

    このスクリプトは、システムコールが開いたり、閉じたり、読み込みを行ったり、ファイルに書き込んだりするたびに追跡します。システムコールがアクセスするファイルごとに、読み取りもしくは書き込みが終了するまでの時間をマイクロ秒単位でカウントし、読み取りもしくは書き込みされたデータ量をバイト単位で追跡します。

    この出力には、以下が含まれます。

  • タイムスタンプ (マイクロ秒)
  • プロセス ID およびプロセス名
  • access フラグまたは iotime フラグ
  • アクセスしたファイル

    プロセスがデータの読み取りまたは書き込みが可能であった場合は、アクセス行とiotime行のペアが一緒に表示されます。アクセス行は、指定したプロセスがファイルのアクセスを開始した時間を指します。アクセス行の末尾には、読み取りまたは書き込みのデータ量が表示されます。iotime の行には、プロセスが読み取りまたは書き込みを実行するのにかかった時間がマイクロ秒単位で表示されます。

iotime.stp スクリプトの出力は、以下のようになります。

[...]
825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11
[...]

25.3. SystemTap で累積 I/O の追跡

traceio.stp SystemTap スクリプトを使用して、システムへの I/O の累積量を追跡できます。

手順

  • traceio.stp スクリプトを実行します。

    # stap --example traceio.stp

    このスクリプトでは、時間の経過とともに I/O トラフィックを生成する上位 10 個の実行ファイルが出力されます。また、これらの実行可能ファイルが実行した I/O 読み取りおよび書き込みの累積量も追跡します。この情報は降順で 1 秒ごとに追跡、プリントアウトされます。

    traceio.stp スクリプトの出力は、以下のようになります。

[...]
           Xorg r:   583401 KiB w:        0 KiB
       floaters r:       96 KiB w:     7130 KiB
multiload-apple r:      538 KiB w:      537 KiB
           sshd r:       71 KiB w:       72 KiB
pam_timestamp_c r:      138 KiB w:        0 KiB
        staprun r:       51 KiB w:       51 KiB
          snmpd r:       46 KiB w:        0 KiB
          pcscd r:       28 KiB w:        0 KiB
     irqbalance r:       27 KiB w:        4 KiB
          cupsd r:        4 KiB w:       18 KiB
           Xorg r:   588140 KiB w:        0 KiB
       floaters r:       97 KiB w:     7143 KiB
multiload-apple r:      543 KiB w:      542 KiB
           sshd r:       72 KiB w:       72 KiB
pam_timestamp_c r:      138 KiB w:        0 KiB
        staprun r:       51 KiB w:       51 KiB
          snmpd r:       46 KiB w:        0 KiB
          pcscd r:       28 KiB w:        0 KiB
     irqbalance r:       27 KiB w:        4 KiB
          cupsd r:        4 KiB w:       18 KiB

25.4. SystemTap を使用した、特定デバイスでの I/O アクティビティーの監視

traceio2.stp SystemTap スクリプトを使用して、特定のデバイスにおける I/O アクティビティーを監視できます。

手順

  • traceio2.stp スクリプトを実行します。
# stap --example traceio2.stp 'argument'

このスクリプトは、デバイス番号全体を引数として取ります。この番号を確認するには、以下のコマンドを実行します。

# stat -c "0x%D" directory

監視するデバイスのディレクトリー がある場所。

この出力には、以下が含まれます。

  • 読み取りまたは書き込みを実行するプロセスの名前と ID
  • 実行中の機能 (vfs_read または vfs_write)
  • カーネルデバイス番号

以下のような# stap traceio2.stp 0x805の出力を検討してください。

[...]
synergyc(3722) vfs_read 0x800005
synergyc(3722) vfs_read 0x800005
cupsd(2889) vfs_write 0x800005
cupsd(2889) vfs_write 0x800005
cupsd(2889) vfs_write 0x800005
[...]

25.5. SystemTap を使用したファイルの読み取りと書き込みの監視

inodewatch.stp SystemTap スクリプトを使用すると、ファイルの読み取りと書き込みをリアルタイムで監視できます。

手順

  • inodewatch.stp スクリプトを実行します。
# stap --example inodewatch.stp 'argument1' 'argument2' 'argument3'

スクリプト inodewatch.stp では、コマンドラインの引数を 3 つ使用します。

  1. ファイルのメジャーデバイス番号。
  2. ファイルのマイナーデバイス番号。
  3. ファイルの inode 番号。

この番号は、以下を使用して取得できます。

# stat -c '%D %i' filename

filename は絶対パスです。

以下の例を見てみましょう。

# stat -c '%D %i' /etc/crontab

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

805 1078319

ここで、

  • 805 は、ベース 16 (16 進数) のデバイス番号です。最後の 2 桁はマイナーデバイス番号で、残りの2 桁はメジャー番号です。
  • 1078319 は、inode 番号です。

/etc/crontab の監視を開始するには、次のコマンドを実行します。

# stap inodewatch.stp 0x8 0x05 1078319

最初の 2 つの引数では、基数 16 の数に 0x の接頭辞を使用する必要があります。

この出力には、以下が含まれます。

  • 読み取りまたは書き込みを実行するプロセスの名前と ID
  • 実行中の機能 (vfs_read または vfs_write)
  • カーネルデバイス番号

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

cat(16437) vfs_read 0x800005/1078319
cat(16437) vfs_read 0x800005/1078319