Red Hat Training

A Red Hat training course is available for RHEL 8

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

Red Hat Enterprise Linux 8

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

概要

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

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

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章 パフォーマンス監視オプションの概要

以下は、Red Hat Enterprise Linux 8 で利用可能なパフォーマンス監視および設定ツールの一部です。

  • Performance Co-Pilot (pcp) は、システムレベルのパフォーマンス測定の監視、視覚化、保存、および分析に使用されます。これにより、リアルタイムデータの監視および管理、および履歴データのログと取得が可能になります。
  • Red Hat Enterprise Linux 8 は、ランレベル 5 以外のシステムを監視するためにコマンドラインから使用できる複数のツールを提供します。以下は、ビルトインのコマンドラインツールです。

    • top は、procps-ng パッケージで提供されます。これにより、実行中のシステムのプロセスの動的ビューが提供されます。システムの概要や Linux カーネルが現在管理しているタスクの一覧など、さまざまな情報が表示されます。
    • psprocps-ng パッケージで提供されます。これは、アクティブなプロセスの選択したグループのスナップショットをキャプチャーします。デフォルトでは、検査されたグループは、現在のユーザーが所有し、ps コマンドが実行される端末に関連付けられているプロセスに制限されます。
    • 仮想メモリーの統計 (vmstat) は、procps-ng パッケージで提供されます。システムのプロセス、メモリー、ページング、ブロックの入出力、割り込み、および CPU アクティビティーの即時レポートを提供します。
    • System activity reporter (sar) は sysstat パッケージで提供されます。過去に発生したシステムアクティビティーに関する情報を収集し、報告します。
  • perf は、ハードウェアパフォーマンスカウンターとカーネルトレースポイントを使用して、システム上の他のコマンドやアプリケーションの影響を追跡します。
  • bcc-tools は BPF コンパイラーコレクション (BCC) に使用され ます。これは、カーネルアクティビティーを監視する 100 を超える eBPF スクリプトを提供します。各ツールの詳細は、ツールの使用方法と、ツールが実行する機能について説明する man ページを参照してください。
  • turbostatkernel-tools パッケージで提供されます。Intel 64 プロセッサーのプロセッサートポロジー、周波数、アイドル時の電力状態の統計、温度、および電力使用量について報告します。
  • iostatsysstat パッケージで提供されます。管理者が物理ディスク間で IO 負荷のバランスを取る方法を決定できるように、システム IO デバイスのロードを監視および報告します。
  • irqbalance は、システムパフォーマンスを改善するために、複数のプロセッサーにハードウェア割り込みを分散します。
  • ss はソケットに関する統計情報を出力するため、管理者は時間とともにデバイスのパフォーマンスを評価することができます。Red Hat は、Red Hat Enterprise Linux 8 で ss over netstat を使用することを推奨します。
  • numastatnumactl パッケージで提供されます。デフォルトでは、numastat は、カーネルメモリーアロケーターからノードごとの NUMA ヒットしたシステム統計を表示します。最適なパフォーマンスは、高い numa_hit 値および低い numa_miss 値によって示されます。
  • numad は NUMA アフィニティーの自動管理デーモンです。NUMA リソースの割り当て、管理、システムのパフォーマンスを動的に改善するシステム内の NUMA トポロジーとリソースの使用状況を監視します。
  • SystemTap は、特にカーネルアクティビティーなど、オペレーティングシステムのアクティビティーを監視および分析します。
  • valgrind は、アプリケーションを合成 CPU で実行し、実行中の既存のアプリケーションコードをインストルメント化してアプリケーションを分析します。次に、アプリケーション実行に関連する各プロセスをユーザー指定のファイル、ファイル記述子、またはネットワークソケットに明確に識別するコメントを出力します。また、メモリーリークを見つける場合にも便利です。
  • pqosintel-cmt-cat パッケージで提供されます。最新の Intel プロセッサーで CPU キャッシュとメモリー帯域幅を監視および制御します。

関連情報

第2章 Tuned の使用

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

2.1. Tuned の目的

Tuned は、システムを監視し、特定の作業負荷の下でパフォーマンスを最適化するサービスです。Tuned のコアとなるのは、さまざまなユースケースに合わせてシステムを調整する プロファイル です。

Tuned では、次のようなユースケースのために、いくつかの事前定義プロファイルとともに配布されています。

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

各プロファイル向けに定義されたルールを変更し、特定のデバイスのチューニング方法をカスタマイズできます。他のプロフィールに切り替えたり、Tuned を無効にした場合は、以前のプロファイルによりシステム設定に加えられたすべての変更が、元の状態に戻ります。

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

2.2. Tuned プロファイル

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

Tuned で提供したプロファイルは、次のカテゴリーに分類されます。

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

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

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

プロファイル設定の構文

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

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

関連情報

  • tuned.conf(5) man ページ

2.3. デフォルトの Tuned プロファイル

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

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

コンピュートノード

throughput-performance

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

仮想マシン

virtual-guest

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

その他のケース

balanced

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

関連情報

  • tuned.conf(5) man ページ

2.4. マージされた Tuned プロファイル

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

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

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

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

# tuned-adm profile virtual-guest powersave
警告

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

関連情報

  • tuned.conf(5) man ページ

2.5. Tuned プロファイルの場所

Tuned は、次のディレクトリーにプロファイルを格納します。

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

関連情報

  • tuned.conf(5) man ページ

2.6. RHEL と一緒に配布される Tuned プロファイル

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

注記

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

balanced

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

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

powersave

省電力パフォーマンスを最大化するプロファイル。実際の電力消費を最小化するためにパフォーマンスを調整できます。現行の Tuned リリースでは、SATA ホストアダプターの USB 自動サスペンド、WiFi の省電力、およびアグレッシブリンク電源管理 (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 パラメーターの調整を行います。

これは、energy_ performance_preference および scaling_ governor 属性を パフォーマンスプロファイル に変更する latency- 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 8 仮想マシンおよび VMWare ゲスト向けプロファイル。仮想メモリーのスワップの減少や、ディスクの readahead 値の増加などが行われます。ディスクバリアは無効になりません。

throughput-performance プロファイルを継承し、energy_performance_preference および scaling_governor 属性を パフォーマンスプロファイル に変更します。

virtual-host

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

throughput-performance プロファイルを継承し、energy_performance_preference および scaling_governor 属性を パフォーマンスプロファイル に変更します。

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

cpu-partitioning プロファイルは、システムの CPU を、分離されたハウスキーピングの CPU に分割します。分離された CPU のジッターと割り込みを減らすために、プロファイルは分離された CPU を、ユーザー空間プロセス、可動カーネルスレッド、割り込みハンドラー、およびカーネルタイマーから削除します。

ハウスキーピング CPU は、すべてのサービス、シェルプロセス、およびカーネルスレッドを実行できます。

/etc/tuned/cpu-partitioning-variables.conf ファイルで cpu-partitioning プロファイルを設定できます。設定オプションは以下のようになります。

isolated_cores=cpu-list
分離する CPU を一覧表示します。分離された CPU の一覧はコンマで区切るか、ユーザーが範囲を指定できます。3-5 のようにハイフンを使用して範囲を指定できます。このオプションは必須です。この一覧にない CPU は、自動的にハウスキーピング CPU と見なされます。
no_balance_cores=cpu-list
システム全体のプロセスの負荷分散時に、カーネルに考慮されない CPU の一覧を表示します。このオプションは任意です。通常、これは isolated_cores と同じリストです。

cpu-partitioning の詳細は、man ページの tuned-profiles-cpu-partitioning(7) を参照してください。

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

2.7. RHEL で配布されるリアルタイム Tuned プロファイル

リアルタイムプロファイルは、リアルタイムカーネルを実行するシステムを対象としています。特殊なカーネルビルドなしでは、システムはリアルタイムになりません。RHEL では、このプロファイルは追加のリポジトリーから利用できます。

利用できるリアルタイムプロファイルは以下の通りです。

リアルタイム

ベアメタルのリアルタイムシステムで使用します。

tuned-profiles-realtime パッケージにより提供されます。これは、RT リポジトリーまたは NFV リポジトリーから入手できます。

realtime-virtual-host

リアルタイムに設定された仮想ホストで使用します。

NFV リポジトリーから利用できる tuned-profiles-nfv-host パッケージにより提供されます。

realtime-virtual-guest

リアルタイムに設定された仮想化ゲストで使用します。

NFV リポジトリーから利用できる tuned-profiles-nfv-guest パッケージにより提供されます。

2.8. Tuned の静的および動的のチューニング

このセクションでは、Tuned が提供するシステムチューニングの 2 つのカテゴリー (静的 および 動的) の違いを説明します。

静的なチューニング
主に、事前定義された sysctl 設定および sysfs 設定の適用と、ethtool などの複数の設定ツールのワンショットアクティベーションから構成されます。
動的チューニング

システムのアップタイム中に、さまざまなシステムコンポーネントがどのように使用されているかを監視します。Tuned は、その監視情報に基づいてシステム設定を動的に調整します。

たとえば、ハードドライブは起動時およびログイン時に頻繁に使用されますが、Web ブラウザーや電子メールクライアントなどのアプリケーションをユーザーが主に使用する場合はほとんど使用されません。同様に、CPU とネットワークデバイスは、異なるタイミングで使用されます。Tuned は、これらのコンポーネントのアクティビティーを監視し、その使用の変化に反応します。

デフォルトでは、動的チューニングは無効になっています。これを有効にするには、/etc/tuned/tuned-main.conf ファイルを編集して、dynamic_tuning オプションを 1 に変更します。Tuned は、その後、定期的にシステム統計を分析し、それらを使用してシステム調整設定を更新します。これらの更新間の時間間隔を秒単位で設定するには、update_interval オプションを使用します。

現在実装されている動的チューニングアルゴリズムは、パフォーマンスと省電力のバランスを取ろうとし、パフォーマンスプロファイルで無効になります。個々のプラグインの動的調整は、Tuned プロファイルで有効または無効にできます。

例2.2 ワークステーションでの静的および動的のチューニング

一般的なオフィスワークステーションでは、イーサネットネットワークインターフェースは常に非アクティブの状態です。少数の電子メールのみが出入りするか、一部の Web ページが読み込まれている可能性があります。

ネットワークインターフェースは、このような読み込みではデフォルトではフルで稼働しますが、常にフルスピードで稼働する必要はありません。Tuned には、ネットワークデバイスの監視および調整のプラグインがあり、これによりこの低いアクティビティーを検出して、自動的にそのインターフェースの速度を下げることができるため、通常は消費電力が少なくなります。

DVD イメージをダウンロードしているとき、または大きな添付ファイル付きの電子メールが開いているときなど、インターフェースのアクティビティーが長期間にわたって増加した場合は、Tuned がこれを検出し、アクティビティーレベルが高い間にインターフェースの速度を最大に設定します。

この原則は、CPU およびディスクの他のプラグインにも使用されます。

2.9. Tuned の no-daemon モード

no-daemon モードの Tuned を実行できます。これには常駐メモリーは必要ありません。このモードでは、Tuned が設定を適用して終了します。

デフォルトでは、このモードには、以下のように多くの Tuned 機能がないため、no-daemon モードが無効になっています。

  • D-Bus サポート
  • ホットプラグサポート
  • 設定のロールバックサポート

no-daemon モードを有効にするには、/etc/tuned/tuned-main.conf ファイルに以下の行を含めます。

daemon = 0

2.10. Tuned のインストールおよび有効化

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

手順

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

    # yum install tuned
  2. tuned サービスを有効にして起動します。

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

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

2.11. 利用可能な Tuned プロファイルの一覧表示

この手順は、システムで現在利用できる Tuned プロファイルの一覧を表示します。

手順

  • システムで利用可能な Tuned プロファイルの一覧を表示するには、次のコマンドを実行します。

    $ tuned-adm list
    
    Available profiles:
    - 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

関連情報

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

2.12. Tuned プロファイルの設定

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

前提条件

手順

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

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

    # tuned-adm profile selected-profile

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

    # tuned-adm profile profile1 profile2

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

関連情報

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

2.13. Tuned の無効化

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

手順

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

    # tuned-adm off

    tuned サービスが再開したあと、再度調整が適用されます。

  • または、tuned サービスを永続的に停止して無効にするには、次のコマンドを実行します。

    # systemctl disable --now tuned

関連情報

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

第3章 Tuned プロファイルのカスタマイズ

使用目的に合わせてシステムパフォーマンスを最適化するための Tuned プロファイルを作成または変更できます。

前提条件

  • 詳細は「 Tuned のインストールおよび有効化」で説明されているように 、Tuned をインストールして有効にします。

3.1. Tuned プロファイル

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

Tuned で提供したプロファイルは、次のカテゴリーに分類されます。

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

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

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

プロファイル設定の構文

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

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

関連情報

  • tuned.conf(5) man ページ

3.2. デフォルトの Tuned プロファイル

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

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

コンピュートノード

throughput-performance

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

仮想マシン

virtual-guest

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

その他のケース

balanced

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

関連情報

  • tuned.conf(5) man ページ

3.3. マージされた Tuned プロファイル

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

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

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

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

# tuned-adm profile virtual-guest powersave
警告

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

関連情報

  • tuned.conf(5) man ページ

3.4. Tuned プロファイルの場所

Tuned は、次のディレクトリーにプロファイルを格納します。

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

関連情報

  • tuned.conf(5) man ページ

3.5. Tuned プロファイル間の継承

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

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

[main]
include=parent

プロファイルの設定はすべて、この プロファイルに読み込まれます。以下のセクションでは、 プロファイルは、 プロファイルから継承された特定の設定をオーバーライドするか、 プロファイルに表示されない新しい設定を追加します。

/usr/lib/tuned/ にあらかじめインストールしておいたプロファイルでパラメーターをいくつか調整するだけで、/etc/tuned/ に独自の プロファイルを作成できます。

Tuned のアップグレード後などに、 プロファイルが更新すると、この変更は プロファイルに反映されます。

例3.2 バランスの取れた省電力プロファイル

以下は、balanced プロファイルを拡張し、すべてのデバイスの Aggressive Link Power Management (ALPM) を最大省電力に設定するカスタムプロファイルの例です。

[main]
include=balanced

[scsi_host]
alpm=min_power

関連情報

  • tuned.conf(5) man ページ

3.6. Tuned の静的および動的のチューニング

このセクションでは、Tuned が提供するシステムチューニングの 2 つのカテゴリー (静的 および 動的) の違いを説明します。

静的なチューニング
主に、事前定義された sysctl 設定および sysfs 設定の適用と、ethtool などの複数の設定ツールのワンショットアクティベーションから構成されます。
動的チューニング

システムのアップタイム中に、さまざまなシステムコンポーネントがどのように使用されているかを監視します。Tuned は、その監視情報に基づいてシステム設定を動的に調整します。

たとえば、ハードドライブは起動時およびログイン時に頻繁に使用されますが、Web ブラウザーや電子メールクライアントなどのアプリケーションをユーザーが主に使用する場合はほとんど使用されません。同様に、CPU とネットワークデバイスは、異なるタイミングで使用されます。Tuned は、これらのコンポーネントのアクティビティーを監視し、その使用の変化に反応します。

デフォルトでは、動的チューニングは無効になっています。これを有効にするには、/etc/tuned/tuned-main.conf ファイルを編集して、dynamic_tuning オプションを 1 に変更します。Tuned は、その後、定期的にシステム統計を分析し、それらを使用してシステム調整設定を更新します。これらの更新間の時間間隔を秒単位で設定するには、update_interval オプションを使用します。

現在実装されている動的チューニングアルゴリズムは、パフォーマンスと省電力のバランスを取ろうとし、パフォーマンスプロファイルで無効になります。個々のプラグインの動的調整は、Tuned プロファイルで有効または無効にできます。

例3.3 ワークステーションでの静的および動的のチューニング

一般的なオフィスワークステーションでは、イーサネットネットワークインターフェースは常に非アクティブの状態です。少数の電子メールのみが出入りするか、一部の Web ページが読み込まれている可能性があります。

ネットワークインターフェースは、このような読み込みではデフォルトではフルで稼働しますが、常にフルスピードで稼働する必要はありません。Tuned には、ネットワークデバイスの監視および調整のプラグインがあり、これによりこの低いアクティビティーを検出して、自動的にそのインターフェースの速度を下げることができるため、通常は消費電力が少なくなります。

DVD イメージをダウンロードしているとき、または大きな添付ファイル付きの電子メールが開いているときなど、インターフェースのアクティビティーが長期間にわたって増加した場合は、Tuned がこれを検出し、アクティビティーレベルが高い間にインターフェースの速度を最大に設定します。

この原則は、CPU およびディスクの他のプラグインにも使用されます。

3.7. Tuned プラグイン

プラグインは、Tuned がシステムのさまざまなデバイスを監視または最適化するために使用する Tuned プロファイルのモジュールです。

Tuned は、2 種類のプラグインを使用します。

プラグインの監視

モニタリングプラグインは、稼働中のシステムから情報を取得するために使用されます。監視プラグインの出力は、動的チューニング向けチューニングプラグインで使用できます。

監視プラグインは、有効ないずれかのチューニングプラグインでメトリクスが必要な場合に必ず自動的にインスタンス化されます。2 つのチューニングプラグインで同じデータが必要な場合は、監視プラグインのインスタンスが 1 つだけ作成され、データが共有されます。

プラグインのチューニング
各チューニングプラグインにより、個別サブシステムがチューニングされ、tuned プロファイルから入力される複数のパラメーターが取得されます。各サブシステムには、チューニングプラグインの個別インスタンスで処理される複数のデバイス (複数の CPU やネットワークカードなど) を含めることができます。また、個別デバイスの特定の設定もサポートされます。

Tuned プロファイルのプラグインの構文

プラグインインスタンスが記述されるセクションは、以下のように書式化されます。

[NAME]
type=TYPE
devices=DEVICES
NAME
ログで使用されるプラグインインスタンスの名前です。これは、任意の文字列です。
TYPE
チューニングプラグインのタイプです。
DEVICES

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

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

例3.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 の行を省略することができます。タイプと同様に、インスタンスは名前で参照されます。上記の例は、以下のように書き換えることができます。

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

[disk]
devices=sdb*
disable_barriers=false

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

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

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

注記

Tuned には、調整プロファイルを有効または無効にする一環として、シェルコマンドを実行する機能が含まれています。これにより、Tuned に統合されていない機能を持つ Tuned プロファイルを拡張できます。

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

関連情報

  • tuned.conf(5) man ページ

3.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 パラメーターを使用して、実行ファイルへのパスを指定します。

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

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

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

[bootloader]
cmdline=quiet

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

[bootloader]
cmdline=isolcpus=2

3.9. Tuned プロファイルの変数

Tuned プロファイルがアクティベートされると、ランタイム時に展開されます。

Tuned 変数は、Tuned プロファイルで必要な入力量を減らします。

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

[variables]

variable_name=value

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

${variable_name}

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

3.10. Tuned プロファイルの組み込み関数

Tuned プロファイルがアクティブになると、ランタイム時に組み込み関数が拡張されます。

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

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

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

${f:function_name:argument_1:argument_2}

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

${i:PROFILE_DIR}

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

3.11. Tuned プロファイルで使用可能な組み込み関数

以下の組み込み関数は、Tuned プロファイルで利用できます。

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

Tuned が仮想マシン内またはベアメタル上で実行しているかどうかを確認します。

  • 仮想マシン内では、この関数が最初の引数を返します。
  • ベアメタルでは、この関数は、エラーが発生した場合でも 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 に圧縮します。

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

3.13. 既存の Tuned プロファイルの変更

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

前提条件

手順

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

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

    [main]
    include=parent-profile

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

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

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

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

検証手順

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

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

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

tuna ツールは、以下の操作を実行します。

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

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

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

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

手順

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

    # yum install tuna

検証手順

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

    # tuna -h

関連情報

  • tuna(8) の man ページ

4.2. tuna ツールを使用したシステムステータスの表示

この手順では、tuna コマンドラインインターフェース (CLI) ツールを使用してシステムの状態を表示する方法を説明します。

前提条件

手順

  • 現在のポリシーおよび優先度を表示するには、以下を実行します。

    # tuna --show_threads
                thread
    pid   SCHED_ rtpri affinity             cmd
    1      OTHER     0      0,1            init
    2       FIFO    99        0     migration/0
    3      OTHER     0        0     ksoftirqd/0
    4       FIFO    99        0      watchdog/0
  • PID に対応する特定のスレッドまたはコマンド名と一致する場合は、次のコマンドを実行します。

    # tuna --threads=pid_or_cmd_list --show_threads

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

  • tuna CLI を使用して CPU をチューニングするには、「tuna ツールを使用した CPU のチューニング」を参照してください。
  • tuna ツールを使用して IRQ をチューニングするには、「tuna ツールを使用した IRQ のチューニング」を参照してください。
  • 変更した設定を保存するには、以下を実行します。

    # tuna --save=filename

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

関連情報

  • tuna(8) の man ページ

4.3. tuna ツールを使用した CPU の調整

tuna ツールコマンドは、個別の CPU をターゲットとして指定できます。

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

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

この手順では、tuna CLI を使用して CPU を調整する方法を説明します。

前提条件

手順

  • コマンドの影響を受ける CPU の一覧を指定するには、次のコマンドを実行します。

    # tuna --cpus=cpu_list [command]

    cpu_list 引数は、コンマ区切りの CPU 番号の一覧です。例: --cpus=0,2CPU リストは、--cpus=”1-3 の範囲でも指定でき、CPU 1、2、および 3 を選択します。

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

    [command] を、--isolate に置き換えます。

  • CPU を分離するには、以下を実行します。

    # tuna --cpus=cpu_list --isolate
  • CPU を指定するには、以下を実行します。

    # tuna --cpus=cpu_list --include
  • 4 つ以上のプロセッサーを持つシステムを使用するには、すべての ssh スレッドを CPU 0 および 1 で実行し、CPU 2 および 3 のすべての http スレッドを実行する方法を表示します。

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

    このコマンドは、以下の操作を順次実行します。

    1. CPU 0 および 1 を選択します。
    2. ssh で開始するスレッドをすべて選択します。
    3. 選択したスレッドを選択した CPU に移動します。tuna は、ssh で始まるスレッドのアフィニティーマスクを適切な CPU に設定します。CPU は、数字で 0 および 1 で表すことができ、16 進マスクでは 0x3 で、またはバイナリーでは 11 として表現できます。
    4. CPU 一覧を 2 および 3 にリセットします。
    5. http で始まるすべてのスレッドを選択します。
    6. 選択したスレッドを指定された CPU に移動します。tuna は、http で始まるスレッドのアフィニティーマスクを指定された CPU に設定します。CPU は、16 進マスクで 0xC または 1100 のバイナリーで 2 および 3 で表すこともできます。

検証手順

  • 現在の設定を表示し、変更が想定どおりに実行されたことを確認します。

    # tuna --threads=gnome-sc\* --show_threads \
    --cpus=0 --move --show_threads --cpus=1 \
    --move --show_threads --cpus=+0 --move --show_threads
    
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        0     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav

    このコマンドは、以下の操作を順次実行します。

    1. gnome-sc スレッドで始まるすべてのスレッドを選択します。
    2. 選択したスレッドを表示して、ユーザーがアフィニティーマスクと RT の優先度を検証できるようにします。
    3. CPU 0 を選択します。
    4. gnome-sc スレッドを指定の CPU 0 に移動します。
    5. 移動の結果を表示します。
    6. CPU 一覧を CPU 1 にリセットします。
    7. gnome-sc スレッドを指定した CPU (CPU 1) に移動します。
    8. 移動の結果を表示します。
    9. CPU 一覧に CPU 0 を追加します。
    10. gnome-sc スレッドを、指定した CPU、CPU 0、および 1 に移動します。
    11. 移動の結果を表示します。

関連情報

  • /proc/cpuinfo ファイル
  • tuna(8) の man ページ

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

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

この手順では、tuna ツールを使用して IRQ を調整する方法を説明します。

前提条件

手順

  • 現在の IRQ とそれらのアフィニティーを表示するには、以下を実行します。

    # tuna --show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  • コマンドの影響を受ける IRQ の一覧を指定するには、次のコマンドを実行します。

    # tuna --irqs=irq_list [command]

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

    [command] を、--isolate に置き換えます。

  • 指定した CPU に割り込みを移動するには、以下を実行します。

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

    128 を irq_list 引数に置き換え、3 を cpu_list 引数に置き換えます。

    cpu_list 引数は、--cpus=0,2 などのコンマ区切り CPU 番号の一覧です。詳細は、「tuna ツールを使用した CPU の調整」を参照してください。

検証手順

  • 選択した IRQ の状態を、割り込みを指定の CPU に移動してから比較します。

    # tuna --irqs=128 --show_irqs
       # users            affinity
     128 iwlwifi                 3

関連情報

  • /procs/interrupts ファイル
  • tuna(8) の man ページ

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

システム管理者は、Ansible Automation Platform コントロールノードでメトリック RHEL システムロールを使用して、システムのパフォーマンスを監視することができます。

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

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

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

  • kdump
  • network
  • selinux
  • storage
  • certificate
  • kernel_settings
  • logging
  • metrics
  • nbde_client and nbde_server
  • timesync
  • tlog

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

関連情報

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

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

システムロールの用語

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

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

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

前提条件

手順

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

    # yum install rhel-system-roles

    Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンを使用できます。この場合は、次の手順を実行します。

    1. RHEL Ansible Engine リポジトリーを有効にします。

      # subscription-manager refresh
      
      # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
    2. Ansible Engine をインストールします。

      # yum install ansible

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

関連情報

5.4. ロールの適用

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

前提条件

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

    # yum install rhel-system-roles
  • RHEL システムロールを使用する Playbook を実行するには、ansible パッケージが必要です。Ansible Engine リポジトリーが有効になり、コントロールノードとして使用するシステムに ansible パッケージがインストールされていることを確認します。

    • Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンを使用できます。この場合は、次の手順を実行します。

      1. RHEL Ansible Engine リポジトリーを有効にします。

        # subscription-manager refresh
        # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
      2. Ansible Engine をインストールします。

        # yum install ansible
    • Red Hat Ansible Engine のサブスクリプションをお持ちの場合は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 に記載されている手順を行ってください。
  • 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.timesync
    注記

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

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

    SUBSYSTEM は、selinuxkdumpnetworktimesync、または storage などの必要なロールの名前に置き換えます。

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

      Playbook 実行コマンド:

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

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

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

表5.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: false

metrics_query_service

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

metrics_query_service: false

metrics_provider

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

metrics_provider: "pcp"

注記

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

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

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

前提条件

  • 監視するマシンに Red Hat Ansible Engine がインストールされている。
  • 監視するマシンに 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 インターフェースにアクセスします。

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

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

前提条件

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

手順

  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

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

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

前提条件

  • Playbook の実行に使用するマシンに Red Hat Ansible Engine がインストールされている。
  • 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 インターフェースにアクセスします。

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

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

前提条件

  • Playbook の実行に使用するマシンに Red Hat Ansible Engine がインストールされている。
  • 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://127.0.0.1?username=your_username" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

5.10. metrics システムロールを使用した SQL サーバーのメトリクスコレクションの設定および有効化

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

前提条件

  • 監視するマシンに Red Hat Ansible Engine がインストールされている。
  • 監視するマシンに rhel-system-roles パッケージがインストールされている。
  • Red Hat Enterprise Linux に Microsoft SQL Server をインストールし、SQL Server への「信頼できる」接続を確立している。
  • Red Hat Enterprise Linux 用の SQL Server の Microsoft ODBC ドライバーがインストールされている。

手順

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

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

    ---
    - hosts: localhost
      roles:
        - role: rhel-system-roles.metrics
          vars:
            metrics_from_sql: 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 パッケージで自動的にインストールされます。

第6章 PCP の設定

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

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

6.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 パッケージは、グラフィカルアプリケーションを提供します。yum install pcp-gui コマンドを実行して、pcp-gui パッケージをインストールします。詳細は「PCP Charts アプリケーションで PCP ログアーカイブをトレース 」を参照してください。

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

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

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

手順

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

    # yum 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

関連情報

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

関連情報

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

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

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

名前

説明

pmcd

PMCD (Performance Metric Collector Daemon)

pmie

Performance Metrics In difference Engine

pmlogger

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

pmmgr

ゼロ以上の設定ディレクトリーに従って、PMCD (Performance Metric Collector Daemon) を実行している、検出された一連のローカルおよびリモートのホストで PCP デーモンのコレクションを管理します。

pmproxy

PMCD (Performance Metric Collector Daemon) プロキシーサーバー

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

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

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

名前

説明

pcp

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

pcp-atop

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

pcp-dstat

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

pmchart

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

pmclient

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

pmcollectl

ライブシステムまたは Performance Co-Pilot アーカイブファイルのいずれかからシステムレベルデータを収集して表示します。

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 変数を表示または設定します。

pminfo

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

pmiostat

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

pmlc

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

pmlogcheck

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

pmlogconf

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

pmloglabel

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

pmlogsummary

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

pmprobe

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

pmrep

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

pmsocks

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

pmstat

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

pmstore

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

pmtrace

トレースの PMDA (Performance Metrics Domain Agent) にコマンドラインインターフェースを提供します。

pmval

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

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

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

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

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

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

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

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

前提条件

手順

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

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

関連情報

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

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

関連情報

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

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

前提条件

手順

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

    # yum 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. パブリック ゾーン を永続的に追加するように、ファイアウォールを設定します。

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

関連情報

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

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

前提条件

手順

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

    # yum 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_LOG_DIR/pmlogger/rhel7u4a -r -T24h10m -c config.rhel7u4a
    192.168.4.14 n n PCP_LOG_DIR/pmlogger/rhel6u10a -r -T24h10m -c config.rhel6u10a
    192.168.4.62 n n PCP_LOG_DIR/pmlogger/rhel8u1a -r -T24h10m -c config.rhel8u1a

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

関連情報

7.6. pmdumptext での PCP ログアーカイブの再生

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

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

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

前提条件

手順

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

    $ pmdumptext -t 5seconds -H -a 20170605 xfs.perdev.log.writes
    
    Time local::xfs.perdev.log.writes["/dev/mapper/fedora-home"] local::xfs.perdev.log.writes["/dev/mapper/fedora-root"]
    ? 0.000 0.000
    none count / second count / second
    Mon Jun 5 12:28:45 ? ?
    Mon Jun 5 12:28:50 0.000 0.000
    Mon Jun 5 12:28:55 0.200 0.200
    Mon Jun 5 12:29:00 6.800 1.000

    上記の例では、アーカイブに 5 秒 間隔で収集された xfs.perdev.log メトリックのデータを表示し、すべてのヘッダーを表示します。

関連情報

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

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

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

8.1. pmda-postfix での postfix の監視

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

前提条件

手順

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

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

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

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

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

      # yum 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

関連情報

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

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

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

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

前提条件

手順

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

    # pmchart

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

関連情報

8.3. PCP を使用した SQL Server からのデータの収集

Red Hat Enterprise Linux 8.2 以降では、SQL Server エージェントは Performance Co-Pilot (PCP) で利用できます。これは、データベースのパフォーマンスの問題を監視および分析するのに役立ちます。

この手順では、システムの pcp を使用して Microsoft SQL Server のデータを収集する方法を説明します。

前提条件

  • Red Hat Enterprise Linux に Microsoft SQL Server をインストールし、SQL Server への「信頼できる」接続を確立している。
  • Red Hat Enterprise Linux 用の SQL Server の Microsoft ODBC ドライバーがインストールされている。

手順

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

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

    # yum install gcc-c++ python3-devel unixODBC-devel
    
    $ pip3 install pyodbc
  3. mssql エージェントをインストールします。

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

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

      username: user_name
      password: user_password

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

  4. 必要なパーミッションを追加します。

    # chown root:root /var/lib/pcp/pmdas/mssql/mssql.conf
    # chmod 400 /var/lib/pcp/pmdas/mssql/mssql.conf
  5. エージェントをインストールします。

    # 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 ログアーカイブをトレース 」を参照してください。

関連情報

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

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

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

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

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

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

前提条件

手順

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

    # cd /var/lib/pcp/pmdas/xfs/
  2. XFS PMDA を手動でインストールします。

    xfs]# ./Install
    
    You will need to choose an appropriate configuration for install of
    the “xfs” Performance Metrics Domain Agent (PMDA).
    
      collector     collect performance statistics on this system
      monitor       allow this system to monitor local and/or remote systems
      both          collector and monitor configuration for this system
    
    Please enter c(ollector) or m(onitor) or (both) [b]
    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 xfs metrics have appeared ... 149 metrics and 149 values
  3. collector の場合は c を、monitor の場合は m を、またはこれら両方の場合は b を入力して、PMDA ロールを選択します。PMDA インストールスクリプトから、以下の PMDA ロールのいずれかを指定するように求められます。

    • collector ロールを指定すると、現在のシステムでパフォーマンスメトリックを収集できます。
    • monitor ロールを指定すると、システムがローカルシステム、リモートシステム、またはその両方を監視できるようになります。

      デフォルトオプションは collectormonitor の両方です。これにより、ほとんどのシナリオで XFS PMDA は適切に動作できます。

検証手順

  • 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

関連情報

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

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

関連情報

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

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

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

メトリックグループ

提供されたメトリック

xfs.*

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

xfs.allocs.*

xfs.alloc_btree.*

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

xfs.block_map.*

xfs.bmap_tree.*

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

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

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

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

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

メトリックグループ

提供されたメトリック

xfs.perdev.*

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

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

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

xfs.perdev.block_map.*

xfs.perdev.bmap_tree.*

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

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

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

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

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

10.1. PCP の pcp-zeroconf での設定

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

手順

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

    # yum install pcp-zeroconf

検証手順

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

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

関連情報

10.2. grafana-server の設定

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

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

前提条件

手順

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

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

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

検証手順

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

関連情報

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

10.3. Grafana Web UI へのアクセス

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

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

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

前提条件

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

手順

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

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

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

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

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

    図10.1 Home Dashboard

    grafana home dashboard
    注記

    画面の右上隅にある grafana top corner settings icon アイコンは似ていますが、一般的な Dashboard 設定を制御します

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

  8. オプション: メニューから管理 プロファイル grafana logout option icon アイコンにカーソルを合わせ、Edit ProfileChange Password、または Sign out などの Preferences を変更します。

関連情報

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

10.4. PCP Redis の設定

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

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

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

前提条件

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

手順

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

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

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

      図10.2 PCP Redis: ホストの概要

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

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

      図10.3 PCP Redis クエリーパネル

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

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

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

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

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

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

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

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

前提条件

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

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

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

手順

  1. メニューから alerting bell icon Alerting アイコンにマウスをかざし、Notification channel Addチャネル にカーソルを合わせます。
  2. Add notification channel details ペインで、以下を実行します。

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

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

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

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

注記

Red Hat Enterprise Linux 8.3 以降から、PCP は scram-sha-256 認証メカニズムに対応します。

手順

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

    # yum 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

関連情報

10.8. PCP bpftrace のインストール

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

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

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

前提条件

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

手順

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

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

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

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

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

      図10.6 PCP bpftrace: システム分析

      pcp bpftrace システム分析

10.10. PCP Vector のインストール

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

前提条件

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

手順

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

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

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

      図10.7 PCP Vector: ホストの概要

      pcp vector ホストの概要
  5. メニューから pcp plugin in grafana Performance Co-Pilot プラグインにマウスをかざし、PCP Vector Checklist をクリックします。

    PCP チェックリストの pcp vector checklist troubleshooting doc help または pcp vector checklist warning 警告アイコンをクリックして、関連するトラブルシューティングまたは参照リンクを表示します。

    図10.8 Performance Co-Pilot / PCP Vector Checklist

    pcp vector checklist

第11章 Web コンソールを使用したシステムパフォーマンスの最適化

以下では、RHEL 8 Web コンソールでパフォーマンスプロファイルを設定し、選択したタスクに対してシステムのパフォーマンスを最適化する方法を説明します。

11.1. Web コンソールでのパフォーマンスチューニングオプション

Red Hat Enterprise Linux 8 には、以下のタスクに対してシステムを最適化する複数のパフォーマンスプロファイルが同梱されています。

  • デスクトップを使用するシステム
  • スループットパフォーマンス
  • レイテンシーパフォーマンス
  • ネットワークパフォーマンス
  • 電力の低消費
  • 仮想マシン

tuned サービスは、選択したプロファイルに一致するようにシステムオプションを最適化します。

Web コンソールでは、システムが使用するパフォーマンスプロファイルを設定できます。

関連情報

11.2. Web コンソールでのパフォーマンスプロファイルの設定

この手順では、Web コンソールを使用して、選択したタスクのシステムパフォーマンスを最適化します。

前提条件

手順

  1. RHEL 8 Web コンソールにログインします。詳細は「Web コンソールへのログイン」を参照してください。
  2. 概要 をクリックします。
  3. パフォーマンスプロファイル フィールドで、現在のパフォーマンスプロファイルをクリックします。

    cockpit performance profile pf4

  4. 必要に応じて、パフォーマンスプロファイルの変更 ダイアログボックスで、プロファイルを変更します。
  5. プロファイルの変更 をクリックします。

    cockpit performance profile change pf4

検証手順

  • Overview タブには、選択したパフォーマンスプロファイルが表示されます。

11.3. Web コンソールを使用したパフォーマンスの監視

Red Hat の Web コンソールは、トラブルシューティングに Utilization Saturation および Errors (USE) メソッドを使用します。新しいパフォーマンスメトリックページには、データの履歴ビューが時系列に整理されており、最新のデータが上部に表示されます。

ここでは、リソースの使用状況および飽和状況のイベント、エラー、およびグラフィカル表示を表示できます。

前提条件

  1. Web コンソールをインストールし、アクセスできることを確認します。詳細は、「Web コンソールのインストール」を参照してください。
  2. cockpit-pcp パッケージをインストールします。これにより、パフォーマンスメトリックの収集が可能になります。

    # yum install cockpit-pcp

手順

  1. RHEL 8 Web コンソールにログインします。詳細は「Web コンソールへのログイン」を参照してください。
  2. 概要 をクリックします。

    Web console Overview

  3. View details and history をクリックして、Performance Metrics を表示します。

    View details and history

    Performance metrics in Web console

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

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

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

注記

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

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

12.1. 利用可能なディスクスケジューラー

Red Hat Enterprise Linux 8 では、以下のマルチキューディスクスケジューラーに対応しています。

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

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

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

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

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

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

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

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

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

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

bfq を使用します。

仮想ゲスト

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

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

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

注記

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

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

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

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

手順

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

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

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

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

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

検証手順

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

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

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

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

手順

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

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

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

検証手順

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

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

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

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

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

前提条件

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

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

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

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

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

第14章 仮想マシンのパフォーマンスの最適化

仮想マシンでは、ホストと比べて、パフォーマンス低下が常に見られます。以下のセクションでは、この低下の理由を説明します。また、ハードウェアのインフラストラクチャーリソースを可能な限り効率的に使用できるように、RHEL 8 での仮想化によるパフォーマンスへの影響を最小限に抑える方法を説明します。

14.1. 仮想マシンのパフォーマンスに影響を及ぼすもの

仮想マシンは、ホストのユーザー空間プロセスとして実行します。したがって、ハイパーバイザーは、仮想マシンがホストシステムのリソースを使用できるように、ホストのシステムリソースを変換する必要があります。したがって、変換によりリソースの一部が消費されるため、仮想マシンのパフォーマンス効率は、ホストと同じにはなりません。

システムパフォーマンスにおける仮想化の影響

仮想マシンのパフォーマンス低下の理由には、以下のようなものがあります。

  • 仮想 CPU (vCPU) がホスト上のスレッドとして実装され、Linux スケジューラーで処理される。
  • 仮想マシンは、ホストカーネルから NUMA や Huge Page などの最適化機能を自動的に継承しない。
  • ホストのディスクおよびネットワーク I/O の設定が、仮想マシンのパフォーマンスに大きく影響する可能性がある。
  • ネットワークトラフィックは、一般的に、ソフトウェアベースのブリッジから仮想マシンに流れる。
  • ホストデバイスとそのモデルによっては、その特定のハードウェアのエミュレーションにより、オーバーヘッドが著しくなる可能性がある。

仮想化が仮想マシンのパフォーマンスに与える影響の重大度は、次のようなさまざまな要因の影響を受けます。

  • 同時に実行している仮想マシンの数
  • 各仮想マシンで使用される仮想デバイスのサイズ
  • 仮想マシンが使用するデバイスの種類

仮想マシンのパフォーマンス損失を減らす

RHEL 8は、仮想化のパフォーマンスへの悪影響を減らすのに使用できる多くの機能を提供します。以下に例を示します。

重要

仮想マシンのパフォーマンスのチューニングは、その他の仮想化機能に悪影響を与える可能性があります。たとえば、変更した仮想マシンの移行がより困難になります。

14.2. tuned で仮想マシンのパフォーマンスの最適化

tuned ユーティリティーは、CPU 集中型タスクや、ストレージネットワークスループットの応答などの特定のワークロードの特性に対して RHEL を調整するプロファイル配信メカニズムです。これにより、特定のユースケースで、パフォーマンスを強化し、電力消費を減らすように事前設定されたチューニングプロファイルを多数利用できます。これらのプロファイルを編集するか、または新規プロファイルを作成して、仮想化環境に適したパフォーマンスソリューション (仮想化環境を含む) を作成できます。

Red Hat は、RHEL 8 で仮想化を使用する場合は、次のプロファイルの使用を推奨します。

  • RHEL 8 仮想マシンの場合は、virtual-guest プロファイルを使用します。これは、一般的に適用された throughput-performance プロファイルをベースにしていますが、仮想メモリーのスワップは減少します。
  • RHEL 8 仮想ホストの場合は、virtual-host プロファイルを使用します。これにより、ダーティーメモリーページのより集中的なライトバックが有効になり、ホストのパフォーマンスを活用できます。

手順

特定の tuned プロファイルを有効にするには、以下を実行します。

  1. 利用可能な tuned プロファイルを一覧表示します。

    # tuned-adm list
    
    Available profiles:
    - balanced             - General non-specialized tuned profile
    - desktop              - Optimize for the desktop use-case
    [...]
    - virtual-guest        - Optimize for running inside a virtual guest
    - virtual-host         - Optimize for running KVM guests
    Current active profile: balanced
  2. (必要に応じて) 新しい tuned プロファイルを作成するか、既存の tuned プロファイルを編集します。

    詳細は「tuned プロファイルのカスタマイズ」を参照してください。

  3. tuned プロファイルをアクティベートします。

    # tuned-adm profile selected-profile
    • 仮想化ホストを最適化するには、virtual-host プロファイルを使用します。

      # tuned-adm profile virtual-host
    • RHEL ゲストオペレーティングシステムで、virtual-guest プロファイルを使用します。

      # tuned-adm profile virtual-guest

関連情報

14.3. 仮想マシンのメモリーの設定

仮想マシンのパフォーマンスを改善するために、追加のホスト RAM を仮想マシンに割り当てることができます。同様に、仮想マシンに割り当てるメモリー量を減らして、ホストメモリーを他の仮想マシンやタスクに割り当てることができます。

これらのアクションを実行するには、Web コンソール または コマンドラインインターフェース を使用します。

14.3.1. Web コンソールで仮想マシンのメモリーの追加と削除

仮想マシンのパフォーマンスを向上させるか、または仮想マシンが使用するホストリソースを解放するために、Web コンソールを使用して、仮想マシンに割り当てられたメモリーの量を調整できます。

前提条件

  • ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。

    1. 仮想マシンの設定に memballoon デバイスが含まれていることを確認します。

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      このコマンドで出力が表示され、モデルが none に設定されていない場合は、memballoon デバイスが存在します。

    2. ballon ドライバーがゲスト OS で実行されていることを確認します。

      • Windows ゲストでは、ドライバーは virtio-win ドライバーパッケージの一部としてインストールされます。手順は、「Windows 仮想マシンの準仮想化 KVM ドライバーのインストール」を参照してください。
      • Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、memballoon デバイスがあれば、アクティベートされます。
  • Web コンソールの仮想マシンプラグインをインストール して、Web コンソールを使用して仮想マシンを管理できるようにしてある。

手順

  1. 任意: 最大メモリーと、仮想マシンに現在使用されている最大メモリーの情報を取得します。これは、変更のベースラインとして、さらに検証用として機能します。

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. 仮想マシン インターフェースで、割り当てているメモリーを表示および設定する仮想マシンの名前がある行をクリックします。

    行が展開され、Overview ペインが表示されます。このペインには、選択した仮想マシンの基本情報が含まれます。

  3. 概要ペインで メモリー 行の値をクリックします。

    メモリー調整 ダイアログが表示されます。

    virt memory cockpit
  4. 選択した仮想マシンの仮想 CPU を設定します。

    • 最大割り当て - 仮想マシンがそのプロセスに使用できるホストメモリーの最大量を設定します。この値を増やすと、仮想マシンのパフォーマンスが低下する可能性が向上し、値を減らすことで、仮想マシンがホスト上にあるパフォーマンスフットプリントが低減します。

      仮想マシンをシャットダウンしてからでないと、最大メモリー割り当てを調整できません。

    • 現在の割り当て - 仮想マシンに割り当てる実際のメモリー量を設定します。値を調整して、仮想マシンで利用可能なメモリーをプロセス用に調整できます。この値は、最大割り当て値を超えることができません。
  5. 保存 をクリックします。

    仮想マシンのメモリー割り当てが調整されます。

関連情報

14.3.2. コマンドラインインターフェースで仮想マシンのメモリーの追加と削除

仮想マシンのパフォーマンスを改善したり、使用しているホストリソースを解放したりするために、CLI を使用して仮想マシンに割り当てられたメモリーの量を調整できます。

前提条件

  • ゲスト OS がメモリーバルーンドライバーを実行している。これを確認するには、以下を実行します。

    1. 仮想マシンの設定に memballoon デバイスが含まれていることを確認します。

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      このコマンドで出力が表示され、モデルが none に設定されていない場合は、memballoon デバイスが存在します。

    2. ballon ドライバーがゲスト OS で実行されていることを確認します。

      • Windows ゲストでは、ドライバーは virtio-win ドライバーパッケージの一部としてインストールされます。手順は、「Windows 仮想マシンの準仮想化 KVM ドライバーのインストール」を参照してください。
      • Linux ゲストでは、通常、このドライバーはデフォルトで含まれており、memballoon デバイスがあれば、アクティベートされます。

手順

  1. 任意: 最大メモリーと、仮想マシンに現在使用されている最大メモリーの情報を取得します。これは、変更のベースラインとして、さらに検証用として機能します。

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. 仮想マシンに割り当てる最大メモリーを調整します。この値を増やすと、仮想マシンのパフォーマンスが低下する可能性が向上し、値を減らすことで、仮想マシンがホスト上にあるパフォーマンスフットプリントが低減します。この変更は、停止している仮想マシンでのみ実行できるため、実行中の仮想マシンを調整するには再起動する必要があります。

    たとえば、仮想マシン testguest が使用可能な最大メモリーを 4096 MiB に変更するには、次のコマンドを実行します。

    # virt-xml testguest --edit --memory memory=4096,currentMemory=4096
    Domain 'testguest' defined successfully.
    Changes will take effect after the domain is fully powered off.
  1. 任意: 仮想マシンが現在使用しているメモリーを最大割り当てまで調整することもできます。これにより、仮想マシンの最大割り当てを変更せずに、仮想マシンが次回の再起動までホスト上にあるメモリー負荷が調整されます。

    # virsh setmem testguest --current 2048

検証

  1. 仮想マシンが使用するメモリーが更新されていることを確認します。

    # virsh dominfo testguest
    Max memory:     4194304 KiB
    Used memory:    2097152 KiB
  2. (必要に応じて) 現在の仮想マシンメモリーを調整すると、仮想マシンのメモリーバルーンの統計を取得して、そのメモリー使用量をどの程度効果的に調整するかを評価できます。

     # virsh domstats --balloon testguest
    Domain: 'testguest'
      balloon.current=365624
      balloon.maximum=4194304
      balloon.swap_in=0
      balloon.swap_out=0
      balloon.major_fault=306
      balloon.minor_fault=156117
      balloon.unused=3834448
      balloon.available=4035008
      balloon.usable=3746340
      balloon.last-update=1587971682
      balloon.disk_caches=75444
      balloon.hugetlb_pgalloc=0
      balloon.hugetlb_pgfail=0
      balloon.rss=1005456

関連情報

14.3.3. 関連情報

  • 実行中の仮想マシンの最大メモリーを増やすには、仮想マシンにメモリーデバイスを割り当てます。これは、メモリーのホットプラグとも呼ばれます。詳細は「デバイスの仮想マシンへの接続」を参照してください。

    RHEL 8 では、メモリーのホットアンプラグとも呼ばれる仮想マシンからメモリーデバイスを削除することはサポートされておらず、Red Hat ではその使用を推奨していません。

14.4. 仮想マシンの I/O パフォーマンスの最適化

仮想マシンの入出力 (I/O) 機能は、仮想マシンの全体的な効率を大幅に制限する可能性があります。これに対処するために、ブロック I/O パラメーターを設定して、仮想マシンの I/O を最適化できます。

14.4.1. 仮想マシンにおけるブロック I/O のチューニング

複数のブロックデバイスが、複数の仮想マシンで使用されている場合は、I/O ウェイト を変更して特定の仮想デバイスの I/O の優先度を調整することが重要になる場合があります。

デバイスの I/O ウェイトを上げると、I/O 帯域幅の優先度が高まるため、より多くのホストリソースが提供されます。同様に、デバイスのウェイトを下げると、ホストのリソースが少なくなります。

注記

各デバイスの ウェイト の値は 100 から 1000 の範囲内でなければなりません。もしくは、値を 0 にすると、各デバイスの一覧からそのデバイスを削除できます。

手順

仮想マシンのブロック I/O パラメーターを表示および設定するには、以下を行います。

  1. 仮想マシンの現在の <blkio> パラメーターを表示します。

    # virsh dumpxml VM-name

    <domain>
      [...]
      <blkiotune>
        <weight>800</weight>
        <device>
          <path>/dev/sda</path>
          <weight>1000</weight>
        </device>
        <device>
          <path>/dev/sdb</path>
          <weight>500</weight>
        </device>
      </blkiotune>
      [...]
    </domain>
  2. 指定したデバイスの I/O ウェイトを編集します。

    # virsh blkiotune VM-name --device-weights device, I/O-weight

    たとえば、以下では、liftrul 仮想マシンの /dev/sda デバイスのウェイトを 500 に変更します。

    # virsh blkiotune liftbrul --device-weights /dev/sda, 500

14.4.2. 仮想マシンのディスク I/O スロットリング

複数の仮想マシンが同時に実行する場合は、過剰なディスク I/O により、システムパフォーマンスに影響が及ぶ可能性があります。KVM 仮想化のディスク I/O スロットリングでは、仮想マシンからホストマシンに送られるディスク I/O 要求に制限を設定する機能を利用できます。これにより、仮想マシンが共有リソースを過剰に使用し、その他の仮想マシンのパフォーマンスに影響を及ぼすことを防ぐことができます。

ディスク I/O スロットリングを有効にするには、仮想マシンに割り当てられた各ブロックデバイスからホストマシンに送られるディスク I/O 要求に制限を設定します。

手順

  1. virsh domblklist コマンドを使用して、指定された仮想マシン上のすべてのディスクデバイスの名前を一覧表示します。

    # virsh domblklist rollin-coal
    Target     Source
    ------------------------------------------------
    vda        /var/lib/libvirt/images/rollin-coal.qcow2
    sda        -
    sdb        /home/horridly-demanding-processes.iso
  2. スロットルする仮想ディスクがマウントされているホストブロックデバイスを見つけます。

    たとえば、前の手順の sdb 仮想ディスクをスロットリングする場合は、以下の出力では、ディスクが /dev/nvme0n1p3 パーティションにマウントされていることを示しています。

    $ lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    zram0                                         252:0    0     4G  0 disk  [SWAP]
    nvme0n1                                       259:0    0 238.5G  0 disk
    ├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
    ├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
    └─nvme0n1p3                                   259:3    0 236.9G  0 part
      └─luks-a1123911-6f37-463c-b4eb-fxzy1ac12fea 253:0    0 236.9G  0 crypt /home
  3. virsh blkiotune コマンドを使用して、ブロックデバイスの I/O 制限を設定します。

    # virsh blkiotune VM-name --parameter device,limit

    以下の例は、rollin-coal 仮想マシン上の sdb ディスクを毎秒 1000 の読み書き操作にスロットリングし、毎秒 50 MB の読み書きスループットにスロットリングします。

    # virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800

関連情報

  • ディスク I/O スロットリングは、異なる顧客に属する仮想マシンが同じホストで実行されている場合や、異なる仮想マシンに QoS 保証が提供されている場合など、さまざまな状況で役立ちます。ディスク I/O スロットリングは、低速なディスクをシミュレートするために使用することもできます。
  • I/O スロットリングは、仮想マシンに割り当てられた各ブロックデバイスに個別に適用でき、スループットおよび I/O 操作の制限に対応します。
  • Red Hat は、virsh blkdeviotune コマンドを使用した仮想マシンでの I/O スロットリングの設定はサポートしていません。RHEL 8 を仮想マシンホストとして使用する際のサポートされない機能の詳細は、「RHEL 8 仮想化でサポートされない機能」を参照してください。

14.4.3. マルチキュー virtio-scsi の有効化

仮想マシンで virtio-scsi ストレージデバイスを使用する場合は、マルチキュー virtio-scsi 機能により、ストレージパフォーマンスおよびスケーラビリティーが向上します。このため、各仮想 CPU (vCPU) に別のキューを持たせることが可能になります。また仮想 CPU は、その他の vCPU に影響を及ぼすことなく使用するために、割り込みできるようになります。

手順

  • 特定の仮想マシンに対してマルチキュー virtio-scsi サポートを有効にするには、仮想マシンの XML 設定に以下を追加します。ここでの N は、vCPU キューの合計数です。

    <controller type='scsi' index='0' model='virtio-scsi'>
       <driver queues='N' />
    </controller>

14.5. 仮想マシンの CPU パフォーマンスの最適化

vCPU は、ホストマシンの物理 CPU と同様、仮想マシンのパフォーマンスにおいて極めて重要です。したがって、vCPU を最適化すると、仮想マシンのリソース効率に大きな影響を及ぼす可能性があります。vCPU を最適化するには、以下を実行します。

  1. 仮想マシンに割り当てられているホスト CPU の数を調整します。これは、CLI または Web コンソール を使用して実行できます。
  2. vCPU モデルが、ホストの CPU モデルに調整されていることを確認します。たとえば、仮想マシン testguest1 を、ホストの CPU モデルを使用するように設定するには、次のコマンドを実行します。

    # virt-xml testguest1 --edit --cpu host-model
  3. Kernel Same-page Merging (KSM) を無効にします
  4. ホストマシンが Non-Uniform Memory Access (NUMA) を使用する場合は、その仮想マシンに対して NUMA を設定 することもできます。これにより、ホストの CPU およびメモリープロセスが、仮想マシンの CPU およびメモリープロセスにできるだけ近くにマッピングされます。事実上、NUMA チューニングにより、仮想マシンに割り当てられたシステムメモリーへのより効率的なアクセスが可能になります。これにより、vCPU 処理の効果が改善されます。

    詳細は 「仮想マシンでの NUMA の設定」 および 「vCPU のパフォーマンスチューニングシナリオ例」 を参照してください。

14.5.1. コマンドラインインターフェースを使用した仮想 CPU の追加と削除

仮想マシンの CPU パフォーマンスを増減するには、仮想マシンに割り当てられた仮想 CPU (vCPU) を追加または削除します。

実行中の仮想マシンで実行する場合、これは vCPU ホットプラグおよびホットアンプラグとも呼ばれます。ただし、RHEL 8 では vCPU のホットアンプラグに対応しておらず、Red Hat ではその使用を強く推奨していません。

前提条件

  • オプション: ターゲット仮想マシン内の vCPU の現在の状態を表示します。たとえば、仮想マシン testguest 上の仮想 CPU 数を表示するには、以下を実行します。

    # virsh vcpucount testguest
    maximum      config         4
    maximum      live           2
    current      config         2
    current      live           1

    この出力は、testguest が現在 1 vCPU を使用していることを示し、1 つ以上の vCPU をホットプラグして仮想マシンのパフォーマンスを向上できることを示しています。ただし、再起動後に使用される vCPU の testguest 数は 2 に変更され、2 以上の vCPU のホットプラグが可能になります。

手順

  1. 仮想マシンに割り当てることができる vCPU の最大数を調整します。これは、仮想マシンの次回起動時に有効になります。

    たとえば、仮想マシン testguest の vCPU の最大数を 8 に増やすには、次のコマンドを実行します。

    # virsh setvcpus testguest 8 --maximum --config

    最大値は、CPU トポロジー、ホストハードウェア、ハイパーバイザー、およびその他の要素によって制限される可能性があることに注意してください。

  2. 仮想マシンに割り当てられている現在の仮想 CPU の数を調整し、直前のステップで設定された最大数まで調整します。以下に例を示します。

    • 実行中の仮想マシン testguest にアタッチされている vCPU を 4 に増やすには、以下を実行します。

      # virsh setvcpus testguest 4 --live

      これにより、仮想マシンの次回の起動まで、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが高まります。

    • testguest 仮想マシンにアタッチされている vCPU の数を永続的に 1 に減らすには、次のコマンドを実行します。

      # virsh setvcpus testguest 1 --config

      これにより、仮想マシンの次回の起動後に、仮想マシンのパフォーマンスおよび testguest のホスト負荷のフットプリントが低下します。ただし、必要に応じて、仮想マシンに追加の vCPU をホットプラグして、一時的にパフォーマンスを向上させることができます。

検証

  • 仮想マシンの vCPU の現在の状態に変更が反映されていることを確認します。

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

関連情報

14.5.2. Web コンソールで仮想 CPU の管理

RHEL 8 Web コンソールを使用して、Web コンソールが接続している仮想マシンが使用する仮想 CPU を確認し、設定できます。

前提条件

手順

  1. 仮想マシン インターフェースで、仮想 CPU パラメーターを表示および設定する仮想マシンの名前がある行をクリックします。

    行が展開され、概要ペインが表示されます。このペインには、選択した仮想マシンの基本情報 (仮想 CPU の数など) が記載され、仮想マシンのシャットダウンおよび削除を制御できます。

  2. 概要ペインの仮想 CPU の数をクリックします。

    vCPU の詳細ダイアログが表示されます。

    cockpit での vCPU の設定
    注記

    vCPU の詳細ダイアログの警告は、仮想 CPU 設定を変更しないと表示されません。

  3. 選択した仮想マシンの仮想 CPU を設定します。

    • vCPU 数 - 現在使用中の vCPU の数

      注記

      vCPU 数は、vCPU 最大値以下にする必要があります。

    • vCPU 最大値 - 仮想マシンに設定できる仮想 CPU の最大数を入力します。この値が vCPU 数 よりも大きい場合、追加の vCPU を仮想マシンに割り当てることができます。
    • ソケット - 仮想マシンに公開するソケットの数を選択します。
    • ソケットごとのコア - 仮想マシンに公開する各ソケットのコア数を選択します。
    • コアあたりのスレッド - 仮想マシンに公開する各コアのスレッド数を選択します。

      SocketsCores per socket、および Threads per core オプションは、仮想マシンの CPU トポロジーを調整することに注意してください。これは、vCPU のパフォーマンスにメリットがあり、ゲスト OS の特定のソフトウェアの機能に影響を与える可能性があります。デプロイメントで異なる設定が必要ない場合、Red Hat はデフォルト値を維持することを推奨します。

  4. 適用 をクリックします。

    仮想マシンに仮想 CPU が設定されます。

    注記

    仮想 CPU 設定の変更は、仮想マシンの再起動後にのみ有効になります。

関連情報

14.5.3. 仮想マシンでの NUMA の設定

以下の方法は、RHEL 8 ホストで、仮想マシンの Non-Uniform Memory Access (NUMA) 設定の構成に使用できます。

前提条件

  • ホストが NUMA 対応のマシンである。これを確認するには、virsh nodeinfo コマンドを使用して、NUMA cell(2) の行を確認します。

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              48
    CPU frequency:       1200 MHz
    CPU socket(s):       1
    Core(s) per socket:  12
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         67012964 KiB

    行の値が 2 以上であると、そのホストは NUMA に対応しています。

手順

使いやすさのため、自動化ユーティリティーとサービスを使用して、仮想マシンの NUMA を設定できます。ただし、手動で NUMA を設定すると、パフォーマンスが大幅に向上する可能性が高くなります。

自動方式

  • 仮想マシンの NUMA ポリシーを Preferred に設定します。たとえば、仮想マシン testguest5 に対してこれを行うには、次のコマンドを実行します。

    # virt-xml testguest5 --edit --vcpus placement=auto
    # virt-xml testguest5 --edit --numatune mode=preferred
  • ホストで NUMA の自動負荷分散を有効にします。

    # echo 1 > /proc/sys/kernel/numa_balancing
  • numad コマンドを使用して、メモリーリソースで仮想マシンの CPU を自動的に調整します。

    # numad

手動方式

  1. 特定ホストの CPU、またはある範囲の CPU に特定の vCPU スレッドをピニングします。これは、NUMA 以外のホストおよび仮想マシンでも可能で、vCPU のパフォーマンスを向上させる安全な方法として推奨されています。

    たとえば、次のコマンドでは、仮想マシン testguest6 の vCPU スレッドの 0 から 5 を、ホストの CPU 1、3、5、7、9、11 にそれぞれピニングします。

    # virsh vcpupin testguest6 0 1
    # virsh vcpupin testguest6 1 3
    # virsh vcpupin testguest6 2 5
    # virsh vcpupin testguest6 3 7
    # virsh vcpupin testguest6 4 9
    # virsh vcpupin testguest6 5 11

    その後、これが成功したかどうかを確認できます。

    # virsh vcpupin testguest6
    VCPU   CPU Affinity
    ----------------------
    0      1
    1      3
    2      5
    3      7
    4      9
    5      11
  2. vCPU スレッドのピニング後に、指定の仮想マシンに関連付けられた QEMU プロセススレッドを、特定ホスト CPU、またはある範囲の CPU に固定することもできます。たとえば、以下のコマンドは、testguest6 の QEMU プロセススレッドを CPU 13 および 15 にピニングし、これが成功したことを確認します。

    # virsh emulatorpin testguest6 13,15
    # virsh emulatorpin testguest6
    emulator: CPU Affinity
    ----------------------------------
           *: 13,15
  3. これで、特定の仮想マシンに対して割り当てられるホストの NUMA ノードを指定することができます。これにより、仮想マシンの vCPU によるホストメモリーの使用率が向上します。たとえば、次のコマンドでは、ホスト NUMA ノード 3 ~ 5 を使用するように testguest6 を設定し、これが成功したかどうかを確認します。

    # virsh numatune testguest6 --nodeset 3-5
    # virsh numatune testguest6

関連情報

14.5.4. vCPU のパフォーマンスチューニングシナリオ例

最適な vCPU パフォーマンスを得るためにも、以下のシナリオなど、手動で vcpupinemulatorpin、および numatune 設定をまとめて使用することが推奨されます。

開始シナリオ

  • ホストには以下のハードウェア仕様があります。

    • 2 つの NUMA ノード
    • 各ノードにある 3 つの CPU コア
    • 各コアにある 2 スレッド

    このようなマシンの virsh nodeinfo の出力は以下のようになります。

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              12
    CPU frequency:       3661 MHz
    CPU socket(s):       2
    Core(s) per socket:  3
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         31248692 KiB
  • 既存の仮想マシンを変更して、8 つの vCPU を使用できるようにします。これは、1 つの NUMA ノードに収まらないことを意味します。

    したがって、各 NUMA ノードに 4 つの vCPU を分散し、vCPU トポロジーをホストトポロジーに可能な限り近づけるようにする必要があります。つまり、指定の物理 CPU のシブリングスレッドとして実行される vCPU は、同じコア上のホストスレッドに固定 (ピニング) される必要があります。詳細は、以下の ソリューション を参照してください。

ソリューション

  1. ホストトポロジーに関する情報を取得します。

    # virsh capabilities

    この出力には、以下のようなセクションが含まれます。

    <topology>
      <cells num="2">
        <cell id="0">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="10" />
            <sibling id="1" value="21" />
          </distances>
          <cpus num="6">
            <cpu id="0" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="1" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="2" socket_id="0" core_id="2" siblings="2,5" />
            <cpu id="3" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="4" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="5" socket_id="0" core_id="2" siblings="2,5" />
          </cpus>
        </cell>
        <cell id="1">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="21" />
            <sibling id="1" value="10" />
          </distances>
          <cpus num="6">
            <cpu id="6" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="7" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="8" socket_id="1" core_id="5" siblings="8,11" />
            <cpu id="9" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="10" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="11" socket_id="1" core_id="5" siblings="8,11" />
          </cpus>
        </cell>
      </cells>
    </topology>
  2. (必要に応じて) 適用可能なツールおよびユーティリティー を使用して、仮想マシンのパフォーマンスをテストします。
  3. ホストに 1 GiB の Huge Page を設定してマウントします。

    1. ホストのカーネルコマンドラインに次の行を追加します。

      default_hugepagesz=1G hugepagesz=1G
    2. /etc/systemd/system/hugetlb-gigantic-pages.service ファイルを以下の内容で作成します。

      [Unit]
      Description=HugeTLB Gigantic Pages Reservation
      DefaultDependencies=no
      Before=dev-hugepages.mount
      ConditionPathExists=/sys/devices/system/node
      ConditionKernelCommandLine=hugepagesz=1G
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/etc/systemd/hugetlb-reserve-pages.sh
      
      [Install]
      WantedBy=sysinit.target
    3. /etc/systemd/hugetlb-reserve-pages.sh ファイルを以下の内容で作成します。

      #!/bin/sh
      
      nodes_path=/sys/devices/system/node/
      if [ ! -d $nodes_path ]; then
      	echo "ERROR: $nodes_path does not exist"
      	exit 1
      fi
      
      reserve_pages()
      {
      	echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
      }
      
      reserve_pages 4 node1
      reserve_pages 4 node2

      これにより、4 つの 1GiB の Huge Page が node1 から予約され、さらに別の 4 つの 1 GiB の Huge Page が node2 から予約されます。

    4. 前の手順で作成したスクリプトを実行ファイルにします。

      # chmod +x /etc/systemd/hugetlb-reserve-pages.sh
    5. システムの起動時に Huge Page 予約を有効にします。

      # systemctl enable hugetlb-gigantic-pages
  4. virsh edit コマンドを使用して、最適化する仮想マシンの XML 設定 (この例では super-VM) を編集します。

    # virsh edit super-vm
  5. 次の方法で仮想マシンの XML 設定を調整します。

    1. 仮想マシンが 8 つの静的 vCPU を使用するように設定します。これを行うには、<vcpu/> 要素を使用します。
    2. トポロジーでミラーリングする、対応するホスト CPU スレッドに、各 vCPU スレッドをピニングします。これを行うには、<cputune> セクションの <vcpupin/> 要素を使用します。

      上記の virsh 機能 ユーティリティーで示されているように、ホストの CPU スレッドは、各コアで連続的に順次付けされません。また、vCPU スレッドは、同じ NUMA ノード上のホストのコアの利用可能な最大セットに固定される必要があります。表の図については、以下の 関連情報 セクションを参照してください。

      手順 a と b の XML 構成は次のようになります。

      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
    3. 1 GiB の Huge Page を使用するように仮想マシンを設定します。

      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
    4. ホスト上で対応する NUMA ノードからメモリーを使用するように、仮想マシンの NUMA ノードを設定します。これを行うには、<numatune/> セクションの <memnode/> 要素を使用します。

      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
    5. CPU モードが host-passthrough に設定され、CPU が パススルー モードでキャッシュを使用していることを確認します。

      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
  6. 作成される仮想マシンの XML 設定には、以下のようなセクションが含まれます。

    [...]
      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
      <vcpu placement='static'>8</vcpu>
      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
        <numa>
          <cell id="0" cpus="0-3" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="10"/>
              <sibling id="1" value="21"/>
            </distances>
          </cell>
          <cell id="1" cpus="4-7" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="21"/>
              <sibling id="1" value="10"/>
            </distances>
          </cell>
        </numa>
      </cpu>
    </domain>
  7. (必要に応じて) アプリケーションツールおよびユーティリティー を使用して仮想マシンのパフォーマンスをテストし、仮想マシンの最適化への影響を評価します。

関連情報

  • 以下の表は、ピニングされる必要のある vCPU とホストCPU 間の接続を示しています。

    表14.1 ホストトポロジー

    CPU スレッド

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    コア

    0

    1

    2

    3

    4

    5

    ソケット

    0

    1

    NUMA ノード

    0

    1

    表14.2 仮想マシントポロジー

    vCPU スレッド

    0

    1

    2

    3

    4

    5

    6

    7

    コア

    0

    1

    2

    3

    ソケット

    0

    1

    NUMA ノード

    0

    1

    表14.3 ホストと仮想マシントポロジーの組み合わせ

    vCPU スレッド

     

    0

    1

    2

    3

     

    4

    5

    6

    7

    ホストの CPU スレッド

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    コア

    0

    1

    2

    3

    4

    5

    ソケット

    0

    1

    NUMA ノード

    0

    1

    このシナリオでは、2 つの NUMA ノードと 8 つの vCPU があります。したがって、4 つの vCPU スレッドは各ノードに固定 (ピニング) される必要があります。

    また、Red Hat では、ホストシステムの操作に対して、各ノードに少なくとも 1 つの CPU スレッドを使用することを推奨します。

    以下の例では、NUMA ノードにはそれぞれ 3 コアで、2 個のホスト CPU スレッドがあるため、ノード 0 のセットは、以下のように変換できます。

    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='4'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='5'/>

14.5.5. Kernel Same-page Merging の無効化

Kernel same-page merging (KSM) はメモリーの密度を向上させますが、CPU 使用率が増え、ワークロードによっては全体のパフォーマンスに悪影響を与える可能性があります。このような場合には、KSM を無効にすることで、仮想マシンのパフォーマンスを向上させることができます。

要件に応じて、KSM を 1 回のセッションだけ無効にしたり、永続的に無効にしたりできます。

手順

  • KSM をセッション 1 回分無効にするには、systemctl ユーティリティーを使用して ksm サービスおよび ksmtuned サービスを停止します。

    # systemctl stop ksm
    
    # systemctl stop ksmtuned
  • KSM を永続的に無効にするには、systemctl ユーティリティーを使用して ksm サービスおよび ksmtuned サービスを無効にします。

    # systemctl disable ksm
    Removed /etc/systemd/system/multi-user.target.wants/ksm.service.
    # systemctl disable ksmtuned
    Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.
注記

KSM を無効にする前に仮想マシン間で共有されていたメモリーページは、そのまま共有されます。共有を停止するには、以下のコマンドを使用して、システムの PageKSM ページをすべて削除します。

# echo 2 > /sys/kernel/mm/ksm/run

KSM ページを匿名ページに置き換えると、khugepaged カーネルサービスは仮想マシンの物理メモリーに透過的なヒュージページを再ビルドします。

14.6. 仮想マシンのネットワークパフォーマンスの最適化

仮想マシンのネットワークインターフェースカード (NIC) の性質上、仮想マシンは、割り当てられているホストネットワークの帯域幅の一部を失います。これにより、仮想マシンの全体的なワークロード効率が削減されることがあります。以下のヒントは、仮想 NIC (vNIC) のスループットで仮想化の影響を最小限に抑えることができます。

手順

以下の方法のいずれかを使用し、仮想マシンのネットワークパフォーマンスにメリットがあるかどうかを調べます。

vhost_net モジュールの有効化

ホストで vhost_net カーネル機能が有効になっていることを確認します。

# lsmod | grep vhost
vhost_net              32768  1
vhost                  53248  1 vhost_net
tap                    24576  1 vhost_net
tun                    57344  6 vhost_net

このコマンドの出力が空白である場合は、vhost_net カーネルモジュールを有効にします。

# modprobe vhost_net
マルチキュー virtio-net の設定

仮想マシンに マルチキュー virtio-net 機能を設定するには、virsh edit コマンドを使用して、仮想マシンの XML 設定を編集します。XML で、以下を <devices> セクションに追加し、N を、仮想マシンの vCPU 数 (最大 16) に変更します。

<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>

仮想マシンが実行中の場合は、再起動して変更を適用します。

ネットワークパケットのバッチ処理

転送パスが長い Linux の仮想マシン設定では、パケットをバッチ処理してからカーネルに送信することで、キャッシュが有効に活用される場合があります。パケットバッチ機能を設定するには、ホストで次のコマンドを実行し、tap0 を、仮想マシンが使用するネットワークインターフェースの名前に置き換えます。

# ethtool -C tap0 rx-frames 128
SR-IOV
ホスト NIC が SR-IOV に対応している場合は、vNIC に SR-IOV デバイス割り当てを使用します。詳細は、「SR-IOV デバイスの管理」を参照してください。

関連情報

14.7. 仮想マシンのパフォーマンス監視ツール

最も多くの仮想マシンリソースを消費するものと、仮想マシンで最適化を必要とする部分を認識するために、一般的なパフォーマンス診断ツールや仮想マシン固有のパフォーマンス診断ツールを使用できます。

デフォルトの OS パフォーマンス監視ツール

標準のパフォーマンス評価には、ホストおよびゲストのオペレーティングシステムでデフォルトで提供されるユーティリティーを使用できます。

  • RHEL 8 ホストで、root として top ユーティリティーまたは システムモニター アプリケーションを使用し、出力結果から qemuvirt を見つけます。これは、仮想マシンが消費しているホストシステムのリソースのサイズを示します。

    • 監視ツールにおいて、qemu プロセスまたは virt プロセスのいずれかで、ホストの CPU またはメモリーの容量を大幅に消費していることが示されている場合は、perf ユーティリティを使用して調査を行います。詳細は以下を参照してください。
    • また、vhost_net スレッドプロセス (例: vhost_net-1234) が、ホストの CPU 容量を過剰に消費する際に表示される場合は、マルチキュー virtio-net などの 仮想ネットワークの最適化機能 を使用することを検討してください。
  • ゲストオペレーティングシステムでは、システムで利用可能なパフォーマンスユーティリティーとアプリケーションを使用して、どのプロセスが最も多くのシステムリソースを消費するかを評価します。

    • Linux システムでは、top ユーティリティを使用できます。
    • Windows システムでは、Task Manager アプリケーションを使用できます。

perf kvm

perf ユーティリティーを使用して、RHEL 8 ホストのパフォーマンスに関する仮想化固有の統計を収集および分析できます。これを行うには、以下のように行います。

  1. ホストに、perf パッケージをインストールします。

    # yum install perf
  2. perf kvm stat コマンドの 1 つを使用して、仮想化ホストの perf 統計を表示します。

    • お使いのハイパーバイザーのリアルタイム監視には、perf kvm stat live コマンドを使用します。
    • 一定期間でハイパーバイザーの perf データをログに記録するには、perf kvm stat record コマンドを使用してロギングを有効にします。コマンドをキャンセルまたは中断した後、データは perf.data.guest ファイルに保存されます。これは、perf kvm stat report コマンドを使用して分析できます。
  3. VM-EXIT イベントとそのディストリビューションのタイプについて perf 出力を分析します。たとえば、PAUSE_INSTRUCTION イベントは頻繁に存在すべきではありませんが、以下の出力では、このイベントが頻繁に現れ、ホスト CPU が vCPU を適切に処理していないことを示しています。このようなシナリオでは、アクティブな一部の仮想マシンの電源オフ、その仮想マシンからの vCPU の削除、または vCPU のパフォーマンスの調整 を検討してください。

    # perf kvm stat report
    
    Analyze events for all VMs, all VCPUs:
    
    
                 VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time         Avg time
    
      EXTERNAL_INTERRUPT     365634    31.59%    18.04%      0.42us  58780.59us    204.08us ( +-   0.99% )
               MSR_WRITE     293428    25.35%     0.13%      0.59us  17873.02us      1.80us ( +-   4.63% )
        PREEMPTION_TIMER     276162    23.86%     0.23%      0.51us  21396.03us      3.38us ( +-   5.19% )
       PAUSE_INSTRUCTION     189375    16.36%    11.75%      0.72us  29655.25us    256.77us ( +-   0.70% )
                     HLT      20440     1.77%    69.83%      0.62us  79319.41us  14134.56us ( +-   0.79% )
                  VMCALL      12426     1.07%     0.03%      1.02us   5416.25us      8.77us ( +-   7.36% )
           EXCEPTION_NMI         27     0.00%     0.00%      0.69us      1.34us      0.98us ( +-   3.50% )
           EPT_MISCONFIG          5     0.00%     0.00%      5.15us     10.85us      7.88us ( +-  11.67% )
    
    Total Samples:1157497, Total events handled time:413728274.66us.

    perf kvm stat の出力で問題を知らせる他のイベントタイプには、以下が含まれます。

perf を使用した仮想パフォーマンスを監視する方法は、perf-kvm man ページを参照してください。

numastat

システムの現在の NUMA 設定を表示するには、numastat ユーティリティーを使用できます。これは numactl パッケージをインストールすることで利用できます。

以下は、4 つの実行中の仮想マシンが含まれるホストを示しています。それぞれは、複数の NUMA ノードからメモリーを取得しています。これは、vCPU のパフォーマンスに対して最適なのではなく、保証調整 です。

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm)     68     16    357   6936      2      3    147    598  8128
51747 (qemu-kvm)    245     11      5     18   5172   2532      1     92  8076
53736 (qemu-kvm)     62    432   1661    506   4851    136     22    445  8116
53773 (qemu-kvm)   1393      3      1      2     12      0      0   6702  8114
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total              1769    463   2024   7462  10037   2672    169   7837 32434

一方、以下では、1 つのノードで各仮想マシンに提供されているメモリーを示しています。これは、より一層効率的です。

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm)      0      0      7      0   8072      0      1      0  8080
53736 (qemu-kvm)      0      0      7      0      0      0   8113      0  8120
53773 (qemu-kvm)      0      0      7      0      0      0      1   8110  8118
59065 (qemu-kvm)      0      0   8050      0      0      0      0      0  8051
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total                 0      0   8072      0   8072      0   8114   8110 32368

第15章 PowerTOP で電力消費の管理

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

15.1. PowerTOP の目的

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

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

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

15.2. PowerTOP の使用

前提条件

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

    # yum install powertop

15.2.1. PowerTOP の起動

手順

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

    # powertop
重要

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

15.2.2. PowerTOP の調整

手順

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

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

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

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

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

注記

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

15.2.3. 測定間隔の設定

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

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

手順

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

    # powertop --time=time in seconds

15.3. PowerTOP の統計

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

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

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

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

15.3.1. Overview タブ

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

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

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

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

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

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

15.3.2. Idle stats タブ

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

15.3.3. Device stats タブ

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

15.3.4. Tunables タブ

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

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

図15.1 PowerTOP 出力

PowerTOP 出力

関連情報

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

15.4. HTML 出力の生成

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

手順

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

    # powertop --html=htmlfile.html

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

15.5. 電力消費の最適化

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

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

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

手順

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

    # systemctl enable powertop

15.5.2. powertop2tuned ユーティリティー

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

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

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

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

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

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

前提条件

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

    # yum install tuned-utils

手順

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

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

    # tuned-adm profile new_profile_name

関連情報

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

    $ powertop2tuned --help

15.5.4. powertop.service と powertop2tuned の比較

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

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

第16章 perf の使用

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

16.1. perf の概要

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

16.2. perf のインストール

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

手順

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

    # yum install perf

16.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 ページを開きます。

第17章 perf top を使用したリアルタイムにおける CPU 使用率のプロファイリング

perf top コマンドを使用して、さまざまな機能の CPU 使用率をリアルタイムで測定できます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

17.1. perf top の目的

perf top コマンドは、top ユーティリティーと同様に、リアルタイムシステムのプロファイリングおよび機能に使用されます。ただし、top ユーティリティーは、通常、指定のプロセスまたはスレッドが使用している CPU 時間を示しており、perf top は各関数が使用する CPU 時間を表示します。デフォルトの状態では、perf top はユーザー空間とカーネル空間のすべての CPU で使用される関数について通知します。perf top を使用するには、root アクセスが必要です。

17.2. perf top を使った CPU 使用率のプロファイリング

この手順では、perf top をアクティブにし、CPU 使用率をリアルタイムでプロファイルします。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。
  • root アクセスがある。

手順

  • perf top モニタリングインターフェースを起動します。

    # perf top

    監視インターフェースは、以下のようになります。

    --------------------------------------------------------------------
    PerfTop:   20806 irqs/sec  kernel:57.3%  exact: 100.0% lost: 0/0 drop: 0/0 [4000Hz cycles],  (all, 8 CPUs)
    ---------------------------------------------------------------------
    Overhead  Shared Object       Symbol
       2.20%  [kernel]            [k] do_syscall_64
       2.17%  [kernel]            [k] module_get_kallsym
       1.49%  [kernel]            [k] copy_user_enhanced_fast_string
       1.37%  libpthread-2.29.so  [.] pthread_mutex_lock 1.31% [unknown] [.] 0000000000000000 1.07% [kernel] [k] psi_task_change 1.04% [kernel] [k] switch_mm_irqs_off 0.94% [kernel] [k] fget
       0.74%  [kernel]            [k] entry_SYSCALL_64
       0.69%  [kernel]            [k] syscall_return_via_sysret
       0.69%  libxul.so           [.] 0x000000000113f9b0
       0.67%  [kernel]            [k] kallsyms_expand_symbol.constprop.0
       0.65%  firefox             [.] moz_xmalloc
       0.65%  libpthread-2.29.so  [.] __pthread_mutex_unlock_usercnt
       0.60%  firefox             [.] free
       0.60%  libxul.so           [.] 0x000000000241d1cd
       0.60%  [kernel]            [k] do_sys_poll
       0.58%  [kernel]            [k] menu_select
       0.56%  [kernel]            [k] _raw_spin_lock_irqsave
       0.55%  perf                [.] 0x00000000002ae0f3

    この例では、カーネル関数 do_syscall_64 は CPU 時間を最も多く使用しています。

関連情報

  • man ページの perf-top(1)

17.3. perf top 出力の解釈

perf top モニタリングインターフェースは、データを複数の列に表示します。

「Overhead」列
指定された関数が使用している CPU のパーセントを表示します。
「共有オブジェクト」のコラム
機能を使用しているプログラムまたはライブラリー名を表示します。
「Symbol」列
関数名またはシンボルを表示します。カーネル空間で実行される関数は [k] によって識別され、ユーザースペースで実行される関数は [.] によって識別されます。

17.4. perf が一部の関数名を raw 関数アドレスとして表示する理由

カーネル関数の場合は、perf/proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数については、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。

実行ファイルの debuginfo パッケージがインストールされているか、または実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。

注記

実行ファイルに関連する debuginfo のインストール後に perf record コマンドを再実行する必要はありません。単に perf report コマンドを再実行 します。

17.5. デバッグおよびソースのリポジトリーの有効化

Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。

手順

  • ソースおよびデバッグの情報パッケージチャンネルを有効にします。

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    $(uname -i) の部分は、システムのアーキテクチャーで一致する値に自動的に置き換えられます。

    アーキテクチャー名

    64 ビット Intel および AMD

    x86_64

    64 ビット ARM

    aarch64

    IBM POWER

    ppc64le

    64 ビット IBM Z

    s390x

17.6. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得

デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。

前提条件

  • デバッグするアプリケーションまたはライブラリーがシステムにインストールされている。
  • GDB と debuginfo-install ツールがシステムにインストールされている。詳細は「アプリケーションをデバッグするための設定」を参照してください。
  • debuginfo パッケージおよび debugsource パッケージを提供するチャンネルをシステムに設定し、有効にしている。

手順

  1. デバッグするアプリケーションまたはライブラリーに割り当てられた GDB を起動します。GDB は、足りないデバッグ情報を自動的に認識し、実行するコマンドを提案します。

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. GDB を終了します。q と入力して、Enter で確認します。

    (gdb) q
  3. GDB が提案するコマンドを実行して、必要な debuginfo パッケージをインストールします。

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf パッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。

  4. GDB が debuginfo パッケージを提案できない場合は、「手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得」で説明されている手順に従います。

第18章 perf stat でプロセスの実行中にイベントをカウント

perf stat コマンドを使用すると、プロセスの実行中にハードウェアおよびソフトウェアのイベントをカウントできます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

18.1. perf stat の目的

perf stat コマンドは指定されたコマンドを実行し、コマンドの実行中にハードウェアおよびソフトウェアのイベントの発生回数を維持し、これらのカウントの統計を生成します。イベントを指定しないと、perf stat は共通のハードウェアおよびソフトウェアのイベントセットをカウントします。

18.2. perf stat を使用したイベントのカウント

perf stat を使用すると、コマンドの実行中に発生したハードウェアおよびソフトウェアのイベントをカウントし、これらのカウントの統計を生成できます。デフォルトでは、perf stat はスレッドごとのモードで動作します。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • イベントをカウントします。

    • root アクセスなしで perf stat コマンドを実行すると、ユーザー空間で発生したイベントのみをカウントします。

      $ perf stat ls

      例18.1 perf stat の出力が root アクセスなしで実行

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    1.28 msec task-clock:u               #    0.165 CPUs utilized
                       0      context-switches:u         #    0.000 M/sec
                       0      cpu-migrations:u           #    0.000 K/sec
                     104      page-faults:u              #    0.081 M/sec
               1,054,302      cycles:u                   #    0.823 GHz
               1,136,989      instructions:u             #    1.08  insn per cycle
                 228,531      branches:u                 #  178.447 M/sec
                  11,331      branch-misses:u            #    4.96% of all branches
      
             0.007754312 seconds time elapsed
      
             0.000000000 seconds user
             0.007717000 seconds sys

      以前の例で分かるように、perf stat を root アクセスなしで実行すると、イベント名の後に :u が付けられ、これらのイベントがユーザー空間でのみカウントされていることが分かります。

    • ユーザー空間およびカーネルスペースの両方のイベントをカウントするには、perf stat の実行時に root アクセスが必要になります。

      # perf stat ls

      例18.2 root アクセスで実行された perf stat の出力

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    3.09 msec task-clock                #    0.119 CPUs utilized
                      18      context-switches          #    0.006 M/sec
                       3      cpu-migrations            #    0.969 K/sec
                     108      page-faults               #    0.035 M/sec
               6,576,004      cycles                    #    2.125 GHz
               5,694,223      instructions              #    0.87  insn per cycle
               1,092,372      branches                  #  352.960 M/sec
                  31,515      branch-misses             #    2.89% of all branches
      
             0.026020043 seconds time elapsed
      
             0.000000000 seconds user
             0.014061000 seconds sys
      • デフォルトでは、perf stat はスレッドごとのモードで動作します。CPU 全体のイベントカウントに変更するには、-a オプションを perf stat に渡します。CPU 全体のイベントをカウントするには、root アクセスが必要です。

        # perf stat -a ls

関連情報

  • perf-stat(1) man page

18.3. perf stat 出力の解釈

perf stat は指定されたコマンドを実行し、コマンドの実行中にイベントの発生をカウントし、これらのカウントの統計を 3 列で表示します。

  1. 指定されたイベントでカウントされた発生数
  2. カウントされたイベントの名前。
  3. 関連するメトリクスが利用可能な場合、右側のコラムのハッシュ記号 (#) の後に比率またはパーセンテージが表示されます。

    たとえば、デフォルトモードで実行している場合、perf stat はサイクルと命令の両方をカウントします。したがって、右端のコラムのサイクルごとの命令を計算して表示します。デフォルトでは両方のイベントがカウントされるため、分岐ミスに関して同様の動作がすべてのブランチのパーセントとして表示されます。

18.4. 実行中のプロセスに perf stat を割り当てる

perf stat を実行中のプロセスに割り当てることができます。これにより、コマンドの実行中に、指定したプロセスでのみ発生するイベントをカウントするように perf stat に指示します。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • perf stat を実行中のプロセスに割り当てます。

    $ perf stat -p ID1,ID2 sleep seconds

    前の例では、ID が ID1 and ID2 のプロセス内のイベントを、sleep コマンドで指定した seconds の秒数だけカウントします。

関連情報

  • perf-stat(1) man page

第19章 perf によるパフォーマンスプロファイルの記録および分析

perf ツールを使用すると、パフォーマンスデータを記録し、後で分析することができます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

19.1. perf record の目的

perf record コマンドはパフォーマンスデータをサンプルし、これをファイル perf.data に保存します。このファイルは、他の perf コマンドで読み取り、視覚化できます。perf.data は現在のディレクトリーに生成され、おそらく別のマシン上にある後でアクセスできます。

perf record を記録するコマンドを指定しないと、Ctrl+C を押して手動でプロセスを停止するまで記録されます。-p オプションに続いてプロセス ID を 1 つ以上渡すと、perf record を特定のプロセスに割り当てることができます。root アクセスなしで perf record レコードを実行できますが、実行するとユーザー領域のパフォーマンスデータのサンプルのみとなります。デフォルトモードでは、perf record レコードは CPU サイクルをサンプルイベントとして使用し、継承モードが有効な状態でスレッドごとのモードで動作します。

19.2. root アクセスなしのパフォーマンスプロファイルの記録

root アクセスなしで perf record を使用すると、ユーザー空間のみのパフォーマンスデータのサンプリングおよび記録を行うことができます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • パフォーマンスデータのサンプルと記録:

    $ perf record command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.3. root アクセスによるパフォーマンスプロファイルの記録

root アクセスで perf record を使用して、ユーザー空間とカーネル空間の両方でパフォーマンスデータをサンプリングおよび記録できます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。
  • root アクセスがある。

手順

  • パフォーマンスデータのサンプルと記録:

    # perf record command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.4. CPU ごとのモードでのパフォーマンスプロファイルの記録

CPU ごとのモードで perf record を使用すると、監視対象の CPU のすべてのスレッドにわたって、ユーザー空間とカーネル空間の両方で同時にパフォーマンスデータをサンプリングして記録できます。デフォルトでは、CPU ごとのモードはすべてのオンライン CPU を監視します。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • パフォーマンスデータのサンプルと記録:

    # perf record -a command

    command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。

関連情報

  • man ページの perf-record(1)

19.5. perf レコードで呼び出し先のデータを取得する

perf record ツールを設定して、どの関数がパフォーマンスプロファイル内の他の関数を呼び出しているかを記録することができます。これは、複数のプロセスが同じ関数を呼び出す場合にボトルネックを特定するのに役立ちます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  • --call-graph オプションを使用して、パフォーマンスデータのサンプルと記録を行います。

    $ perf record --call-graph method command
    • command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。
    • method を、以下のアンワインドメソッドのいずれかに置き換えます。

      fp
      フレームポインターメソッドを使用します。GCC オプション --fomit-frame-pointer でビルドされたバイナリーの場合など、コンパイラーの最適化により、スタックをアンワインドできない可能性があります。
      dwarf
      DWARF 呼び出し情報を使用してスタックのアンワインドを行います。
      lbr
      Intel プロセッサーで最後のブランチレコードハードウェアを使用します。

関連情報

  • man ページの perf-record(1)

19.6. perf レポートを使用した perf.data の分析

perf report を使用して perf.data ファイルを表示し、分析できます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。
  • 現行ディレクトリーに perf.data ファイルがある。
  • perf.data ファイルが root アクセスで作成された場合は、root アクセスで perf report を実行する必要もあります。

手順

  • 詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report

    このコマンドは、以下のような出力を表示します。

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

関連情報

  • perf-report(1) man page

19.7. perf report 出力の解釈

perf report コマンドを実行して表示されるテーブルは、データを複数のコラムに分類します。

「Overhead」列
その特定の機能で収集された全体のサンプルのパーセンテージを示します。
「Command」列
サンプルが収集されたプロセスを通知します。
「Shared Object」列
サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからのものである場合に [kernel.kallsyms] という名前が使用されます)。
「Symbol」列
関数名またはシンボルを表示します。

デフォルトモードでは、関数は、オーバーヘッドの最も高いものが最初に表示される順に降順でソートされます。

19.8. 別のデバイスで読み取り可能な perf.data ファイルの生成

perf ツールを使用してパフォーマンスデータを perf.data ファイルに記録し、異なるデバイスで分析することができます。

前提条件

手順

  1. さらに調査する予定のパフォーマンスデータを取得します。

    # perf record -a --call-graph fp sleep seconds

    この例では、sleep コマンドの使用によって指定される 数でシステム全体の perf.data を生成します。また、フレームポインターの方法を使用して呼び出しグラフデータを取得します。

  2. 記録されたデータのデバッグシンボルを含むアーカイブファイルを生成します。

    # perf archive

検証手順

  • アーカイブファイルが現在のアクティブなディレクトリーで生成されたことを確認します。

    # ls perf.data*

    出力には、perf.dataで始まる現在のディレクトリーのすべてのファイルが表示されます。アーカイブファイルの名前は以下のいずれかになります。

    perf.data.tar.gz

    または

    perf data.tar.bz2

19.9. 別のデバイスで作成された perf.data ファイルの分析

perf ツールを使用して、別のデバイスで生成された perf.data ファイルを分析することができます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。
  • 使用中の現在のデバイスに、別のデバイスで生成された perf.data ファイルと関連アーカイブファイルが存在する。

手順

  1. perf.data ファイルとアーカイブファイルの両方を現在のアクティブなディレクトリーにコピーします。
  2. アーカイブファイルを ~/.debugに展開します。

    # mkdir -p ~/.debug
    # tar xf perf.data.tar.bz2 -C ~/.debug
    注記

    アーカイブファイルの名前は perf.data.tar.gz でも構いません。

  3. perf.data ファイルを開いて詳細な分析を行います。

    # perf report

19.10. perf が一部の関数名を raw 関数アドレスとして表示する理由

カーネル関数の場合は、perf/proc/kallsyms ファイルからの情報を使用して、サンプルをそれぞれの関数名またはシンボルにマッピングします。ただし、ユーザー空間で実行される関数については、バイナリーがストライピングされるので、raw 機能のアドレスが表示される可能性があります。

実行ファイルの debuginfo パッケージがインストールされているか、または実行ファイルがローカルで開発したアプリケーションである場合は、アプリケーションがデバッグ情報 (GCC の -g オプション) を有効にしてコンパイルされ、このような状況で関数名またはシンボルが表示される必要があります。

注記

実行ファイルに関連する debuginfo のインストール後に perf record コマンドを再実行する必要はありません。単に perf report コマンドを再実行 します。

19.11. デバッグおよびソースのリポジトリーの有効化

Red Hat Enterprise Linux の標準インストールでは、デバッグリポジトリーおよびソースリポジトリーが有効になっていません。このリポジトリーには、システムコンポーネントのデバッグとパフォーマンスの測定に必要な情報が含まれます。

手順

  • ソースおよびデバッグの情報パッケージチャンネルを有効にします。

    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-baseos-source-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-debug-rpms
    # subscription-manager repos --enable rhel-8-for-$(uname -i)-appstream-source-rpms

    $(uname -i) の部分は、システムのアーキテクチャーで一致する値に自動的に置き換えられます。

    アーキテクチャー名

    64 ビット Intel および AMD

    x86_64

    64 ビット ARM

    aarch64

    IBM POWER

    ppc64le

    64 ビット IBM Z

    s390x

19.12. GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得

デバッグ情報は、コードをデバッグするために必要です。パッケージからインストールされるコードの場合、GNU デバッガー (GDB) は足りないデバッグ情報を自動的に認識し、パッケージ名を解決し、パッケージの取得方法に関する具体的なアドバイスを提供します。

前提条件

  • デバッグするアプリケーションまたはライブラリーがシステムにインストールされている。
  • GDB と debuginfo-install ツールがシステムにインストールされている。詳細は「アプリケーションをデバッグするための設定」を参照してください。
  • debuginfo パッケージおよび debugsource パッケージを提供するチャンネルをシステムに設定し、有効にしている。

手順

  1. デバッグするアプリケーションまたはライブラリーに割り当てられた GDB を起動します。GDB は、足りないデバッグ情報を自動的に認識し、実行するコマンドを提案します。

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. GDB を終了します。q と入力して、Enter で確認します。

    (gdb) q
  3. GDB が提案するコマンドを実行して、必要な debuginfo パッケージをインストールします。

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    dnf パッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。

  4. GDB が debuginfo パッケージを提案できない場合は、「手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得」で説明されている手順に従います。

第20章 perf でビジー CPU の調査

システムでパフォーマンスの問題を調査する際に、perf ツールを使用して、作業に集中するために CPU を特定して監視することができます。

20.1. perf stat でカウントされた CPU イベントの表示

perf stat を使用すると、CPU カウントアグリゲーションを無効にすることで、どの CPU イベントがカウントされたかを表示できます。この機能を使用するには、-a フラグを使用してシステム全体のモードでイベントをカウントする必要があります。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • CPU カウントアグリゲーションが無効になっているイベントをカウントします。

    # perf stat -a -A sleep seconds

    この例では、CPU0 以降の各 CPU に対して sleep コマンドを使用し、一定時間 ( 単位) に記録された一般的なハードウェアおよびソフトウェアイベントのデフォルトセット数が表示されます。そのため、cycle などのイベントを指定すると便利です。

    # perf stat -a -A -e cycles sleep seconds

20.2. perf レポートを使用して実行した CPU サンプルの表示

perf record コマンドはパフォーマンスデータをサンプルし、このデータを perf.data ファイルに保存します。このファイルは perf report コマンドで読み取ることができます。perf record コマンドは、どの CPU サンプルが発生したかを常に記録します。perf report を設定して、この情報を表示することができます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。
  • 現行ディレクトリーに perf recordperf.data ファイルが作成されている。perf.data ファイルが root アクセスで作成された場合は、root アクセスで perf report を実行する必要もあります。

手順

  • CPU でソートしながら、詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report --sort cpu
    • CPU およびコマンドでソートすると、CPU 時間が費やされている場所に関する詳細情報を表示できます。

      # perf report --sort cpu,comm

      この例では、すべての監視 CPU からのコマンドを、オーバーヘッド使用量の降順で合計オーバーヘッドで一覧表示し、コマンドが実行された CPU を特定します。

20.3. perf top を使用したプロファイリング中の特定の CPU の表示

perf top を設定して、システムのリアルタイムプロファイリング中に特定の CPU および相対使用率を表示できます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  • CPU でソートしながら perf top インターフェースを起動します。

    # perf top --sort cpu

    この例では、CPU とその各オーバーヘッドを、オーバーヘッド使用量の降順にリアルタイムで一覧表示します。

    • CPU およびコマンドでソートして、CPU 時間が費やされている場所の詳細を確認できます。

      # perf top --sort cpu,comm

      この例では、オーバーヘッド使用量の降順で合計オーバーヘッドでコマンドを一覧表示し、そのコマンドがリアルタイムに実行された CPU を特定します。

20.4. perf レコードと perf レポートを使用した特定 CPU の監視

perf record は、対象の特定の CPU のみのサンプルを設定し、詳細な分析のために perf report で生成された perf.data ファイルを分析できます。

前提条件

  • perf のインストール」で説明されているように、perf ユーザー領域ツールがインストールされている。

手順

  1. perf.data ファイルを生成して、特定の CPU のパフォーマンスデータをサンプルし、記録します。

    • CPU のコンマ区切りリストを使用します。

      # perf record -C 0,1 sleep seconds

      上記の例は、sleep コマンドの使用によって決定される 数で CPU 0 と 1 にデータをサンプルし、記録します。

    • さまざまな CPU を使用:

      # perf record -C 0-2 sleep seconds

      上記の例は、sleep コマンドの使用によって決定される 数で、CPU 0 から 2 までのすべての CPU にデータをサンプルし、記録します。

  2. 詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report

    この例では、perf.data の内容を表示します。複数の CPU を監視しており、どの CPU データがサンプルされたかを把握する場合は、「 perf report を使用した CPU サンプルの表示 」を参照してください。

第21章 perf でアプリケーションパフォーマンスの監視

本セクションでは、perf ツールを使用してアプリケーションのパフォーマンスを監視する方法を説明します。

21.1. 実行中のプロセスに perf レコードを割り当てる

実行中のプロセスに perf レコード をアタッチできます。これにより、perf レコード が、指定されたプロセスでパフォーマンスデータのサンプルデータと記録のみを行うように指示されます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  • 実行中のプロセスに perf レコード をアタッチします。

    $ perf record -p ID1,ID2 sleep seconds

    上記の例では、sleep コマンドを使用して、プロセス ID の ID1ID2 のプロセスのパフォーマンスデータを 数でサンプルし、記録します。perf を設定して、イベントを特定のスレッドに記録することもできます。

    $ perf record -t ID1,ID2 sleep seconds
    注記

    -t フラグを使用し、スレッド ID をログに記録する場合、perf はデフォルトで継承を無効にします。--inherit オプションを追加して継承 を有効にできます。

21.2. perf レコードで呼び出し先のデータを取得する

perf record ツールを設定して、どの関数がパフォーマンスプロファイル内の他の関数を呼び出しているかを記録することができます。これは、複数のプロセスが同じ関数を呼び出す場合にボトルネックを特定するのに役立ちます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  • --call-graph オプションを使用して、パフォーマンスデータのサンプルと記録を行います。

    $ perf record --call-graph method command
    • command を、サンプルデータを作成するコマンドに置き換えます。コマンドを指定しないと、Ctrl+C を押して手動で停止するまで perf record がデータのサンプリングを行います。
    • method を、以下のアンワインドメソッドのいずれかに置き換えます。

      fp
      フレームポインターメソッドを使用します。GCC オプション --fomit-frame-pointer でビルドされたバイナリーの場合など、コンパイラーの最適化により、スタックをアンワインドできない可能性があります。
      dwarf
      DWARF 呼び出し情報を使用してスタックのアンワインドを行います。
      lbr
      Intel プロセッサーで最後のブランチレコードハードウェアを使用します。

関連情報

  • man ページの perf-record(1)

21.3. perf レポートを使用した perf.data の分析

perf report を使用して perf.data ファイルを表示し、分析できます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。
  • 現行ディレクトリーに perf.data ファイルがある。
  • perf.data ファイルが root アクセスで作成された場合は、root アクセスで perf report を実行する必要もあります。

手順

  • 詳細な分析のために perf.data ファイルの内容を表示します。

    # perf report

    このコマンドは、以下のような出力を表示します。

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

関連情報

  • perf-report(1) man page

第22章 perf mem によるメモリーアクセスのプロファイリング

perf mem コマンドを使用して、システムのメモリーアクセスをサンプルできます。

22.1. perf mem の目的

perf ツールの mem サブコマンドは、メモリーアクセスのサンプリング (読み込みおよ格納) を可能にします。perf mem コマンドは、メモリーのレイテンシーに関する情報、メモリーアクセスの種類、キャッシュヒットおよびミスを引き起こした機能、データシンボルの記録、これらのヒットおよびミスが発生するメモリーの場所に関する情報を提供します。

22.2. perf mem によるメモリーアクセスのサンプリング

この手順では、perf mem コマンドを使用して、システムのメモリーアクセスをサンプルする方法を説明します。このコマンドは、perf record および perf report と同じオプションと、mem サブコマンドに制限される一部のオプションをすべて取ります。記録されたデータは、後で分析するために、現在のディレクトリーの perf.data ファイルに保存されます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  1. メモリーアクセスの例:

    # perf mem record -a sleep seconds

    この例では、sleep コマンドで指示されるように、秒単位の期間にわたる、すべての CPU でのメモリーアクセスを例に挙げています。sleep コマンドは、メモリーアクセスデータをサンプルしたいコマンドに置き換えることができます。デフォルトでは、perf mem は、メモリーロードおよびストアの両方をサンプルします。-t オプションを使用して、perf memrecord 間に「load」または「store」のいずれかを指定します。ロードすると、メモリー階層レベルに関する情報、TLB メモリーアクセス、バススヌーピング、およびメモリーロックがキャプチャーされます。

  2. 分析用に perf.data ファイルを開きます。

    # perf mem report

    上記のコマンド例を使用すると、以下のような出力になります。

    Available samples
    35k cpu/mem-loads,ldlat=30/P
    54k cpu/mem-stores/P

    cpu/mem-loads,ldlat=30/P の行は、メモリーロードで収集されるデータを示し、cpu/mem-stores/P の行はメモリーストアで収集されるデータを示します。対象のカテゴリーを強調表示し、Enter を押してデータを表示します。

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 4067062
    Overhead       Samples  Local Weight  Memory access             Symbol                                                                 Shared Object                 Data Symbol                                                     Data Object                            Snoop         TLB access              Locked
       0.07%            29  98            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            26  97            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%            25  96            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.06%             1  2325          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9084                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.06%             1  2247          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%             1  2166          L1 or L1 hit              [.] 0x00000000038140d6                                                 libxul.so                     [.] 0x00007ffd7b84b4a8                                          [stack]                                None          L1 or L2 hit            No
       0.05%             1  2117          Uncached or N/A hit       [k] check_for_unclaimed_mmio                                           [kernel.kallsyms]             [k] 0xffffb092c1842300                                          [kernel.kallsyms]                      None          L1 or L2 hit            No
       0.05%            22  95            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1898          L1 or L1 hit              [.] 0x0000000002a30e07                                                 libxul.so                     [.] 0x00007f610422e0e0                                          anon                                   None          L1 or L2 hit            No
       0.05%             1  1878          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e8164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.04%            18  94            L1 or L1 hit              [.] 0x000000000000a255                                                 libspeexdsp.so.1.5.0          [.] 0x00007f697a3cd0f0                                          anon                                   None          L1 or L2 hit            No
       0.04%             1  1593          Local RAM or RAM hit      [.] 0x00000000026f907d                                                 libxul.so                     [.] 0x00007f3336d50a80                                          anon                                   Hit           L2 miss                 No
       0.03%             1  1399          L1 or L1 hit              [.] 0x00000000037cb5f1                                                 libxul.so                     [.] 0x00007fbe81ef5d78                                          libxul.so                              None          L1 or L2 hit            No
       0.03%             1  1229          LFB or LFB hit            [.] 0x0000000002962aad                                                 libxul.so                     [.] 0x00007fb6f1be2b28                                          anon                                   None          L2 miss                 No
       0.03%             1  1202          LFB or LFB hit            [.] __pthread_mutex_lock                                               libpthread-2.29.so            [.] 0x00007fb75583ef20                                          anon                                   None          L1 or L2 hit            No
       0.03%             1  1193          Uncached or N/A hit       [k] pci_azx_readl                                                      [kernel.kallsyms]             [k] 0xffffb092c06e9164                                          [kernel.kallsyms]                      None          L2 miss                 No
       0.03%             1  1191          L1 or L1 hit              [k] azx_get_delay_from_lpib                                            [kernel.kallsyms]             [k] 0xffffb092ca7efcf0                                          [kernel.kallsyms]                      None          L1 or L2 hit            No

    データを表示するときに、結果をソートして、対象の異なる側面を調査できます。たとえば、サンプリング期間中に発生したメモリーアクセスの種類ごとに、主な原因となるオーバーヘッドの降順で、メモリー負荷でデータを分類するには、以下を行います。

    # perf mem -t load report --sort=mem

    たとえば、以下のような出力になります。

    Samples: 35K of event 'cpu/mem-loads,ldlat=30/P', Event count (approx.): 40670
    Overhead       Samples  Memory access
      31.53%          9725  LFB or LFB hit
      29.70%         12201  L1 or L1 hit
      23.03%          9725  L3 or L3 hit
      12.91%          2316  Local RAM or RAM hit
       2.37%           743  L2 or L2 hit
       0.34%             9  Uncached or N/A hit
       0.10%            69  I/O or N/A hit
       0.02%           825  L3 miss

関連情報

  • man ページの perf-mem(1)

22.3. perf nen 出力の解釈

修飾子を指定せずに perf mem report コマンドを実行すると表示される表では、データを複数のコラムに分類します。

「Overhead」列
その特定の機能で収集された全体のサンプルのパーセンテージを示します。
「Samples」列
その行でアカウントを指定したサンプル数を表示します。
「Local Weight」の列
プロセッサーのコアサイクルでアクセスレイテンシーを表示します。
「Memory Access」の列
発生したメモリーアクセスのタイプを表示します。
「Symbol」列
関数名またはシンボルを表示します。
「Shared Object」列
サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからのものである場合に [kernel.kallsyms] という名前が使用されます)。
「Data Symbol」の列
行がターゲットとしていたメモリーの場所のアドレスを表示します。
重要

多くの場合、アクセスされるメモリーまたはスタックメモリーの動的割り当てにより、「Data Symbol」の列は raw アドレスを表示します。

「Snoop」の列
バストランザクションを表示します。
「TLB アクセス」の列
TLB メモリーアクセスを表示します。
「Locked」の列
関数がメモリーがロックされたか否かを示します。

デフォルトモードでは、関数は、オーバーヘッドの最も高いものが最初に表示される順に降順でソートされます。

第23章 偽共有の検出

偽共有は、対称型マルチプロセッシング (SMP) システムのプロセッサーコアが、プロセッサー間で共有されていない他のデータアイテムにアクセスするために、他のプロセッサーによって使用されている同じキャッシュラインのデータアイテムを変更すると発生します。

この初期修正では、キャッシュラインを使用する他のプロセッサーがコピーを無効にし、変更されたデータアイテムの更新バージョンをプロセッサーが必要としないにもかかわらず、または必然的にアクセスできる場合でも、更新されたコピーを要求する必要があります。

perf c2c コマンドを使用して、偽共有を検出できます。

23.1. perf c2c の目的

perf ツールの c2c サブコマンドは、Shared Data Cache-to-Cache (C2C) 分析を有効にします。perf c2c コマンドを使用して、キャッシュライン競合を検査し、true と false の両方の共有を検出できます。

キャッシュラインの競合は、対称型マルチプロセッシング (SMP) システムのプロセッサーコアが、他のプロセッサーによって使用されている同じキャッシュラインにあるデータオブジェクトを修正すると発生します。このキャッシュラインを使用する他のプロセッサーはすべて、コピーを無効にして更新されたものを要求します。これにより、パフォーマンスが低下する可能性があります。

perf c2c コマンドは、以下の情報を提供します。

  • 競合が検出されたキャッシュライン
  • データの読み取りおよび書き込みのプロセス
  • 競合の原因となった命令
  • 競合に関連する NUMA (Non-Uniform Memory Access) ノード

23.2. perf c2c でキャッシュライン競合の検出

perf c2c コマンドを使用して、システム内のキャッシュライン競合を検出します。

perf c2c コマンドは、perf record と同じオプションと、c2c サブコマンドに排他的なオプションに対応します。記録されたデータは、後で分析するために、現在のディレクトリーの perf.data ファイルに保存されます。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  • perf c2c を使用してキャッシュラインの競合を検出します。

    # perf c2c record -a sleep seconds

    この例では、sleep コマンドによって指示される期間 (seconds) に対し、すべての CPU でキャッシュライン競合データをサンプルおよび記録します。sleep コマンドは、キャッシュライン競合データを収集するコマンドに置き換えることができます。

関連情報

  • perf-c2c(1) の man ページ

23.3. perf c2c レコードで記録された perf.data ファイルの可視化

この手順では、perf c2c コマンドを使用して記録された perf.data ファイルを視覚化する方法を説明します。

前提条件

手順

  1. perf.data ファイルを開いて詳細な分析を行います。

    # perf c2c report --stdio

    このコマンドは、perf.data ファイルを端末内の複数のグラフに可視化します。

    =================================================
               Trace Event Information
    =================================================
     Total records                     :     329219
     Locked Load/Store Operations      :      14654
     Load Operations                   :      69679
     Loads - uncacheable               :          0
     Loads - IO                        :          0
     Loads - Miss                      :       3972
     Loads - no mapping                :          0
     Load Fill Buffer Hit              :      11958
     Load L1D hit                      :      17235
     Load L2D hit                      :         21
     Load LLC hit                      :      14219
     Load Local HITM                   :       3402
     Load Remote HITM                  :      12757
     Load Remote HIT                   :       5295
     Load Local DRAM                   :        976
     Load Remote DRAM                  :       3246
     Load MESI State Exclusive         :       4222
     Load MESI State Shared            :          0
     Load LLC Misses                   :      22274
     LLC Misses to Local DRAM          :        4.4%
     LLC Misses to Remote DRAM         :       14.6%
     LLC Misses to Remote cache (HIT)  :       23.8%
     LLC Misses to Remote cache (HITM) :       57.3%
     Store Operations                  :     259539
     Store - uncacheable               :          0
     Store - no mapping                :         11
     Store L1D Hit                     :     256696
     Store L1D Miss                    :       2832
     No Page Map Rejects               :       2376
     Unable to parse data source       :          1
    
    =================================================
       Global Shared Cache Line Event Information
    =================================================
     Total Shared Cache Lines          :         55
     Load HITs on shared lines         :      55454
     Fill Buffer Hits on shared lines  :      10635
     L1D hits on shared lines          :      16415
     L2D hits on shared lines          :          0
     LLC hits on shared lines          :       8501
     Locked Access on shared lines     :      14351
     Store HITs on shared lines        :     109953
     Store L1D hits on shared lines    :     109449
     Total Merged records              :     126112
    
    =================================================
                     c2c details
    =================================================
     Events                            : cpu/mem-loads,ldlat=30/P
    	                                    : cpu/mem-stores/P
     Cachelines sort on                : Remote HITMs
     Cacheline data groupping          : offset,pid,iaddr
    
    =================================================
    	   Shared Data Cache Line Table
    =================================================
    #
    #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
    # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
    # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
    #
          0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
          1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
          2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
          3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
          4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7
    
    =================================================
          Shared Cache Line Distribution Pareto
    =================================================
    #
    #        ----- HITM -----  -- Store Refs --        Data address                               ---------- cycles ----------       cpu                                     Shared
    #   Num      Rmt      Lcl   L1 Hit  L1 Miss              Offset      Pid        Code address  rmt hitm  lcl hitm      load       cnt               Symbol                Object                  Source:Line  Node{cpu list}
    # .....  .......  .......  .......  .......  ..................  .......  ..................  ........  ........  ........  ........  ...................  ....................  ...........................  ....
    #
      -------------------------------------------------------------
          0     9834     2269   109036      468            0x602180
      -------------------------------------------------------------
              65.51%   55.88%   75.20%    0.00%                 0x0    14604            0x400b4f     27161     26039     26017         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:144   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.41%    0.35%    0.00%    0.00%                 0x0    14604            0x400b56     18088     12601     26671         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   0.00%    0.00%   24.80%  100.00%                 0x0    14604            0x400b61         0         0         0         9  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:145   0{0-1,4}  1{24-25,120}  2{48,54}  3{169}
    	   7.50%    9.92%    0.00%    0.00%                0x20    14604            0x400ba7      2470      1729      1897         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:154   1{122}  2{144}
    	  17.61%   20.89%    0.00%    0.00%                0x28    14604            0x400bc1      2294      1575      1649         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:158   2{53}  3{170}
    	   8.97%   12.96%    0.00%    0.00%                0x30    14604            0x400bdb      2325      1897      1828         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:162   0{96}  3{171}
    
      -------------------------------------------------------------
          1     2832     1119        0        0            0x602100
      -------------------------------------------------------------
    	  29.13%   36.19%    0.00%    0.00%                0x20    14604            0x400bb3      1964      1230      1788         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:155   1{122}  2{144}
    	  43.68%   34.41%    0.00%    0.00%                0x28    14604            0x400bcd      2274      1566      1793         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:159   2{53}  3{170}
    	  27.19%   29.40%    0.00%    0.00%                0x30    14604            0x400be7      2045      1247      2011         2  [.] read_write_func  no_false_sharing.exe  false_sharing_example.c:163   0{96}  3{171}

23.4. perf c2c report 出力の解釈

本セクションでは、perf c2c report コマンドの出力を解釈する方法を説明します。

perf c2c report --stdio コマンドを実行して表示される視覚化は、データを複数のテーブルに分類します。

Trace Events Information
この表は、perf c2c record コマンドで収集された負荷およびストアサンプルの大まかな概要を示しています。
Global Shared Cache Line Event Information
この表は、共有キャッシュラインに関する統計を提供します。
c2c Details
この表は、サンプルされたイベントと、perf c2c report データを視覚化で編成する方法についての情報を提供します。
Shared Data Cache Line Table
この表は、デフォルトでキャッシュラインごとに検出されるリモート Hitm の量によって、偽共有が検出され、降順に並び替えられるホットテストキャッシュラインの 1 行の概要を提供します。
Shared Cache Line Distribution Pareto

以下の表には、競合が発生している各キャッシュラインに関するさまざまな情報が記載されています。

  • キャッシュラインは NUM 列で番号 0 から始まる番号です。
  • 各キャッシュラインの仮想アドレスは Data address Offset の列に含まれます。また、その後に異なるアクセスが発生したキャッシュラインにオフセットが続きます。
  • Pid 列にはプロセス ID が含まれます。
  • Code Address 列には、インストラクションポインターコードアドレスが含まれます。
  • cycles ラベル下の列には、平均負荷のレイテンシーが表示されます。
  • cpu cnt 列には、生成された CPU の各種サンプルの数を表示します (特定の場所でインデックス化したデータを待つさまざまな CPU の数)。
  • Symbol 列には関数名またはシンボルが表示されます。
  • Shared Object 列は、サンプルの送信元である ELF イメージの名前を表示します (サンプルがカーネルからの場合は [kernel.kallsyms] という名前が使用されます)。
  • Source:Line 列には、ソースファイルと行番号が表示されます。
  • Node{cpu list} 列には、各ノードに対して、どの特定の CPU サンプルが生成されたかが表示されます。

23.5. perf c2c を使用した偽共有の検出

この手順では、perf c2c コマンドを使用して偽共有を検出する方法を説明します。

前提条件

手順

  1. perf.data ファイルを開いて詳細な分析を行います。

    # perf c2c report --stdio

    これにより、端末で perf.data ファイルが開きます。

  2. 「Trace Event Information」テーブルで、LLC Misses to Remote Cache (HITM)の値が含まれる行を見つけます。

    LLC Misses to Remote Cache (HITM) の行の値コラムの割合は、変更したキャッシュラインの NUMA ノード全体で発生していた LLC ミスの割合を表し、偽共有が発生したことを示す主要な指標です。

    =================================================
                Trace Event Information
    =================================================
      Total records                     :     329219
      Locked Load/Store Operations      :      14654
      Load Operations                   :      69679
      Loads - uncacheable               :          0
      Loads - IO                        :          0
      Loads - Miss                      :       3972
      Loads - no mapping                :          0
      Load Fill Buffer Hit              :      11958
      Load L1D hit                      :      17235
      Load L2D hit                      :         21
      Load LLC hit                      :      14219
      Load Local HITM                   :       3402
      Load Remote HITM                  :      12757
      Load Remote HIT                   :       5295
      Load Local DRAM                   :        976
      Load Remote DRAM                  :       3246
      Load MESI State Exclusive         :       4222
      Load MESI State Shared            :          0
      Load LLC Misses                   :      22274
      LLC Misses to Local DRAM          :        4.4%
      LLC Misses to Remote DRAM         :       14.6%
      LLC Misses to Remote cache (HIT)  :       23.8%
      LLC Misses to Remote cache (HITM) : 57.3%
      Store Operations                  :     259539
      Store - uncacheable               :          0
      Store - no mapping                :         11
      Store L1D Hit                     :     256696
      Store L1D Miss                    :       2832
      No Page Map Rejects               :       2376
      Unable to parse data source       :          1
  3. Shared Data Cache Line TableLLC Load Hitm フィールドの Rmt 列を確認します。

      =================================================
                 Shared Data Cache Line Table
      =================================================
      #
      #                              Total      Rmt  ----- LLC Load Hitm -----  ---- Store Reference ----  --- Load Dram ----      LLC    Total  ----- Core Load Hit -----  -- LLC Load Hit --
      # Index           Cacheline  records     Hitm    Total      Lcl      Rmt    Total    L1Hit   L1Miss       Lcl       Rmt  Ld Miss    Loads       FB       L1       L2       Llc       Rmt
      # .....  ..................  .......  .......  .......  .......  .......  .......  .......  .......  ........  ........  .......  .......  .......  .......  .......  ........  ........
      #
            0            0x602180   149904   77.09%    12103     2269     9834   109504   109036      468       727      2657    13747    40400     5355    16154        0      2875       529
            1            0x602100    12128   22.20%     3951     1119     2832        0        0        0        65       200     3749    12128     5096      108        0      2056       652
            2  0xffff883ffb6a7e80      260    0.09%       15        3       12      161      161        0         1         1       15       99       25       50        0         6         1
            3  0xffffffff81aec000      157    0.07%        9        0        9        1        0        1         0         7       20      156       50       59        0        27         4
            4  0xffffffff81e3f540      179    0.06%        9        1        8      117       97       20         0        10       25       62       11        1        0        24         7

    この表は、キャッシュ行ごとに検出されるリモート Hitm の量によって降順で並び替えられます。LLC Load Hitm セクションの Rmt 列の数値が大きい場合は、偽共有を示しており、偽共有アクティビティをデバッグするには、それが発生したキャッシュラインをさらに検査する必要があります。

第24章 flamegraphs の使用

システム管理者は、flamegraphs を使用して、perf ツールで記録されたシステムパフォーマンスデータの視覚化を作成できます。ソフトウェア開発者は、flamegraphs を使用して、perf ツールで記録されたアプリケーションパフォーマンスデータの視覚化を作成できます。

スタックトレースのサンプリングは、perf ツールを使用して CPU パフォーマンスをプロファイリングするための一般的な方法です。ただし、perf を使用したプロファイリングスタックトレースの結果は、極めて詳細にわたるので、分析の工数がかなりかかる可能性があります。flamegraphs は、perf で記録されたデータから作成された視覚化で、より早く、簡単にホットコードパスを特定できるようにします。

24.1. flamegraphs のインストール

flamegraphs の使用を開始するには、必要なパッケージをインストールします。

手順

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

    # yum install js-d3-flame-graph

24.2. システム全体でのフレームグラフの作成

この手順では、flamegraphs を使用して、システム全体で記録されたパフォーマンスデータを視覚化する方法を説明します。

前提条件

手順

  • データを記録し、視覚化を作成します。

    # perf script flamegraph -a -F 99 sleep 60

    このコマンドは、sleep コマンドを使用して調整されるように、60 秒にわたりシステム全体でパフォーマンスデータをサンプルおよび記録し、現在のアクティブなディレクトリーに flamegraph.html として保存される視覚化を構築します。このコマンドは、デフォルトで呼び出しグラフデータをサンプルし、perf ツールと同じ引数を取ります。この例では、以下のようになります。

    -a
    システム全体でデータを記録するように調整します。
    -F
    1 秒あたりのサンプリング頻度を設定します。

検証手順

  • 分析するには、生成された視覚化を表示します。

    # xdg-open flamegraph.html

    このコマンドにより、デフォルトのブラウザーで視覚化が開きます。

    flamegraph allcpus

24.3. 特定プロセスにおけるフレームグラフの作成

flamegraphs を使用して、特定の実行中のプロセスで記録されたパフォーマンスデータを視覚化できます。

前提条件

手順

  • データを記録し、視覚化を作成します。

    # perf script flamegraph -a -F 99 -p ID1,ID2 sleep 60

    このコマンドは、sleep コマンドの使用で規定されているようにプロセス ID が ID1 および ID2 のプロセスのパフォーマンスデータを 60 秒間にわたりサンプルして記録します。次に、flamegraph.html として現在のアクティブディレクトリーに保存される視覚化を構築します。このコマンドは、デフォルトで呼び出しグラフデータをサンプルし、perf ツールと同じ引数を取ります。この例では、以下のようになります。

    -a
    システム全体でデータを記録するように調整します。
    -F
    1 秒あたりのサンプリング頻度を設定します。
    -p
    特定のプロセス ID をシュミュレートし、データをサンプリングして記録します。

検証手順

  • 分析するには、生成された視覚化を表示します。

    # xdg-open flamegraph.html

    このコマンドにより、デフォルトのブラウザーで視覚化が開きます。

    flamegraph

24.4. flamegraphs の解釈

フレームグラフの各ボックスは、スタック内の異なる関数を示しています。スタックの深さは、x 軸で示されています。CPU でサンプルされた実際の関数は、最も上のボックスで、その他下のものは、その上位となります。X 軸は、サンプルの呼び出しグラフデータの近接性を表示します。

特定の行のスタックの子は、x 軸に沿って降順でそれぞれの関数から取得されたサンプルの数に基づいて表示されます。x 軸は時間の経過を表すものではありません。ボックスが広いほど、データがサンプリングされていたときに、CPU 上または CPU 上の一部での頻度が高いことを意味します。

手順

  • 以前表示されていない可能性のある関数の名前を確認するには、フレームグラフ内のボックスをクリックしてその特定の場所のスタックに拡大します。

    zoomed in flamegraph

  • フレームグラフのデフォルトビューに戻るには、Reset Zoom をクリックします。
重要

ユーザー空間関数を表すボックスには、関数のバイナリーが取り除かれているため、flamegraphsUnknown とラベルが付けられる場合があります。実行可能ファイルの debuginfo パッケージがインストールされているか、または実行可能ファイルがローカルで開発したアプリケーションである場合は、アプリケーションはデバッグ情報と共にコンパイルされる必要があります。GCC で -g オプションを使用して、このような状況で関数名またはシンボルを表示します。

flamegraph

第25章 perf circular バッファーを使用したパフォーマンスのボトルネックの監視

システムで実行されている特定のプロセスまたはアプリケーションの一部のパフォーマンスのボトルネックを監視するために、perf ツールを使用してデータのイベント固有のスナップショットを取得する循環バッファーを作成できます。このような場合には、perf は、指定されたイベントが検出されると、後で分析するために perf.data ファイルにデータのみを書き込みます。

25.1. perf を使用した循環バッファーおよびイベント固有のスナップショット

perf を使用してプロセスまたはアプリケーションでパフォーマンスの問題を調査する場合、特定の対象イベントが発生する前の数時間のデータを記録することは、簡単ではない、または適切ではない場合があります。このような場合は、perf record を使用して、特定のイベントの後にスナップショットを取得するカスタムの循環バッファーを作成できます。

--overwrite オプションを使用すると、perf record は上書き可能な循環バッファーにすべてのデータを保存します。バッファーがいっぱいになると、perf record が最も古いレコードを自動的に上書きするため、perf.data ファイルに書き込まれることはありません。

--overwrite および --switch-output-event オプションを併用すると、--switch-output-event トリガーイベントを検出するまで、データを継続的に記録およびダンプする循環バッファーが設定されます。トリガーイベントは、ユーザーが関心のある何かが発生したので、循環バッファー内のデータを perf.data ファイルに書き込むように perf record に通知します。これにより、関心のある特定のデータが収集されると同時に、perf.data ファイルに不要なデータを書き込まないことで、実行中の perf プロセスのオーバーヘッドが削減されます。

25.2. perf 循環バッファーを使用したパフォーマンスのボトルネックを監視するための特定のデータの収集

perf ツールを使用すると、関心のあるデータのみを収集するために指定したイベントによってトリガーされる循環バッファーを作成できます。イベント固有のデータを収集する循環バッファーを作成するには、perf--overwrite および --switch-output-event オプションを使用します。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。
  • プロセスまたはアプリケーション内の関心のある場所に、監視したいプロセスまたはアプリケーションに uprobe を配置している。

    # perf probe -x /path/to/executable -a function
    Added new event:
      probe_executable:function   (on function in /path/to/executable)
    
    You can now use it in all perf tools, such as:
    
            perf record -e probe_executable:function -aR sleep 1

手順

  • トリガーイベントとして uprobe を使用して循環バッファーを作成します。

    # perf record --overwrite -e cycles --switch-output-event probe_executable:function ./executable
    [ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012231959 ]
    [ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012232008 ]
    ^C[ perf record: dump data: Woken up 1 times ]
    [ perf record: Dump perf.data.2021021012232082 ]
    [ perf record: Captured and wrote 5.621 MB perf.data.<timestamp> ]

    この例では、実行可能ファイルを開始し、-e オプションの後に指定された CPU サイクルを、perf--switch-output-event オプションの後に指定されたトリガーイベントである uprobe を検出するまで収集します。この時点で、perf は循環バッファーにあるすべてのデータのスナップショットを取得し、タイムスタンプで識別される一意の perf.data ファイルに保存します。この例では、合計 2 つのスナップショットが生成され、最後の perf.data ファイルは Ctrl+c を押すことによって強制されました。

第26章 perf を停止または再起動せずに、実行中の perf コレクターからトレースポイントを追加および削除する

コントロールパイプインターフェースを使用して、実行中の perf コレクターで異なるトレースポイントを有効化および無効化することで、perf を停止または再起動せずに、収集するデータを動的に調整できます。これにより、プロセスの停止または再起動中に記録されたはずのパフォーマンスデータが失われることはありません。

26.1. perf を停止または再起動せずに、実行中の perf コレクターにトレースポイントを追加する

コントロールパイプインターフェースを使用して実行中の perf コレクターにトレースポイントを追加し、perf を停止してパフォーマンスデータを損失することなく録画中のデータを調整します。

前提条件

  • perf ユーザー空間ツールがインストールされている。詳細は「perf のインストール」を参照してください。

手順

  1. 制御パイプインターフェースを設定します。

    # mkfifo control ack perf.pipe
  2. コントロールファイル設定と、有効にするイベントで perf record を実行します。

    # perf record --control=fifo:control,ack -D -1 --no-buffering -e 'sched:*' -o - > perf.pipe

    この例では、-e オプションの後に 'sched:*' を宣言すると、スケジューラーイベントで perf record が開始されます。

  3. 2 つ目の端末で、制御パイプの読み取り側を起動します。

    # cat perf.pipe | perf --no-pager script -i -

    コントロールパイプの読み取り側を起動すると、最初の端末で以下のメッセージがトリガーされます。

    Events disabled
  4. 3 つ目の端末で、制御ファイルを使用してトレースポイントを有効にします。

    # echo 'enable sched:sched_process_fork' > control

    このコマンドは perf をトリガーし、宣言されたイベントについて制御ファイル内の現在のイベント一覧をスキャンします。イベントが存在する場合は、トレースポイントが有効になり、次のメッセージが最初の端末に表示されます。

    event sched:sched_process_fork enabled

    トレースポイントを有効にすると、2 つ目の端末は、トレースポイントを検出した perf の出力を表示します。

    bash 33349 [034] 149587.674295: sched:sched_process_fork: comm=bash pid=33349 child_comm=bash child_pid=34056

26.2. perf を停止または再起動せずに、実行中の perf コレクターからトレースポイントを削除する

制御パイプインターフェースを使用して、実行中の perf コレクターからトレースポイントを削除し、perf を停止してパフォーマンスデータを失うことなく収集するデータの範囲を減らします。

前提条件

手順

  • トレースポイントを削除します。

    # echo 'disable sched:sched_process_fork' > control
    注記

    この例では、以前にスケジューラーイベントをコントロールファイルに読み込み、トレースポイント sched:sched_process_fork を有効にしていることを前提としています。

    このコマンドは perf をトリガーし、宣言されたイベントについて制御ファイル内の現在のイベント一覧をスキャンします。イベントが存在する場合は、トレースポイントが無効になり、制御パイプの設定に使用する端末に以下のメッセージが表示されます。

    event sched:sched_process_fork disabled

第27章 numastat を使用したメモリー割り当てのプロファイリング

numastat ツールを使用すると、システムのメモリー割り当てに関する統計を表示できます。

numastat ツールは、各 NUMA ノードのデータを個別に表示します。この情報を使用して、システムのメモリーパフォーマンスや、システムのさまざまなメモリーポリシーの効果を調査できます。

27.1. デフォルトの numastat 統計

デフォルトでは、numastat ツールは、各 NUMA ノードの以下のカテゴリーに対する統計を表示します。

numa_hit
このノードに正常に割り当てられていたページ数。
numa_miss
対象のノードのメモリーが少ないために、このノードに割り当てたページ数。それぞれの numa_miss イベントには、別のノードで対応する numa_foreign イベントがあります。
numa_foreign
代わりに別のノードに割り当てられたこのノードについて最初に意図されたページ数です。それぞれの numa_foreign イベントには、対応する numa_miss イベントが別のノードにあります。
interleave_hit
このノードに正常に割り当てられるインターリーブポリシーページの数。
local_node
このノードのプロセスで、このノードで正常に割り当てられるページ数。
other_node
別のノードのプロセスでこのノードに割り当てられるページ数。
注記

高い numa_hit の値と低い numa_miss の値 (互いに相対的) は、最適なパフォーマンスを示します。

27.2. numastat を使用したメモリー割り当ての表示

numastat ツールを使用してシステムのメモリー割り当てを表示できます。

前提条件

  • numactl パッケージをインストールする。

    # yum install numactl

手順

  • システムのメモリー割り当てを表示する。

    $ numastat
                                 node0         node1
    numa_hit                  76557759      92126519
    numa_miss                 30772308      30827638
    numa_foreign              30827638      30772308
    interleave_hit              106507        103832
    local_node                76502227      92086995
    other_node                30827840      30867162

関連情報

  • numastat(8) の man ページ

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

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

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

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

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

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

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

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

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

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

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

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

28.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
  • システムのグラフィカル表現を表示するには、以下のコマンドを実行します。

    # yum install hwloc-gui
    # lstopo

    図28.1 lstopo の出力

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

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

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

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

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

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

手順

  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. オプション: カーネルの ライトバック 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

28.4. 割り込み要求の概要

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

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

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

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

28.4.1. 割り込みの手動分散

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

手順

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

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

    $ journalctl --dmesg | grep APIC

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

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

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

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

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

関連情報

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

28.4.2. smp_affinity マスクの設定

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

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

手順

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

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

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

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

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

29.1. スケジューリングポリシーのカテゴリー

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

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

標準ポリシー
通常スレッドは、通常の優先度のタスクに使用されます。
リアルタイムポリシー

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

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

関連情報

  • sched(7)sched_setaffinity(2)sched_getaffinity(2)sched_setscheduler(2)、および sched_getscheduler(2)

29.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 秒) です。

29.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 ミリ秒 です。

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

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

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

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

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

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

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

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

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

-f

--fifo

スケジュールを SCHED_FIFO に設定

-o

--other

スケジュールを SCHED_OTHER に設定

-r

--rr

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

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

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

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

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

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

前提条件

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

    # yum 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

関連情報

29.8. 優先順位マップ

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

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

表29.2 優先度範囲の説明

優先度スレッド詳細

1

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

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

2 - 49

利用可能

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

50

デフォルトの hard-IRQ 値

 

51 - 98

優先度の高いスレッド

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

99

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

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

29.9. cpu-partitioning プロファイル

cpu-partitioning プロファイルは、CPU をシステムレベルの中断から分離するために使用されます。これらの CPU を分離したら、特定のアプリケーションに割り当てることができます。これは、低レイテンシー環境や、ハードウェアから最大パフォーマンスを抽出する環境で非常に便利です。

このプロファイルでは、ハウスキーピング CPU を指定することもできます。ハウスキーピング CPU は、全サービス、デーモン、シェルプロセス、およびカーネルスレッドを実行するために使用されます。

以下の設定オプションを使用して、cpu-partitioning プロファイルを /etc/tuned/cpu-partitioning-variables.conf ファイルで設定できます。

isolated_cores=cpu-list
分離する CPU を一覧表示します。分離された CPU の一覧はコンマで区切るか、または 3-5 のようにダッシュを使用して範囲を指定できます。このオプションは必須です。この一覧にない CPU は、自動的にハウスキーピング CPU と見なされます。
no_balance_cores=cpu-list
システム全体のプロセスの負荷分散時に、カーネルに考慮されない CPU の一覧を表示します。このオプションは任意です。通常、これは isolated_cores と同じリストです。

関連情報

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

第30章 I/O およびファイルシステムパフォーマンスに影響を与える要因

ストレージおよびファイルシステムパフォーマンスに適した設定は、ストレージの目的より大きく左右されます。

I/O およびファイルシステムのパフォーマンスは、以下のいずれかの要因により影響を受ける可能性があります。

  • データの書き込みまたは読み取りパターン
  • 順次または無作為
  • バッファーまたはダイレクト IO
  • 基礎となるジオメトリーとのデータ調整
  • ブロックサイズ
  • ファイルシステムのサイズ
  • ジャーナルサイズおよび場所
  • アクセス時間の記録
  • データの信頼性確保
  • 事前にフェッチするデータ
  • ディスク領域の事前割り当て
  • ファイルの断片化
  • リソースの競合

30.1. I/O およびファイルシステムの問題を監視および診断するツール

Red Hat Enterprise Linux 8 では、システムパフォーマンスを監視し、I/O、ファイルシステム、その設定に関連するパフォーマンス問題を診断するために、以下のツールを利用できます。

  • vmstat ツールは、システム全体のプロセス、メモリー、ページング、ブロック I/O、割り込み、および CPU アクティビティーに関する報告を行います。管理者はこのツールを使用することで、パフォーマンスの問題が I/O サブシステムによるものかを判断しやすくなります。vmstat を使用した分析で、I/O サブシステムが原因でパフォーマンスが低下していることがわかった場合に、管理者は iostat ツールを使用して原因となる I/O デバイスを判別できます。
  • iostat は、システムでの I/O デバイスの負荷を報告します。このツールは sysstat パッケージで提供されます。
  • blktrace は、I/O サブシステムでの時間の使用について詳細にわたる情報を提供します。同梱のユーティリティーである blkparse は、blktrace からのロー出力を読み取り、blktrace が記録した入出力操作を人間が判読できるようにまとめます。
  • bttblktrace 出力を分析し、I/O スタックのエリアごとにデータが費やした時間を表示するので、I/O サブシステムのボトルネックを見つけやすくなります。このユーティリティーは、blktrace パッケージの一部として提供されます。blktrace メカニズムで追跡され、btt が分析する重要なイベントには、以下のようなものがあります。

    • I/O イベント (Q) のキュー
    • ドライバーイベント (D) への I/O のディスパッチ
    • I/O イベントの完了 (C)
  • iowatcherblktrace 出力を使用して、I/O を経時的にグラフ化できます。このツールは、ディスク I/O の論理ブロックアドレス (LBA)、1 秒あたりのスループット (メガバイト単位)、シーク数および I/O 操作に重点を置いています。これを使用することで、デバイスの演算回数の上限に到達するタイミングを判断しやすくなります。
  • BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。BCC ツールは、/usr/share/bcc/tools/ ディレクトリーにインストールされます。以下の bcc-tools は、パフォーマンスの分析に役立ちます。

    • biolatency は、ブロックデバイス I/O(ディスク I/O)のレイテンシーをヒストグラムにまとめています。これにより、デバイスのキャッシュヒット、キャッシュミス、レイテンシーアウトライナーの 2 つのモードなど、分散を調査できます。
    • biosnoop は、基本的なブロック I/O 追跡ツールで、各 I/O イベントの表示、プロセス ID および I/O レイテンシーの発行を行います。このツールを使用して、ディスク I/O パフォーマンスの問題を調査できます。
    • biotop は、カーネルのブロック I/O 操作に使用します。
    • Filelife ツールは、 stat() システムコールを追跡します。
    • fileslower は、読み取りと書き込みが遅い同期ファイルを追跡します。
    • filetop は、プロセスによるファイルの読み取りと書き込みを表示します。
    • ext4slowernfsslower および xfsslower は、特定のしきい値よりも操作速度の遅いファイルを表示するツールです (デフォルト値 10ms)。

      詳細は、「BPF コンパイラーコレクションでシステムパフォーマンスの分析」を参照してください。

  • bpftace は、パフォーマンスの問題の分析に使用される eBPF のトレース言語です。また、システムの監査用に BCC のような追跡ユーティリティーが含まれており、I/O のパフォーマンスの問題を調査するのに役立ちます。
  • 以下の SystemTap スクリプトは、ストレージまたはファイルシステムのパフォーマンスの問題の診断に役立ちます。

    • disktop.stp: 5 秒ごとにディスクの読み取りまたは書き込みのステータスを確認し、その期間の上位 10 エントリーを出力します。
    • iotime.stp: 読み取り、書き込み操作に使用した時間、読み取りおよび書き込みバイト数を出力します。
    • traceio.stp: 確認された累積 I/O トラフィックに基づいて上位 10 の実行可能ファイルを秒単位で出力します。
    • traceio2.stp: 指定したデバイスに読み取りおよび書き込みが行われると、実行可能ファイル名とプロセス ID を出力します。
    • inodewatch.stp: 指定したメジャー/マイナーデバイスで、指定の inode に対して読み取りまたは書き込みが行われるたびに、実行可能ファイル名とプロセス ID を出力します。
    • inodewatch2.stp: 指定したメジャー/マイナーデバイスの指定の inode で属性が変更されるたびに、実行可能ファイル名とプロセス ID、属性を出力します。

関連情報

30.2. ファイルシステムのフォーマットに利用可能なチューニングオプション

一部のファイルシステム設定は一旦決定すると、デバイスのフォーマット後に変更できません。

以下は、ストレージデバイスをフォーマットする前に利用可能なオプションです。

Size (サイズ)
ワークロードに適したサイズのファイルシステムを作成します。ファイルシステムが小さいと、ファイルシステムのチェックにかかる時間とメモリーが少なくて済みます。ただし、ファイルシステムが小さすぎると、断片化が多くなり、パフォーマンスが低下します。
ブロックサイズ

ブロックは、ファイルシステムの作業単位です。ブロックサイズで、単一のブロックに保存可能なデータ量が決まるので、1 度に書き込みまたは読み取りされる最小データ量を指します。

デフォルトのブロックサイズは、ほとんどのユースケースに適しています。ただし、ブロックサイズや複数のブロックのサイズが、一般的に一度に読み取る/書き込むデータ量と同じか、若干多い場合には、ファイルシステムのパフォーマンスは向上し、データの保存をより効率的に行います。ファイルが小さい場合は、引き続きブロック全体を使用します。ファイルは複数のブロックに分散できますが、ランタイム時のオーバーヘッドが増える可能性があります。

また、ファイルシステムによっては、特定のブロック数が上限となっており、ファイルシステムの最大数が制限されます。mkfs コマンドでデバイスをフォーマットする時に、ファイルシステムのオプションの一部としてブロックサイズを指定します。ブロックサイズを指定するパラメーターは、ファイルシステムによって異なります。

ジオメトリー

ファイルシステムジオメトリーは、ファイルシステム全体でのデータの分散に関係があります。システムで RAID などのストライプ化ストレージを使用する場合は、デバイスのフォーマット時にデータおよびメタデータを下層にあるストレージジオメトリーに合わせて調整することで、パフォーマンスを向上させることができます。

多くのデバイスは推奨のジオメトリーをエクスポートし、デバイスが特定のファイルシステムでフォーマットされるとそのジオメトリーが自動的に設定されます。デバイスでこのような推奨ジオメトリーをエクスポートしない場合や、推奨の設定を変更する場合には、mkfs コマンドでデバイスのフォーマット時にジオメトリーを指定する必要があります。

ファイルシステムのジオメトリーを指定するパラメーターは、ファイルシステムによって異なります。

外部ジャーナル
ジャーナリングファイルシステムは、操作を実行する前に、ジャーナルファイルに書き込み操作中に加えられる変更を文書化します。これにより、システムクラッシュや電源異常の発生時にストレージデバイスが破損する可能性が低下し、復旧プロセスが高速化されます。
注記

Red Hat では、外部ジャーナルオプションの使用は推奨していません。

メタデータ集約型のワークロードでは、ジャーナルへの更新頻度が非常に多くなります。ジャーナルが大きいと、より多くのメモリーを使用しますが、書き込み操作の頻度は低減します。さらに、プライマリーストレージと同じか、それ以上の速度の専用ストレージにジャーナルを配置することで、メタデータ集約型のワークロードでデバイスのシーク時間を短縮できます。

警告

外部ジャーナルが信頼できることを確認します。外部ジャーナルデバイスが損失すると、ファイルシステムが破損します。外部ジャーナルは、フォーマット時に作成し、マウント時にジャーナルデバイスを指定する必要があります。

関連情報

30.3. ファイルシステムのマウントに利用可能なチューニングオプション

以下は、ほとんどのファイルシステムで利用可能なオプションで、デバイスのマウント時に指定できます。

Access Time

ファイルが読み込まれるたびに、ファイルのメタデータはアクセス時点で更新されます (atime)。この際、追加の書き込み I/O が行われます。ほとんどのファイルシステムの atime のデフォルト設定は relatime です。

ただし、このメタデータの更新に時間がかかる場合で正確なアクセス時間データが必要ない場合には、noatime マウントオプションを指定してファイルシステムをマウントしてください。この設定で、ファイルの読み取り時にメタデータへの更新が無効になります。また、nodiratime 動作も有効にし、ディレクトリーの読み取り時にメタデータへの更新を無効にします。

注記

noatime mount オプションを使用して atime の更新を無効にすると、バックアッププログラムなどに依存するアプリケーションが破損する可能性があります。

read-ahead

Read-ahead 動作では、すぐに必要となる可能性の高いデータを事前にフェッチし、ページキャッシュ (ディスク上にある場合よりも早くデータを取得可能) に読み込むことでファイルのアクセス時間を短縮します。read-ahead 値が大きいほど、さらに事前にシステムのデータがフェッチされます。

Red Hat Enterprise Linux は、ファイルシステムについて検出した内容に基づいて、適切な read-ahead 値の設定を試みます。ただし、正確な検出が常に可能であるとは限りません。たとえば、ストレージアレイが単一の LUN としてシステムに表示した場合に、システムはその単一の LUN を検出するので、アレイに適した read-ahead 値は設定されません。

連続 I/O を大量にストリーミングするワークロードは、read-ahead 値を高くすると効果がある場合が多いです。Red Hat Enterprise Linux で提供されるストレージ関連の tuned プロファイルは、LVM ストライプ化と同様に read-ahead 値を増やしますが、このような調整は、ワークロードすべてで常に十分であるというわけではありません。

関連情報

  • mount(8)xfs(5)、および ext4(5) の man ページ

30.4. 未使用ブロックの破棄の種類

ファイルシステムで未使用のブロックを破棄することは、ソリッドステートディスク (SSD) およびシンプロビジョニングストレージのいずれの場合でも推奨のプラクティスです。

以下は、未使用のブロックを破棄する 2 つの方法です。

バッチ破棄
fstrim コマンドに、このタイプの破棄が含まれています。ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。Red Hat Enterprise Linux 8 は、XFS および ext4 でフォーマットされおり、物理的な破棄操作に対応するデバイスでのバッチ破棄をサポートします。
オンライン破棄

このタイプの破棄操作は、discard オプションを指定してマウント時に設定します。この操作は、ユーザーの介入なしにリアルタイムで実行されます。ただし、未使用から空き状態に移行しているブロックのみを破棄します。Red Hat Enterprise Linux 8 は、XFS および ext4 でフォーマットされたデバイスでのオンライン破棄をサポートします。

Red Hat は、パフォーマンスを維持するためにオンライン破棄が必要な場合や、システムのワークロードでバッチ破棄を実行できない場合を除き、バッチ破棄を推奨します。

事前割り当てでは、領域にデータを書き込むことなく、ファイルに割り当て済みとしてディスク領域をマークします。これは、データの断片化や、読み取りのパフォーマンスの低下を抑える場合に役立ちます。Red Hat Enterprise Linux 8 は、XFS、ext4、および GFS2 ファイルシステムでの領域の事前割り当てに対応します。アプリケーションは、fallocate(2) glibc 呼び出しを使用して、事前割り当てした領域の利点を活用することもできます。

関連情報

  • mount(8) および fallocate(2) の man ページ

30.5. ソリッドステートディスク (SSD) の調整に関する考慮事項

ソリッドステートディスク (SSD) は、回転磁気プラッターではなく、NAND フラッシュチップを使用して永続データを保存します。SSD は、完全な論理ブロックアドレス範囲のデータにアクセスする時間を一定に保ち、回転プラッターのように、測定できるレベルでシーク数を犠牲にすることがありません。ギガバイト単位のストレージ領域としてはより高価で、ストレージ密度が少なくなっていますが、HDD に比べ、レイテンシーが低く、スループットが高くなっています。

SSD の使用済みのブロックが、ディスク容量を占有してくると、通常パフォーマンスは低下します。パフォーマンスの低下レベルはベンダーによって異なりますが、このような状況では、すべてのデバイスでパフォーマンスが低下します。破棄動作を有効にすると、この低下を軽減できます。詳細は、「未使用ブロックの破棄の種類」を参照してください。

デフォルトの I/O スケジューラーおよび仮想メモリーオプションは、SSD での使用に適しています。設定時には、SSD のパフォーマンスに影響を与える可能性がある以下の要素を考慮してください。

I/O スケジューラー

I/O スケジューラーはどれでも、ほとんどの SSD で適切に動作することが想定されます。ただし、Red Hat は、他のストレージタイプと同様に、特定のワークロードに最適な設定を決定するためにベンチマーク設定を行うことを推奨します。Red Hat は、SSD を使用する場合には、特定のワークロードのベンチマーク設定を行う場合のみ、I/O スケジューラーを変更することを推奨します。I/O スケジューラー間の切り替え方法は、/usr/share/doc/kernel-version/Documentation/block/switching-sched.txt ファイルを参照してください。

単一キュー HBA の場合は、デフォルトの I/O スケジューラーは deadline です。複数のキュー HBA の場合は、デフォルトの I/O スケジューラーは none です。I/O スケジューラーの設定方法は、「ディスクスケジューラーの設定」を参照してください。

仮想メモリー
I/O スケジューラーと同様に、仮想メモリー (VM) サブシステムには特別なチューニングは必要ありません。SSD の I/O が高速であるという性質をもとに、vm_dirty_background_ratiovm_dirty_ratio 設定の値を下げ、書き出しのアクティビティーが増えても通常は、ディスクの他の操作のレイテンシーに悪影響はありません。ただし、このチューニングで全体的な I/O が生み出されるので、ワークロード固有のテストがない場合には通常推奨していません。
スワップ
SSD はスワップデバイスとしても使用でき、ページアウトおよびページインのパフォーマンスが向上する可能性が高くなります。

30.6. 汎用ブロックデバイスのチューニングパラメーター

本セクションに記載する汎用チューニングパラメーターは、/sys/block/sdX/queue/ ディレクトリーにあります。

以下のチューニングパラメーターは、I/O スケジューラーチューニングとは別のパラメーターで、全 I/O スケジューラーに適用されます。

add_random
一部の I/O イベントは、/dev/random のエントロピープールに貢献します。これらの貢献のオーバーヘッドが測定できるレベルになった場合には、このパラメーターを 0 に設定してください。
iostats

デフォルトでは、iostats は有効で、デフォルト値は 1 です。iostats 値を 0 に設定すると、デバイスの I/O 統計の収集が無効になり、I/O パスでのオーバーヘッドが少し削除されます。また、iostats0 に設定すると、特定の NVMe ソリッドステートストレージデバイスなど、非常に高性能なデバイスのパフォーマンスが若干向上します。特定のストレージモデルで無効にするようにベンダーからの指示がない限り、iostats は有効のままにしておくことを推奨します。

iostats を無効にすると、デバイスの I/O 統計が /proc/diskstats ファイルからなくなります。I/O 情報は、/sys/diskstats ファイルの内容をソースとしており、sariostats などの I/O ツールの監視に使用します。したがって、デバイスの iostats パラメーターを無効にすると、デバイスは I/O 監視ツールの出力に表示されなくなります。

max_sectors_kb

I/O 要求の最大サイズを KB 単位で指定します。デフォルト値は 512 KB です。このパラメーターの最小値は、ストレージデバイスの論理ブロックサイズで決まります。このパラメーターの最大値は、max_hw_sectors_kb の値で決まります。

Red Hat は、max_sectors_kb を常に最適な I/O サイズと内部消去ブロックサイズの倍数にするように推奨しています。0 が指定されているか、ストレージデバイスによる指定がない場合には、どちらかのパラメーターの logical_block_size の値を使用します。

nomerges
要求をマージは、ほとんどのワークロードで有用です。ただし、デバッグの目的では、マージを無効にすると便利です。デフォルトでは、nomerges パラメーターは 0 に設定されており、マージが有効です。単純な 1 回だけのマージを無効にするには nomerges1 に設定します。すべてのタイプのマージを無効にするには、nomerges2 に設定します。
nr_requests
キューに配置可能な最大 I/O 数です。現在の I/O スケジューラーが none の場合は、この数値を減らすことができますが、それ以外の場合は数字の増減が可能です。
optimal_io_size
このパラメーターで最適な I/O サイズを報告するストレージデバイスもあります。Red Hat では、この値が報告される場合に、できるだけ報告された最適な I/O サイズに合わせその倍数の I/O をアプリケーションで発行させることを推奨しています。
read_ahead_kb

連続読み込み操作中にオペレーティングシステムが読み取ることができる最大キロバイト数を定義します。その結果、必要な情報は、次の連続読み込みのカーネルページキャッシュにすでに存在するので、読み取り I/O のパフォーマンスが向上します。

read_ahead_kb の値を大きくすると、デバイスマッパーは効果を得られます。開始点として、各デバイスに対して 128 KB の値に指定すると適切です。ディスクの read_ahead_kb の値を、要求キューのディスクの max_sectors_kb まで増やすと、大型のファイルの連続読み込みが行われるアプリケーション環境でパフォーマンスが向上する可能性があります。

rotational
一部のソリッドステートディスクは、ソリッドステートのステータスを正しく公開せず、従来の回転ディスクとしてマウントされます。スケジューラーで不要なシーク時間短縮ロジックを無効にするには、rotational の値を 0 に手動で設定します。
rq_affinity
rq_affinity のデフォルト値は 1 です。これは、発行した CPU コアと同じ CPU グループにある CPU コア 1 つで I/O 操作を完了します。I/O 要求を発行したプロセッサーでのみ I/O 操作を完了するには、rq_affinity2 に設定します。上記の 2 つの機能を無効にするには、0 に設定します。
scheduler
特定のストレージデバイスにスケジューラーまたはスケジューラーの優先度を設定するには、/sys/block/devname/queue/scheduler ファイルを編集します。ここで、devname は設定するデバイスの名前に置き換えます。

第31章 ネットワークリソースへのアクセスを最適化するようにオペレーティングシステムを設定

本セクションでは、ワークロード全体でネットワークリソースへのアクセスを最適化するようにオペレーティングシステムを設定する方法を説明します。ネットワークパフォーマンスの問題は、ハードウェアの誤作動やインフラストラクチャーの障害が原因であることがあります。これらの問題の解決については、本書では扱いません。

Tuned サービスは、さまざまなプロファイルを提供し、特定のユースケースでパフォーマンスを向上します。

  • latency-performance
  • network-latency
  • network-throughput

31.1. パフォーマンス問題の監視および診断を行うツール

以下は、Red Hat Enterprise Linux 8 で利用可能なツールです。システムパフォーマンスを監視し、ネットワークサブシステムに関連するパフォーマンス問題を診断するために使用されます。

  • ss ユーティリティーはソケットに関する統計情報を出力するため、管理者は時間とともにデバイスのパフォーマンスを評価できます。デフォルトでは、ss は、確立された接続があるオープンな TCP ソケットを表示します。管理者は、コマンドラインオプションを使用すると、特定のソケットに関する統計をフィルタリングできます。Red Hat は、Red Hat Enterprise Linux では、非推奨の netstat よりも ss を推奨しています。
  • ip を使用すると、管理者はルート、デバイス、ルーティングポリシー、およびトンネルを管理および監視できます。ip monitor コマンドは、デバイス、アドレス、およびルートの状態を継続的に監視できます。-j オプションを使用して JSON 形式で出力を表示します。これは、他のユーティリティーに提供して情報処理を自動化することができます。
  • dropwatch は、dropwatch パッケージが提供する対話式のツールです。カーネルがドロップしたパケットを監視して記録します。
  • ethtool ユーティリティーを使用すると、管理者はネットワークインターフェースカード設定を表示および編集できます。このツールを使用して、特定デバイスのドロップしたパケット数などの統計情報を監視します。ethtool -S device name コマンドを使用して、監視するデバイスの指定されたデバイスのカウンターの状態を表示します。
  • /proc/net/snmp ファイルは、snmp エージェントが IP、ICMP、TCP、UDP の監視および管理に使用するデータを表示します。このファイルを定期的に調べると、管理者は意図しない値を特定し、パフォーマンスの問題を特定することができます。たとえば、/proc/net/snmp ファイル内の UDP 入力エラー (InErrors) を増やすと、ソケット受信キューのボトルネックを示す可能性があります。
  • nstat ツールは、カーネルの SNMP およびネットワークインターフェースの統計を監視します。このツールは、/proc/net/snmp ファイルからデータを読み取り、情報を人間が判読できる形式で出力します。
  • デフォルトでは、systemtap-client パッケージが提供する SystemTap スクリプトは /usr/share/systemtap/examples/network ディレクトリーにインストールされます。

    • nettop.stp: 5 秒ごとに、スクリプトはプロセス一覧 (プロセス識別子とコマンド)、送受信されたパケットの数、その間にプロセスが送受信したデータ量を表示します。
    • socket-trace.stp: Linux カーネルの net/socket.c ファイル内の各関数にインストルメント化し、トレースデータを表示します。
    • dropwatch.stp: 5 秒ごとに、カーネル内の場所で解放されているソケットバッファーの数を表示します。--all-modules オプションを使用してシンボリック名を表示します。
    • latencytap.stp: このスクリプトは、1 つ以上のプロセスにおける、異なるタイプのレイテンシーの影響を記録します。レイテンシータイプの一覧を 30 秒ごとに出力し、待機しているプロセスまたはプロセスの合計時間で降順でソートします。これは、ストレージとネットワークレイテンシーの両方の原因を特定するのに役立ちます。

    Red Hat は、このスクリプトに --all-modules オプションを使用して、レイテンシーイベントのマッピングをより有効化することを推奨します。デフォルトでは、このスクリプトは /usr/share/systemtap/examples/profiling ディレクトリーにインストールされます。

  • BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。eBPF の主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。

関連情報

31.2. パケット受信でのボトルネック

ネットワークスタックは大幅に自己最適化されていますが、ネットワークパケットの処理中にはボトルネックとなり、パフォーマンスが低下する可能性のあるポイントが多数あります。

ボトルネックの原因となる可能性のある問題を以下に示します。

ネットワークカードのバッファーまたはリングバッファー
ハードウェアバッファーは、カーネルが多数のパケットをドロップするとボトルネックとなる可能性があります。ethtool ユーティリティーを使用して、削除されたパケットについてシステムを監視します。
ハードウェアまたはソフトウェアの割り込みキュー
割り込みにより、レイテンシーやプロセッサーの競合が増大する可能性があります。プロセッサーが割り込みを処理する方法は、「 割り込み要求の概要 」、手動で割り込み割り込みの「s mp_affinity マスクの設定」 を参照してください。
アプリケーションのソケット受信キュー
コピーされたものでない多数のパケット、または /proc/net/snmp ファイルの UDP 入力エラー (InErrors) で増大した多数のパケットは、アプリケーションの受信キューにおいてボトルネックを示します。

ハードウェアバッファーが多数のパケットを破棄する場合、次のようないくつかの解決策があります。

入力トラフィックの速度が遅い
受信トラフィックを絞り込み、結合したマルチキャストグループの数を減らしたり、ブロードキャストトラフィックの量を減らしてキューが埋める速度を減らします。
ハードウェアバッファーキューのサイズ

ハードウェアバッファーキューのサイズ調整: 簡単にオーバーフローしないようにキューのサイズを増やしてドロップされるパケット数を増やします。ethtool コマンドを使用して、ネットワークデバイスの rx/tx パラメーターを変更できます。

ethtool --set-ring device-name value

キューのドレイン (解放) レートの変更
  • キューに到達する前にパケットをフィルターまたは破棄したり、デバイスのウェイトを下げたりすることで、キューがいっぱいになる速度を低減します。受信トラフィックをフィルタリングしたり、ネットワークインターフェースカードのデバイスウェイトを下げると、着信トラフィックの速度を低下させます。

    デバイスのウェイトとは、1 回スケジュールされているプロセッサーアクセスでデバイスが一度に受信できるパケット数を指します。キューをドレイン (解放) する速度は、dev_weight カーネル設定で制御するデバイスのウェイトを増加できます。このパラメーターを一時的に変更するには、/proc/sys/net/core/dev_weight ファイルの内容を変更するか、または永続的に変更する場合は、procps-ng パッケージが提供する sysctl コマンドを使用します。

  • アプリケーションのソケットキューの長さを増やします。これは通常、ソケットキューのドレイン率を改善する最も簡単な方法ですが、長期のソリューションとしては適していません。ソケットキューがバーストで制限されたトラフィック量を受信した場合は、ソケットキューの深さをトラフィックのバーストサイズに一致するように増やすと、パケットがドロップされるのを防ぐことができます。キューの深さを増やすには、以下の変更のいずれかを行ってソケット受信バッファーのサイズを増やします。

    • /proc/sys/net/core/rmem_default パラメーターの値を増やします。このパラメーターは、ソケットによって使用される受信バッファーのデフォルトサイズを制御します。この値は、proc/sys/net/core/rmem_max パラメーターの値以下である必要があります。
    • setsockopt を使用して、より高い SO_RCVBUF 値を設定します。このパラメーターは、ソケットの受信バッファーの最大サイズをバイト単位で制御します。getsockopt システムコールを使用して、バッファーの現在の値を判断します。

キューのドレインレートの変更は、通常、ネットワークのパフォーマンス低下を軽減する最も簡単な方法です。ただし、デバイスが一度に受信できるパケット数を増やすと、追加のプロセッサー時間が使用され、他のプロセスがスケジュールできません。そのため、パフォーマンス上の問題が発生する可能性があります。

関連情報

  • man ページの ss (8)、socket(7)、および ethtool(8)
  • /proc/net/snmp ファイル

31.3. ビジーポーリング

分析でレイテンシーが高いと、割り込みベースのパケット受信ではなく、ポーリングベースでメリットが得られます。

ビジーポーリングは、ソケットレイヤーコードがネットワークデバイスの受信キューをポーリングできるようにして、ネットワーク受信パスのレイテンシーを短縮し、ネットワークの割り込みを無効にします。これにより、割り込みおよび結果として生じるコンテキストスイッチによって生じる遅延が削除されます。ただし、CPU 使用率も増加します。ビジーポーリングは、CPU がスリープ状態にならないようにします。これにより、追加の電力消費が発生する可能性があります。ビジーポーリングの動作は、すべてのデバイスドライバーで対応しています。

31.3.1. ビジーポーリングの有効化

デフォルトでは、ビジーポーリングは無効になっています。この手順では、ビジーポーリングを有効にする方法を説明します。

手順

  1. CONFIG_NET_RX_BUSY_POLL コンパイルオプションが有効になっていることを確認します。

    # cat /boot/config-$(uname -r) | grep CONFIG_NET_RX_BUSY_POLL
    CONFIG_NET_RX_BUSY_POLL=y
  2. ビジーポーリングの有効化

    1. 特定のソケットでビジーポーリングを有効にするには、sysctl.net.core.busy_poll カーネルの値を 0 以外の値に設定します。

      # echo "net.core.busy_poll=50" > /etc/sysctl.d/95-enable-busy-polling-for-sockets.conf
      # sysctl -p /etc/sysctl.d/95-enable-busy-polling-for-sockets.conf

      このパラメーターは、ソケットポーリング上のパケットを待機して syscalls を選択するためのミリ秒を制御します。Red Hat は、50 の値を推奨します。

    2. SO_BUSY_POLL ソケットオプションをソケットに追加します。
    3. グローバルにビジーポーリングを有効にするには、sysctl.net.core.busy_read0 以外の値に設定します。

      # echo "net.core.busy_read=50" > /etc/sysctl.d/95-enable-busy-polling-globally.conf
      # sysctl -p /etc/sysctl.d/95-enable-busy-polling-globally.conf

      net.core.busy_read パラメーターは、ソケットの読み取り用にデバイスキューのパケットを待機するマイクロ秒の数を制御します。また、SO _BUSY_POLL オプションのデフォルト値 も設定します。Red Hat ではソケット数が少ない場合は 50、ソケット数が多い場合は 100 の設定を推奨しています。非常に多くのソケット (数百) には、代わりに epoll システムコールを使用してください。

検証手順

  • ビジーポーリングが有効になっているかどうかを確認します。

    # ethtool -k device | grep "busy-poll"
    busy-poll: on [fixed]
    
    # cat /proc/sys/net/core/busy_read
    50

関連情報

31.4. receive-Side Scaling

マルチキュー受信とも呼ばれる Receive Side Scaling (RSS) は、ネットワーク受信処理を複数のハードウェアベースの受信キューに分散し、受信ネットワークトラフィックを複数の CPU で処理できるようにします。RSS を使用すると、1 つの CPU をオーバーロードして発生する受信中断プロセッシングにおけるボトルネックを緩和し、ネットワークレイテンシーを低減させることができます。デフォルトでは RSS が有効になっています。

RSS のネットワークアクティビティーを処理するキューまたは CPU の数は、適切なネットワークデバイスドライバーで設定されます。

  • bnx2x ドライバーの場合、num_queues パラメーターで設定されます。
  • sfc ドライバーの場合は、rss_cpus パラメーターで設定されます。

通常、/sys/class/net/device/queues/rx-queue/ ディレクトリーで設定されます。device はネットワークデバイスの名前 (enp1s0)、rx-queue は適切な受信キューの名前です。

irqbalance デーモンを RSS と併用して、複数ノードのメモリー転送とキャッシュラインボンピングの可能性が低減することができます。これにより、ネットワークパケット処理のレイテンシーが短縮されます。

31.4.1. 割り込み要求キューの表示

Receive-Side Scaling(RSS)を設定する場合、Red Hat は、物理 CPU コアごとにキュー数を 1 つに制限することを推奨します。ハイパースレッディングは、分析ツールで個別のコアとして表されますが、ハイパースレッディングなどの論理コアを含むすべてのコアにキューを設定することは、ネットワークパフォーマンスにあまり良い影響はありません。

有効にすると、RSS は各 CPU のがキューした処理量に基づいて、利用可能な CPU 間でネットワーク処理を均等に分散します。ただし、ethtool ユーティリティーの --show-rxfh-indir パラメーターおよび --set-rxfh-indir パラメーターを使用して、RHEL がネットワークアクティビティーをどのように分散し、特定のネットワークアクティビティーの順位付けを行う方法を変更することができます。

この手順では、割り込み要求キューを表示する方法を説明します。

手順

  • ネットワークインターフェースカードが RSS をサポートしているかどうかを確認するには、複数の割り込み要求キューが /proc/interrupts 内のインターフェースに関連付けられているかどうかを確認します。

    # egrep 'CPU|p1p1' /proc/interrupts
     CPU0    CPU1    CPU2    CPU3    CPU4    CPU5
    89:   40187       0       0       0       0       0   IR-PCI-MSI-edge   p1p1-0
    90:       0     790       0       0       0       0   IR-PCI-MSI-edge   p1p1-1
    91:       0       0     959       0       0       0   IR-PCI-MSI-edge   p1p1-2
    92:       0       0       0    3310       0       0   IR-PCI-MSI-edge   p1p1-3
    93:       0       0       0       0     622       0   IR-PCI-MSI-edge   p1p1-4
    94:       0       0       0       0       0    2475   IR-PCI-MSI-edge   p1p1-5

    この出力は、NIC ドライバーが p1p1 インターフェース (p1p1-0 から p1p1-5) の 6 つの受信キューを作成したことを示しています。また、各キューで処理された割り込みの数と、割り込みをした CPU の数も表示されます。この場合、デフォルトではこの特定の NIC ドライバーは CPU ごとに 1 つのキューを作成するため 6 つのクエリーがあります。また、このシステムには CPU が 6 つあります。これは、NIC ドライバー間で非常に一般的なパターンです。

  • 0000:01:00.0 アドレスで PCI デバイスの割り込み要求キューを一覧表示するには、以下を実行します。

    # ls -1 /sys/devices/*/*/0000:01:00.0/msi_irqs
    101
    102
    103
    104
    105
    106
    107
    108
    109

31.5. パケットスタンプの受信

RPS(Receive Packet Steering)は、パケットを処理するためにパケットを転送するために使用される Receive-Side Scaling(RSS)と似ています。ただし、RPS はソフトウェアレベルで実装されており、単一のネットワークインターフェースカードのハードウェアキューがネットワークトラフィックのボトルネックとなるのを防ぐのに役立ちます。

RPS は、ハードウェアベースの RSS と比較していくつかの利点があります。

  • RPS は、どのネットワークインターフェースカードでも使用できます。
  • 新しいプロトコルに対応するために、ソフトウェアフィルターを RPS に簡単に追加できます。
  • RPS は、ネットワークデバイスのハードウェア割り込みレートを増やしません。ただし、プロセッサー間割り込みは導入されます。

RPS は、ネットワークデバイスごとに設定され、受信キューは /sys/class/net/device/queues/rx-queue/rps_cpus ファイルで設定されます。device はネットワークデバイスの名前になります。enp1s0 や rx-queue は、rx-0 などの適切な受信キューの名前です。

rps_cpus ファイルのデフォルト値は 0 です。これにより RPS が無効になり、CPU がネットワークの割り込みを処理し、パケットも処理します。RPS を有効にするには、指定のネットワークデバイスからのパケットを処理してキューを受信する CPU で適切な rps_cpus ファイルを設定します。

rps_cpus ファイルは、コンマ区切りの CPU 表記を使用します。したがって、CPU がインターフェースの受信キューの割り込みを処理できるようにするには、プレースホルダー内のその位置の値を 1 に設定します。たとえば、CPU0、1、 2 および 3 の割り込みを処理するには、rps_cpus の値を f (16 進数の 15 )に設定します。バイナリー表示では、1500001111(1+2+4+8) です。

単一送信キューを持つネットワークデバイスには、同じメモリードメインの CPU を使用するように RPS を設定することで、最善のパフォーマンスを実現できます。NUMA 以外のシステムでは、利用可能な CPU がすべて使用できることを意味します。ネットワーク割り込みレートが非常に高い場合には、ネットワーク割り込みを処理する CPU を除くと、パフォーマンスが向上することがあります。

複数のキューを持つネットワークデバイスの場合、デフォルトで CPU を各受信キューにマッピングするように RSS が設定されているため、通常 RPS と RSS の両方を設定する利点はありません。ただし、RPS が CPU よりも少ないハードウェアキューがあり、RPS が同じメモリードメインの CPU を使用するように設定されている場合には利点があります。

31.6. Receive Flow Steering

Receive Flow Steering(RFS)は Receive Packet Steering(RPS)動作を拡張し、CPU キャッシュヒット率を増やし、ネットワークレイテンシーが短縮されます。RPS はキューの長さのみに基づいてパケットを転送し、RFS は RPS バックエンドを使用して最も適切な CPU を算出します。次にパケットを消費するアプリケーションの場所に基づいてパケットを転送します。これにより、CPU キャッシュの効率が上がります。

1 つの送信者から受信したデータは複数の CPU に送信されません。1 つの送信元から受信するデータ量が 1 つの CPU が処理できるものよりも大きい場合は、割り込みの数や CPU の処理量を減らすために、より大きなフレームサイズを設定します。NIC オフロードオプションまたは高速 CPU について検討してください。

numactl または taskset を RFS と併用して、アプリケーションを特定のコア、ソケット、または NUMA ノードに固定することを検討してください。これにより、パケットが順番に処理されるようにします。

31.6.1. Receive Flow Steering の有効化

デフォルトでは、RFS (Receive Flow Steering) は無効になっています。この手順では、RFS を有効にする方法を説明します。

手順

  1. net.core.rps_sock_flow_entries カーネル値の値を、同時にアクティブな接続の最大数に設定します。

    # echo "net.core.rps_sock_flow_entries=32768" > /etc/sysctl.d/95-enable-rps.conf
    注記

    Red Hat は、サーバーの負荷に応じて 32768 を推奨します。入力されたすべての値は、実際には 2 の最も近い累乗に丸められます。

  2. net.core.rps_sock_flow_entries の値を永続的に設定します。

    # sysctl -p /etc/sysctl.d/95-enable-rps.conf
  3. sys/class/net/device/queues/rx-queue/rps_flow_cnt ファイルの値を (rps_sock_flow_entries/N) の値に一時的に設定します。ここでの N は、デバイスの受信キューの数です。

    # echo 2048 > /sys/class/net/device/queues/rx-queue/rps_flow_cnt

    device を、設定するネットワークデバイスの名前(例: enp1s0)に、rx-queue を、設定する受信キュー(例: rx-0)に置き換えます。

    N を、設定した受信キューの数に置き換えます。たとえば、rps_flow_entries32768 に設定され、16 の設定済み受信キューがある場合、rps_flow_cnt = 32786/16= 2048 (rps_flow_cnt = rps_flow_enties/N) です。

    単一キューデバイスの場合は、rps_flow_cnt の値は、rps_sock_flow_entries の値と同じです。

  4. すべてのネットワークデバイスで RFS を永続的に有効にし、/etc/udev/rules.d/99-persistent-net.rules ファイルを作成し、次のコンテンツを追加します。

    SUBSYSTEM=="net", ACTION=="add", RUN{program}+="/bin/bash -c 'for x in /sys/$DEVPATH/queues/rx-*; do echo 2048 > $x/rps_flow_cnt;  done'"
  5. 必要に応じて、特定のネットワークデバイスで RPS を有効にするには、以下を実行します。

    SUBSYSTEM=="net", ACTION=="move", NAME="device name" RUN{program}+="/bin/bash -c 'for x in /sys/$DEVPATH/queues/rx-*; do echo 2048 > $x/rps_flow_cnt; done'"

    device name を、実際のネットワークデバイス名に置き換えます。

検証手順

  • RFS が有効かどうかを確認します。

    # cat /proc/sys/net/core/rps_sock_flow_entries
    32768
    
    # cat /sys/class/net/device/queues/rx-queue/rps_flow_cnt
    2048

関連情報

  • man ページの sysctl(8)

31.7. アクセラレート RFS

アクセラレート RFS は、ハードウェアサポートを追加することで、RFS(Receive Flow Steering)の速度を強化します。RFS と同様に、パケットはパケットを使用するアプリケーションの場所に基づいて転送されます。

ただし、従来の RFS とは異なり、パケットはスレッドに対してローカルである CPU に直接送信されます。

  • アプリケーションを実行している CPU のどちらか
  • または、キャッシュ階層のその CPU に対する CPU のローカルな CPU

RFS は、以下の条件が満たされている場合にのみ利用できます。

  • NIC はアクセラレート RFS をサポートしている必要があります。ndo_rx_flow_steer() net_device 関数をエクスポートするカードでは、 アクセラレート RFS に対応しています。NIC のデータシートをチェックして、この機能がサポートされるかどうかを確認します。
  • ntuple フィルタリングを有効にする必要があります。これらのフィルターを有効にする方法は、「 ntuple フィルターの有効化」を参照してください。

これらの条件が満たされると、従来の RFS 設定に基づいて、キューマッピングへの CPU が自動的に消費されます。つまり、キューマッピングへの CPU は各受信キューに対してドライバーによって設定された IRQ 機関に基づいて重複排除されます。従来の RFS の有効化に関する詳細は、「 Enabling Receive Flow Steering 」を参照してください。

31.7.1. ntuple フィルターの有効化

ntuple フィルタリングを有効にする必要があります。ethtool -k コマンドを使用して、ntuple フィルター を有効にします。

手順

  1. ntuple フィルターの現在の状態を表示します。

    # ethtool -k enp1s0 | grep ntuple-filters
    
    ntuple-filters: off
  2. ntuple フィルターを有効にします。

    # ethtool -k enp1s0 ntuple on
注記

出力が ntuple-filters: off [fixed] の場合、ntuple フィルタリングが無効になり、設定できません。

# ethtool -k enp1s0 | grep ntuple-filters
ntuple-filters: off [fixed]

検証手順

  • ntuple フィルターが有効になっているかどうかを確認します。

    # ethtool -k enp1s0 | grep ntuple-filters
    ntuple-filters: on

関連情報

  • ethtool(8) man ページ

第32章 メモリーアクセスを最適化するためにオペレーティングシステムの設定

本セクションでは、オペレーティングシステムを設定してワークロード全体でメモリーアクセスを最適化し、その操作に使用できるツールについて説明します。

32.1. システムメモリーの問題を監視および診断するツール

以下のツールは、システムパフォーマンスを監視し、システムメモリーに関連するパフォーマンス問題を診断するために、Red Hat Enterprise Linux 8 で利用できます。

  • procps-ng パッケージが提供するvmstat ツールは、システムのプロセス、メモリー、ページング、ブロック I/O、トラップ、ディスク、および CPU アクティビティーのレポートを表示します。これは、マシンが最後にオンされてから、または前回のレポート以降、これらのイベントの平均をインスタンス化するレポートを提供します。
  • Valgrind フレームワークは、ユーザー空間バイナリーへのインストルメンテーションを提供します。yum install valgrind コマンドを使用して、このツールをインストールします。これには、以下のようなプログラムパフォーマンスのプロファイリングおよび分析に使用できるツールが多数含まれています。

    • memcheck オプションは、デフォルトの valgrind ツールです。これは、以下のような多くのメモリーエラーを検出し、報告することが困難となる可能性のあるメモリーエラーについて検出および報告します。

      • 発生すべきでないメモリーアクセス
      • 未定義または初期化されていない値の使用
      • 誤って解放されたヒープメモリー
      • ポインターの重複
      • メモリーリーク

        注記

        memcheck は、このエラーのみを報告でき、エラーを回避することはできません。ただし、memcheck は、エラーが発生した場合すぐにエラーメッセージを記録します。

    • cachegrind オプションは、システムのキャッシュ階層および分岐予測とのアプリケーションの対話をシミュレートします。アプリケーションの実行期間についての統計を収集し、コンソールにサマリーを出力します。
    • massif オプションは、指定されたアプリケーションによって使用されるヒープ容量を測定します。便利な容量やブックキーピングと調整目的で割り当てられた容量を測定します。

関連情報

  • vmstat(8) および valgrind(1) の man ページ
  • /usr/share/doc/valgrind-version/valgrind_manual.pdf file

32.2. システムのメモリーの概要

Linux カーネルは、システムのメモリーリソース (RAM) の使用状況を最大化するために設計されています。このような設計の特徴と、ワークロードのメモリー要件によっては、システムのメモリーの一部がワークロードの変わりにカーネル内で使用されますが、メモリーのサイズは解放されています。この空きメモリーは、特別なシステム割り当てや、その他の優先度のシステムサービス用に予約されています。

システムメモリーの残りの部分はワークロード自体に専用で、以下の 2 つのカテゴリーに分類されます。

File memory

このカテゴリーに追加されたページは、永続ストレージのファイルの一部を表します。ページキャッシュのこれらのページは、アプリケーションのアドレス空間でマッピングまたはマッピング解除できます。アプリケーションを使用することで、mmap システムコールを使用してファイルをアドレス空間にマップしたり、バッファー I/O の読み取りおよび書き込み経由でファイルで操作したりできます。

バッファーされた I/O システムコール、およびページを直接マップするアプリケーションも、マッピングされていないページを再使用できます。その結果、これらのページは、同じページのセットに負荷の高い I/O 操作を再発行しないように、カーネルによりキャッシュに保存されます。これは特に、システムがメモリインテンシブなタスクを実行していないときが該当します。

Anonymous memory
このカテゴリーのページは、動的に割り当てられたプロセスで使用されているか、永続ストレージのファイルに関連しません。この一連のページは、アプリケーションスタックやヒープ領域など、各タスクのメモリー内制御構造をバックアップします。

図32.1 メモリー使用パターン

RHEL メモリー使用量パターン

32.3. 仮想メモリーパラメーター

仮想メモリーパラメーターは、/proc/sys/vm ディレクトリーに一覧表示されます。

利用可能な仮想メモリーパラメーターを以下に示します。

vm.dirty_ratio
パーセンテージの値です。システムメモリー合計の割合がこの値を超えると、システムは、pdflush 操作でディスクへの変更の書き込みを開始します。デフォルト値は 20 % です。
vm.dirty_background_ratio
パーセンテージの値。システムメモリー合計の割合がこの値を超えると、システムはバックグラウンドでディスクへの変更の書き込みを開始します。デフォルト値は 10 % です。
vm.overcommit_memory

大容量のメモリー要求を受理または拒否する条件を定義します。デフォルト値は 0 です。

デフォルトでは、カーネルは、利用可能なメモリー量と大きすぎる要求の失敗を予測することで、ヒューリスティックなメモリーのオーバーコミット処理を実行します。ただし、メモリーは正確なアルゴリズムではなくヒューリスティックで割り当てられるため、この設定ではメモリーをオーバーロードすることができます。

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

  • このパラメーターを 1 に設定するとカーネルはメモリーのオーバーコミット処理を行いません。これにより、メモリーがオーバーロードする可能性が向上しますが、メモリー集中型タスクのパフォーマンスが向上します。
  • このパラメーターを 2 に設定すると、カーネルは、利用可能なスワップ領域の合計と overcommit_ratio で指定される物理 RAM の割合またはそれ以上のメモリーの要求を拒否します。これにより、メモリーのオーバーコミットのリスクが軽減されますが、物理メモリーよりも大きいスワップ領域があるシステムのみに推奨されます。
vm.overcommit_ratio
overcommit_memory2 に設定されている場合に考慮される物理 RAM のパーセンテージを指定します。デフォルト値は 50 です。
vm.max_map_count
プロセスが使用可能なメモリーマップ領域の最大数を定義します。デフォルト値は 65530 です。アプリケーションに十分なメモリーマップ領域が必要な場合は、この値を増やします。
vm.min_free_kbytes

予約済み空きページプールのサイズを設定します。また、Linux カーネルのページ回収アルゴリズムの動作を管理する min_pagelow_pagehigh_page のしきい値も設定します。また、システム全体で空き状態になる最小キロバイト数も指定します。これにより、各ローメモリーゾーンの特定の値を計算します。それぞれには、サイズに比例して予約済み空きページが多数割り当てられます。

vm.min_free_kbytes パラメーターの値の設定:

  • パラメーターの値を増やすと、アプリケーションのワーキングセットが効果的に減少します。そのため、カーネル駆動型のワークロードのみに使用するほうがよい場合があります。この場合、ドライバーバッファーはアトミックコンテキストで割り当てる必要があります。
  • パラメーターの値を下げると、システムでメモリーが不足した場合に、カーネルがシステム要求の処理をレンダリングできなくなる可能性があります。

    警告

    極端な値は、システムのパフォーマンスに悪影響を与えます。vm.min_free_kbytes が非常に低い値に設定すると、システムのメモリーを効果的に回収できなくなります。これにより、システムがクラッシュし、サービス割り込みやその他のカーネルサービスに失敗する可能性があります。ただし、vm.min_free_kbytes を設定すると、システムの回収アクティビティーが大幅に増大し、誤ったダイレクト回収状態により割り当てレイテンシーが発生します。これにより、システムがメモリー不足の状態に即座に入ります。

    vm.min_free_kbytes パラメーターは、min_pages というページ回収ウォーターマークも設定します。このウォーターマークは、ページの回収アルゴリズムを管理する他の 2 つのメモリー基準 (low_pages、および high_pages) を決定する要素として使用されます。

/proc/PID/oom_adj

システムがメモリー不足になり、panic_on_oom パラメーターを 0 に設定すると、oom _killer 関数はプロセスを強制終了し、システムが回復するまで 、最も高い oom_ killer を持つプロセスを開始します。

oom_adj パラメーターは、プロセスの oom_score を決定します。このパラメーターはプロセス ID ごとに設定されます。-17 の値は、その プロセスの oom_killer を無効にします。その他の有効な値は、-16 から 15 までです。

注記

調整したプロセスによって作成されたプロセスは、そのプロセスの oom_score を継承します。

vm.swappiness

swappiness 値(0 から 100 まで )は、システムが匿名メモリープールまたはページキャッシュメモリープールからメモリーの回収を優先するレベルを制御します。

swappiness パラメーターの値の設定:

  • 値を高くすると、ファイルマップ駆動型のワークロードが優先され、RAM のアクティブにアクセスされるプロセスの匿名マッピングメモリーをスワップアウトします。これは、ストレージのファイルのデータに依存するファイルサーバーやストリーミングアプリケーションが、サービスリクエストの I/O レイテンシーを低減させるためにメモリーに駐在するのに便利です。
  • 値が小さいほど、ページキャッシュ (ファイルマップされたメモリー) を回収しつつ、匿名のマッピング駆動型ワークロードが優先されます。この設定は、ファイルシステム情報に大きく依存しないアプリケーションや、数学的アプリケーションや数値計算アプリケーション、QEMU などの一部のハードウェア仮想化スーパーバイザーなど、動的に割り当てられたメモリーとプライベートメモリーに大きく利用されるアプリケーションに有用です。

    vm.swappiness パラメーターのデフォルト値は 30 です。

    警告

    vm.swappiness0 に設定すると、匿名メモリーをディスクにスワップアウトする必要がなくなります。これにより、メモリーまたは I/O 集約型のワークロード下で oom_killer 関数によるプロセスの強制終了のリスクが高まります。

関連情報

32.4. ファイルシステムパラメーター

ファイルシステムパラメーターは、/proc/sys/fs ディレクトリーに一覧表示されます。利用可能なファイルシステムパラメーターを以下に示します。

aio-max-nr
すべてのアクティブな非同期入出力コンテキストで許可されるイベントの最大数を定義します。デフォルト値は 65536 で、この値を変更してもカーネルデータ構造の事前割り当てやサイズ変更は行われません。
file-max

システム全体でのファイルハンドルの最大数を決定します。Red Hat Enterprise Linux 8 のデフォルト値は、8192 またはカーネルの起動時に利用可能な空きメモリーページの 10 分のいずれかになります。

この値を設定すると、利用可能なファイルハンドルがないためにエラーを解決できます。

関連情報

  • man ページの sysctl(8)

32.5. カーネルパラメーター

カーネルパラメーターのデフォルト値は /proc/sys/kernel/ ディレクトリーにあります。この値は、利用可能なシステムリソースに応じて、システムの起動時にカーネルにより計算されます。

以下は、msg* および shm* System V IPC (sysvipc) システムコールの制限を設定するのに使用されるカーネルパラメーターです。

msgmax
メッセージキューの単一のメッセージに対する最大許容サイズ (バイト単位) を定義します。この値は、キューのサイズ (msgmnb) を超えることはできません。sysctl msgmax コマンドを使用して、システムの現在の msgmax 値を確認します。
msgmnb
単一のメッセージキューの最大サイズをバイト単位で定義します。sysctl msgmnb コマンドを使用して、システムの現在の msgmnb 値を確認します。
msgmni
メッセージキュー識別子の最大数 (つまりキューの最大数) を定義します。sysctl msgmni コマンドを使用して、システムの現在の msgmni 値を確認します。
shmall
一度にシステムで使用できる共有メモリーページの合計量を定義します。たとえば、AMD64 および Intel 64 のアーキテクチャーでは、ページは 4096 バイトです。sysctl shmall コマンドを使用して、システムの現在の shmall 値を確認します。
shmmax
カーネルが許可する単一の共有メモリーセグメントの最大サイズをバイト単位で定義します。sysctl shmmax コマンドを使用して、システムの現在の shmmax 値を確認します。
shmmni
システム全体の共有メモリーセグメントの最大数を定義します。いずれのシステムでもデフォルト値は 4096 です。

関連情報

  • man ページの sysvipc(7) および sysctl(8)

第33章 Huge Page の設定

物理メモリーは、ページと呼ばれる固定サイズのブロックで管理されます。Red Hat Enterprise Linux 8 でサポートされる x86_64 アーキテクチャーでは、メモリーページのデフォルトサイズは 4 KB です。このデフォルトのページサイズは、さまざまなワークロードをサポートする Red Hat Enterprise Linux などの一般的なオペレーティングシステムに適しています。

ただし、特定のアプリケーションは、特定のケースで大きなページサイズを使用する利点を得られます。たとえば、4 KB ページの使用時に、数百メガバイト、数十ギガバイトの大容量かつ比較的固定のデータセットで動作するアプリケーションは、パフォーマンスの問題となる可能性があります。このようなデータセットでは、4 KB のページ のサイズが大きい可能性があります。これにより、オペレーティングシステムと CPU でオーバーヘッドが発生することがあります。

本セクションでは、Red Hat Enterprise Linux 8 で利用可能なヒュージページとその設定方法を説明します。

33.1. 利用可能な Huge Page の機能

Red Hat Enterprise Linux 8 では、大規模なデータセットに対応するアプリケーションに Huge Page を使用し、このようなアプリケーションのパフォーマンスを向上できます。

以下は、Red Hat Enterprise Linux 8 でサポートされる Huge Page メソッドです。

HugeTLB pages

HugeTLB ページも静的なヒュージページと呼ばれます。HugeTLB ページを予約する方法は 2 つあります。

Transparent HugePages (THP)

THP では、カーネルはヒュージページをプロセスに自動的に割り当てるため、静的な Huge Page を手動で予約する必要はありません。以下は、THP における動作の 2 つのモードです。

  • system-wide で、カーネルはヒュージページを割り当て、プロセスが連続している仮想メモリー領域を使用しているたびに Huge Page をプロセスに割り当てようと試みます。
  • プロセスごと: ここでは、カーネルは各プロセスのメモリー領域だけに割り当てるため、madvise() システムコールを使用して指定できるヒュージページを 1 つのみに割り当てます。

    注記

    THP 機能は 2 MB ページのみをサポートします。

    THP の有効化および無効化に関する詳細は、起動時に HugeTLB ページの動作に影響を与えるパラメーターの詳細は、「透過的な Huge Page の有効化」および「透過的な Huge Page の無効化」を参照してください。

33.2. 起動時に HugeTLB ページを確保するためのパラメーター

起動時に HugeTLB ページの動作に影響を与えるには、以下のパラメーターを使用します。

表33.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 です。

33.3. 起動時の HugeTLB の設定

HugeTLB サブシステムがサポートするページサイズは、アーキテクチャーによって異なります。x86_64 アーキテクチャーは 、2 MB のヒュージページと 1 GB の重み付けページをサポートします。

この手順では、システムの起動時に 1 GB のページを 予約する方法を説明します。

手順

  1. root として /etc/default/grub ファイルのカーネルコマンドラインオプションに次の行を追加して 、1 GB の HugeTLB プールを作成します。

    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 ページ、node 1 に 1 GB ページを確保するには、node 0 の場合は number_of_pages を、2、node 1 の場合は 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

33.4. ランタイム時に HugeTLB ページを確保するためのパラメーター

起動時に HugeTLB ページの動作に影響を与えるには、以下のパラメーターを使用します。

表33.2 ランタイム時に HugeTLB ページを設定するために使用されるパラメーター

パラメーター説明ファイル名

nr_hugepages

指定された NUMA ノードに割り当てられる指定したサイズのヒュージページの数を定義します。

/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

33.5. ランタイム時の HugeTLB の設定

この手順では 、2048 kB の Huge Page を node2 に追加する方法を説明します。

要件に基づいてページを確保するには、以下を置き換えます。

  • 20 (予約するヒュージページ数)
  • 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 ページ

33.6. 透過的な HugePage の有効化

Red Hat Enterprise Linux 8 では、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

関連情報

33.7. 透過的な Huge Page の無効化

Red Hat Enterprise Linux 8 では、THP がデフォルトで有効になっています。ただし、THP を有効または無効にすることができます。

この手順では、THP を無効にする方法を説明します。

手順

  1. THP の現在の状態を確認します。

    # cat /sys/kernel/mm/transparent_hugepage/enabled
  2. THP を無効にします。

    # echo never > /sys/kernel/mm/transparent_hugepage/enabled

33.8. 翻訳されたバッファーサイズのページサイズの影響

ページテーブルからアドレスマッピングを読み取るのは、非常に時間がかかり、リソースの負荷が高くなります。そのため、CPU は、トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) と呼ばれる、最近使用されたアドレスのキャッシュで構築されます。ただし、デフォルトの TLB は、特定のアドレスマッピングのみをキャッシュできます。

要求されたアドレスマッピングが TLB ミスと呼ばれる TLB にない場合、システムはページテーブルを読み込んで、物理から仮想アドレスへのマッピングを判断する必要があります。アプリケーションメモリー要件と、アドレスマッピングのキャッシュに使用されるページサイズ間の関係により、メモリー要件が高いアプリケーションは、最小限であるアプリケーションと比べて、TLB ミスによるパフォーマンスの低下の影響が高くなる可能性があります。したがって、可能であれば TLB ミスを回避するためには重要です。

HugeTLB および Huge Page の機能の両方を使用すると、アプリケーションは 4 KB を超えるページを使用できます。これにより、TLB に保存されているアドレスはより多くのメモリーを参照できます。これにより、TLB ミスが軽減され、アプリケーションのパフォーマンスが向上します。

第34章 SystemTap の使用

システム管理者は、SystemTap を使用して、実行中の Linux システムでバグやパフォーマンスの問題の基本的な原因を特定できます。

アプリケーション開発者は、SystemTap を使用して、Linux システムでアプリケーションがどのように動作するかを詳細に監視できます。

34.1. SystemTap の目的

SystemTap は、オペレーティングシステム (特にカーネル) の動作を詳細に観察および監視できる追跡およびプロービングのツールです。SystemTap では、netstatpstopiostat などのツールのアウトプットと同様の情報を利用できます。ただし、SystemTap では、収集した情報に対するフィルター処理と分析のオプションが強化されています。SystemTap スクリプトでは、SystemTap が収集する情報を指定します。

SystemTap は、カーネルのアクティビティーを追跡するインフラストラクチャーをユーザーに提供し、この機能を 2 つの属性で組み合わせることで、既存の Linux 監視ツールスイートを補完します。

柔軟性
SystemTap のフレームワークを使用すると、幅広いカーネル機能、システムコール、およびカーネルスペースで発生する他のイベントについて、調査および監視目的のシンプルなスクリプトを開発できます。つまり、SystemTap はツールというよりも、独自のカーネル固有のフォレンジックおよび監視ツールの開発を可能にするシステムといえます。
使いやすさ
SystemTap を使用すると、カーネルを再コンパイルしたり、システムを再起動したりせずに、カーネルのアクティビティーを監視できます。

34.2. SystemTap のインストール

SystemTap の使用を開始するには、必要なパッケージをインストールします。システムに複数のカーネルがインストールされていて、それらのカーネル上で SystemTap を使用するには、each カーネルバージョン用に一致する必要なカーなネルパッケージをインストールします。

前提条件

手順

  1. 必要な SystemTap パッケージをインストールします。

    # yum install systemtap
  2. 必要なカーネルパッケージをインストールします。

    1. stap-prep の使用:

      # stap-prep
    2. stap-prep が機能しない場合は、必要なカーネルパッケージを手動でインストールします。

      # yum 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 が有効なハンドラーを実行しました (テキストを出力した後、エラーなしで閉じました)。

34.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 ユーザーのみでなければならなりません。

34.4. SystemTap スクリプトの実行

SystemTap スクリプトは、標準入力またはファイルから実行できます。

SystemTap のインストールと合わせて配布されるサンプルスクリプトは、/usr/share/systemtap/examples ディレクトリーにあります。

前提条件

  1. Installing Systemtap」で説明されているように、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

第35章 SystemTap のクロスインストルメンテーション

SystemTap のクロスインストルメンテーションは、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを作成し、SystemTap が完全にデプロイされていない別のシステムで使用します。

35.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 スクリプトから) インストルメンテーションモジュールが構築されます。
ターゲットカーネル
ターゲットシステム のカーネル。これは、インストルメンテーションモジュール を読み込み、実行するカーネルです。

35.2. SystemTap のクロスインストルメンテーションの初期化

SystemTap のクロスインストルメンテーションを初期化し、あるシステムで SystemTap スクリプトから SystemTap インストルメンテーションモジュールを構築して SystemTap が完全にデプロイされていない別のシステムで使用します。

前提条件

  • SystemTap のインストール」で説明されているように、SystemTap が ホストシステム にインストールされている。
  • ターゲットシステムsystemtap-runtime パッケージがインストールされている。

    # yum install systemtap-runtime
  • ホストシステムターゲットシステム の両方のアーキテクチャーが同じである。
  • ホストシステムターゲットシステム は、どちらも同じメジャーバージョンの Red Hat Enterprise Linux (Red Hat Enterprise Linux 8 など) を実行しており、異なるマイナーバージョン (8.1 や 8.2 など) を実行できます
注意

カーネルのパッケージ化のバグにより、複数の 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

第36章 「BPF コンパイラーコレクションでシステムパフォーマンスの分析」

システム管理者として BPF コンパイラーコレクション (BCC) ライブラリーで Linux オペレーティングシステムのパフォーマンスを分析するツールを作成します。ただし、他のインターフェース経由での取得は困難な場合があります。

36.1. BCC の概要

BPF コンパイラーコレクション (BCC) は、eBPF (extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。この主なユーティリティーは、オーバーヘッドやセキュリティー上の問題が発生することなく、OS のパフォーマンスおよびネットワークパフォーマンスを分析するものです。

BCC により、ユーザーは eBPF の技術詳細を把握する必要がなくなり、事前に作成した eBPF プログラムを含む bcc-tools パッケージなど、多くの標準スタートポイントを利用できます。

注記

eBPF プログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。プログラムがカーネルのセーフ仮想マシンで実行するため、カーネルがクラッシュしたり、ループしたり、応答しなくなることはあまりありません。

36.2. bcc-tools パッケージのインストール

このセクションでは、BCC (BPF コンパイラーコレクション) ライブラリーを含む bcc-tools パッケージをインストールする方法を説明します。

前提条件

手順

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

    # yum 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 ディレクトリーには、各ツールのドキュメントが含まれます。

36.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/
    sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
    ...

    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 出力には、以下のフィールドが表示されます。