PCP を使用したストレージパフォーマンスの解析
ここでは、PCP (Performance Co-Pilot) を使用したストレージパフォーマンス解析の基本的なタスクの概要とチュートリアルを紹介します。
はじめに
PCP は、システムレベルのパフォーマンスを監視および管理するスイートです。特にエンタープライズ環境で使用するのに適しています。PCP は、RHEL 6.6 以降、もしくはその他のディストリビューション (Fedora (F15 以降)、Debian、Ubuntu など) に同梱され完全にサポートされます。このオープンソースプロジェクトは、コミュニティで活発にメンテナンスおよび開発が行われており、安定しています。詳細は、PCP ホームページ、GITHUB のプロジェクトページ、および git repo を参照してください。
- メトリクスの範囲: PCP は、Linux の /proc や /sys などの疑似ファイルシステムがエクスポートしたもの (各プロセスのデータなど) をすべて取得します。 PCP は簡単に拡張でき、約 70 個のプラグイン (Linux プラットフォーム、Oracle、(Java/JVM 向け) mmv、libvirt、Docker コンテナーなど) が利用できます。すべてのリリースに新しいエージェントが追加されます。
- 名前空間およびメタデータ: PCP には統一された階層メトリクスの名前空間があります。これには、データ型 (整数/文字列/ブロック/イベント)、セマンティクス (カウンター/インスタント/その他)、スケーリング単位 (時間/数/空間次元)、ヘルプテキストなど、すべてのメトリクスにメタデータが含まれます。一般的な監視ツールがこのメタデータを使用して適切なスケーリング、メタデータのフォーマット作成、速度変換を行います。これにより、多くの場合、カスタムの監視アプリケーションが必要なくなります。詳細は、pmrep(1)、pmchart(1) などを参照してください。PCP には、sysstat、top などのレガシーツールと同じように操作できるフロントエンドツールが含まれます。詳細は、How does Performance Co-Pilot (PCP) compare with sysstat および Side-by-side comparison of PCP tools with legacy tools を参照してください。
- 分散オペレーションおよびアーカイブ取得: PCP には、保護された IPC チャンネルにライブデータをエクスポートして、オフサイト解析またはレトロスペクティブ解析に使用できるアーカイブを取得するログサービスがあります。 PCP は、基本的に、パフォーマンスデータ (ライブまたはアーカイブでの取得) を、リプレイ (ライブローカル、ライブリモート、またはアーカイブリプレイ) から完全に分離させます。すべての PCP 監視ツールは、ライブ監視とアーカイブリプライの両方を行うことができ、共通のコマンドラインオプションを共有します。詳細は PCPINTRO(1) を参照してください。これにより、ライブデータ (ローカルまたはリモートのホスト) をクエリーし、期間やサンプリング間隔に関わらず、統計的低下に関する過去のデータを詳しく検討します。また、PCP アーカイブは sosreport に自動的に追加されます。
- API: PCP は、RHEL 6.6 以降と、RHEL 7 のすべてのバージョンに含まれます。ドキュメントが整備され、安定したプラグインと、新しいエージェントを開発するデータ取り込みライブラリー、そして新しい監視ツール用ライブラリーが提供されます。すべての API には、C、C++、Python、および Perl バインディングがあります。Go バインディングも利用できます (github における PCP 速度の検索)。さらには、JSON サポートと、Grafana、Vector、およびネイティブな web アプリケーションのサポートが含まれた、開発スタイルの javascript アプリケーションに使用される webapi が含まれます。
- ツール: PCP には、レガシーの sysstat ツール (iostat、pidstat、vmstat、mpstat、uptime、free、atop、numastat など) と互換性のあるコンソールツールが多数含まれる多種多様なツールや、データを詳しく調査してスクリプトを作成する多数の汎用ツールがあります。また、高度な相互作用解析およびレポート生成を行う GUI ツールがあります。
- セキュリティ: PCP は、ローカルホスト限定 (inet ドメインソケットをもたない unix ドメイン) または完全リモートに設定できます。リモートアクセスでは、PCP サービスエーモンとライブラリーが、SSL 暗号化を使用する IPC チャンネルが追加された証明書ベースの認証をサポートします。ファイアウォールを通るアクセスには、専用のプロキシーデーモンも利用できます。
- ドキュメントテーション PCP には、ドキュメンテーションが広範囲に提供されています。本が 2 冊出版されており、さらにはホワイトペーパー、ハウツー、ナレッジベースのソリューションとアーティクルなど、多数用意されています。下部の「参考資料」を参照してください。
- サポート: PCP は、RHEL で完全にサポートされています。サポートケースを作成すれば Red Hat サポートをご利用になれます。コミュニティに直接ご連絡いただくことも可能です。
ストレージ解析のチュートリアル
(4 コア/4 ディスク/8G RAM が搭載された) 小規模サーバーで PCP をインストールし、ログサービスを有効にして設定します。また、疑似ワークロードを設定して、数日間にわたってパフォーマンスログを取得します。その後、ストレージパフォーマンス解析タスクのデモを行います。この時、アーカイブログのリプレイモードでさまざまな PCP 監視ツールを使用します。
パフォーマンス統計を取得するようにサーバーを設定せずに PCP 監視ツールを使用する方法を学習する場合は、このチュートリアルで使用する PCP アーカイブをダウンロードして利用できます。
# wget http://people.redhat.com/~mgoodwin/pcp/archives/goody.tgz
# tar xf goody.tgz
アーカイブの tarball を解凍したら、後述の PCP 監視環境および解析環境の設定に進みます。
サーバー環境の設定
このタスクに関する一般的なナレッジベースソリューションに従って PCP をインストールして設定します。この方法は、RHEL 5 から RHEL 7 の RHEL サーバー、Fedora、Debian に適用されます。PCP は RHEL6.6 以降に同梱されています。以前のバージョンでは、EPEL パッケージ (および bintray.com パッケージ) が利用できます。
標準の pmcd サービスおよび pmlogger サービスを有効にして、デフォルトのログ取得間隔を調整します。30 秒から 5 秒に減らしてください。
プロセスごとのメトリクスのログを有効にし、間隔を 30 秒に設定します。その後、pcp-atop(1) などの PCP 監視ツールでリプレイします。これは、I/O パフォーマンス解析に必須な手順ではありませんが、アクティブになっているプロセス、I/O を行っているプロセス、そしてその他のシステムリソースを使用しているプロセスを確認するのに有効な場合があります。
この設定では、1 日で約 0.5 GB のログを取得し、標準の PCP ログディレクトリ /var/log/pcp 配下にある PCP アーカイブのログに保存します。sos(1) の新しいバージョンでは、このディレクトリが存在する場合は、標準の sosreport に含まれます。古いバージョンの sos(1) を使用している場合は、gzip を使用して手動で作成した tar ファイルをケースにアップロードすることができます。
疑似ワークロードの設定
crontab エントリーから疑似ワークロードをデプロイします。ここでは、バックアップを毎日 8pm に約 2 時間実行することをシミュレートしています。この疑似ワークロードは、ストレージで読み込み負荷が毎日高くなる状態をシミュレートしており、監視ツールで確認できます。実際のデータを使用することはできないため、ここでは疑似ワークロードを使用します。一般的な症状として、「毎晩 I/O 待機が増えてサーバーのパフォーマンスが低下してしまい、それが原因で別のタイムゾーンでアプリケーションのパフォーマンスが低下する」ことが考えられます。
#
# cat /etc/cron.d/fakebackups
# Fake workload - every day at 8pm, pretend to run backups of /home
0 20 * * * root dd if=/dev/mapper/vg-home bs=1M of=/dev/null >/dev/null 2>&1
PCP 監視環境および解析環境の設定
ワークステーションに、(最低でも) pcp-system-tools パッケージをインストールします。man ページ (pcp-doc パッケージ) もインストールします。このパッケージはサーバーにインストールする必要はありません。監視ツールは、解析に使用するシステムにのみ必要です。PCP は移植可能で、完全に分離しているリプレイデータ取得と前方および後方互換性があるため、パフォーマンスのログを問題のサーバーで取得して、その後 PCP 監視ツールがインストールされているシステムで解析します。これは、ライブ監視と、以前取得したログのレトロスペクティブ解析に適用されます。pcp-monitor は、メタ RPM パッケージです。これには、pcp-system-tools などの PCP クライアントツールを含むさまざまな RPM パッケージへの依存関係があります。
# yum -y install pcp-system-tools pcp-doc
しばらく待って PCP アーカイブを調べる
PCP pmlogger サービスを数時間もしくは数日間実行したあと、作成されたログをケースにアップロードするか、ワークステーションにコピーします。
tar コマンドに z オプションを追加して、PCP アーカイブを圧縮します。 ファイルを解凍すると、疑似カスタマーサーバーのログがサブディレクトリに出力されます。ログを取得した各ホストに対してログがそれぞれ 1 つずつ作成されます。ホストが 1 台しかない場合は、そのホストのログだけが出力されます。ここでは、ホストの名前は goody で、ログは /var/log/pcp/pmlogger/goody に出力されます。ログを 2 日間取得すると、ディレクトリには以下のファイルが含まれます。
# ls -hl /var/log/pcp/pmlogger/goody
total 1.4G
-rw-r--r-- 1 pcp pcp 472M Jul 19 12:48 20160718.12.38.0
-rw-r--r-- 1 pcp pcp 86K Jul 19 12:48 20160718.12.38.index
-rw-r--r-- 1 pcp pcp 3.2M Jul 19 12:47 20160718.12.38.meta
-rw-r--r-- 1 pcp pcp 474M Jul 20 13:04 20160719.12.55.0
-rw-r--r-- 1 pcp pcp 86K Jul 20 13:05 20160719.12.55.index
-rw-r--r-- 1 pcp pcp 9.2M Jul 20 13:01 20160719.12.55.meta
-rw-r--r-- 1 pcp pcp 418M Jul 21 10:18 20160720.13.25.0
-rw-r--r-- 1 pcp pcp 74K Jul 21 10:18 20160720.13.25.index
-rw-r--r-- 1 pcp pcp 4.2M Jul 21 10:15 20160720.13.25.meta
-rw-r--r-- 1 pcp pcp 216 Jul 20 13:25 Latest
-rw-r--r-- 1 pcp pcp 11K Jul 20 13:25 pmlogger.log
-rw-r--r-- 1 pcp pcp 11K Jul 20 13:05 pmlogger.log.prior
cron スクリプト pmlogger_daily(1) によって、PCP ログが毎日ロールオーバーされます。各アーカイブの名前には、アーカイブを作成した日時が YYMMDD.HH.MM フォーマットで追加され、さらには最低 3 つのファイル (一時インデックス (.index)、メタデータ (.meta)、1 つ以上のデータボリューム (.0、.1 など)) が含まれます。上の一覧では、6 月 18 日、19 日、20 日に日次ログを取得したことが確認できます。PCP アーカイブ名が監視ツールへの引数として追加される場合は、アーカイブ名だけが提供されます。
以下のように pmdumplog -L コマンドを実行すると、時間の境界を判断するアーカイブラベルを調べることができます。
# cd /var/log/pcp/pmlogger/goody
# pmdumplog -L 20160718.12.38
Log Label (Log Format Version 2)
Performance metrics from host goody
commencing Mon Jul 18 12:38:49.106 2016
ending Tue Jul 19 12:48:44.134 2016
Archive timezone: AEST-10
PID for pmlogger: 12976
pmlogger/goody ディレクトリには、その他にも以下のファイルがあります。
- pmlogger.log:
pmloggerサービスのログです。ログに出力されたメトリクスの情報、そしてログ間隔の情報を提供します。ログを取得する頻度は、メトリクスのグループごとに設定することができます。疑似カスタマーサイトでは、大概のデータログを 5 秒で、そしてプロセスごとのデータログを 30 秒間隔で取得します。また、pmlogger.logファイルは、毎日ログに取得したデータのおおよそのボリュームの数値を提供します。これは、ログの間隔を設定し、/var ファイルシステムの容量を計画するのに役に立ちます。
タイムゾーンと -z フラグ (重要)
上述の一覧を作成する pmdumplog -L では、サーバーのタイムゾーンがログのラベルヘッダーに一覧表示されます。監視ツールを使用して PCP アーカイブをリプレイすると、デフォルトのレポート作成タイムゾーンは、監視ツールを実行するホストのローカルタイムゾーンになります。これは、多くの PCP 監視ツールで、複数アーカイブのリプレイを可能にするためです。このアーカイブは、タイムゾーンが異なる地域で取得された可能性もあります。実際にカスタマーサイトからアーカイブをリプレイしたときは通常、タイムゾーンに最も注目しますが、使用しているタイムゾーンと異なる場合も少なくありません。(ローカルのタイムゾーンと異なるときに) ローカルのタイムゾーンではなくサーバーのタイムゾーンを使用する場合は、使用している監視ツールで -z フラグを使用します。この方法が、カスタマーに報告する際にもっとも適切で、syslog などのログに報告されたタイムゾーンが適切に相関されます。また、-Z ゾーンフラグを使用すれば、使用する報告タイムゾーンをゾーンとして指定できます (-Z EDT、-Z PST、-Z UTC など)。
pmlogextract を使用して複数のアーカイブを 1 つに結合する
監視ツールで特定の期間を調べる前に、複数日または複数週のパフォーマンスデータサマリーを確認したい場合は、pmlogextract ツールを使用して簡単にアーカイブできます。複数のアーカイブを 1 つにまとめ、監視ツールに -a フラグを渡して使用できます。
たとえば、以下のようになります。
# pwd
/var/log/pcp/pmlogger/goody
# pmlogextract *.0 ../myarchive
# pmdumplog -L ../myarchive
Log Label (Log Format Version 2)
Performance metrics from host goody
commencing Mon Jul 18 12:38:49.106 2016
ending Thu Jul 21 08:13:12.404 2016
Archive timezone: AEST-10
PID for pmlogger: 22379
ここで確認できるように、myarchive の長さは数日間に及びます。これを利用して数日間のデータを確認してから、特定の期間を調べることができるため、この機能は非常に便利です。また、pmlogextract ツールは、必要に応じて特定のメトリクスだけを抽出することもできます。詳細は man ページを参照してください。また、新しいバージョンの PCP (pcp-3.11.2 以降) では、-a フラグを複数回指定することができます。ツールは、オンザフライでアーカイブを透過的に結合することができます。
複数日に渡るパフォーマンス概要に pmchart を使用する
myarchive を使用すれば、PCP 監視ツールでパフォーマンスサマリーを取得できます。たとえば、3 日間の CPU 使用量を調べ、I/O の待ち時間 (I/O を保留しているアイドル時間) が存在するかどうかを確認します。
# pmchart -z -a myarchive -t 10m -O-0 -s 400 -v 400 -geometry 800x450 -c CPU -c Loadavg
ここでは、サンプリング間隔を 10 分 (-t 10m) にし、間隔を 400 (-s 400 -v 400) にし、期間を (10 x 400 / 60) で 66 時間または 3 日間に設定しています。サーバーのタイムゾーン (-z)、アーカイブ末尾へのオフセット (- O-0 (-O はネガティブのゼロとなり、アーカイブが終わる前のゼロ秒を示します)) を使用します 。さらには、ウィンドウサイズ 800x450 と、ロード前の pmchart ビューを 2 つ (-c CPU -c Loadavg) 使用します。
ロードアベレージは毎晩 8pm に急増し、I/O 待ち時間も増えていることが分かります (上部の CPU チャートの青色の部分)。この例では、イメージをケースにアップロードして、毎晩 8pm に実行しているアプリケーションを調べます。
テキストベースの出力に pmrep を使用する
# pmrep -z -a myarchive -t 10m -p -S'@19:45' -s 20 kernel.all.load kernel.all.cpu.{user,sys,wait.total} disk.all.total_bytes
k.a.load k.a.load k.a.load k.a.c.user k.a.c.sys k.a.c.w.total d.a.total_bytes
1 minute 5 minute 15 minut
util util util Kbyte/s
19:45:00 0.010 0.020 0.050 N/A N/A N/A N/A
19:55:00 0.010 0.020 0.050 0.012 0.004 0.009 12.507
20:05:00 1.100 0.690 0.330 0.016 0.055 0.292 44104.872
20:15:00 1.010 0.990 0.670 0.012 0.088 0.754 79864.410
20:25:00 1.050 1.060 0.860 0.012 0.074 0.908 66039.610
20:35:00 1.060 1.070 0.960 0.015 0.074 0.913 63837.190
20:45:00 1.310 1.160 1.020 0.012 0.070 0.792 62741.337
20:55:00 1.000 1.030 1.030 0.012 0.070 0.792 61975.538
21:05:00 1.000 1.060 1.060 0.016 0.071 0.882 60047.950
21:15:00 1.000 1.020 1.050 0.013 0.065 0.907 56705.562
21:25:00 1.000 1.020 1.050 0.012 0.060 0.907 52059.462
21:35:00 1.030 1.040 1.050 0.016 0.057 0.921 46970.013
21:45:00 1.020 1.110 1.090 0.012 0.047 0.960 41684.985
21:55:00 0.130 0.680 0.920 0.013 0.035 0.769 29428.372
22:05:00 0.000 0.130 0.510 0.016 0.007 0.013 25.687
22:15:00 0.000 0.020 0.270 0.012 0.004 0.010 13.060
22:25:00 0.000 0.010 0.150 0.014 0.006 0.012 44.713
22:35:00 0.000 0.010 0.080 0.017 0.008 0.010 17.532
22:45:00 0.030 0.030 0.050 0.012 0.004 0.010 13.690
22:55:00 0.000 0.010 0.050 0.012 0.005 0.009 14.037
ここでは、アップデート間隔を 10 分 (-t 10m)、サンプルを 20 (-s 20)、開始時間を 19:45pm (-S@19:45) にして pmrep を実行し、タイムスタンプ (-p) を表示しました。そして、ロードアベレージ (kernel.all.load)、ユーザー、システム、待機 CPU 測定 (kernel.all.cpu.{user,sys,wait.total}、およびディスクスループットの合計 (disk.all.total_bytes) を調べました。 ここでは、pmchart グラフにおける最初の I/O 急増が 6 月 18 日の 8pm ごろに発生し、約 2 時間続いていることを示しています。
ストレージパフォーマンス解析に pmiostat を使用する
pmiostat ツールは、PCP アーカイブログをリプレイする CLI ツールです。pmiostat レポートは、sysstat(1) の namesake と非常によく似ていますが、多くの点でより効果的です。
以下は、上述で pmrep を使用した場合と同じ設定で実行した例です。同じアーカイブで pmiostat を使用していますが、6 月 19 日に発生した 2 回目の I/O 急増を選択し、sda ディスクのレポートを取得しています (regex パターンには -R sda$ を使用)。
# pmiostat -z -a myarchive -x t -t 10m -S'@Jul 19 19:55:00' -s 10 -P0 -R 'sda$'
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 20:05:00 2016 sda 0 0 0 2 0 5 2.7 0.0 7 8 7 1
Tue Jul 19 20:15:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 10 4 1
Tue Jul 19 20:25:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 20:35:00 2016 sda 1 0 419 2 53299 4 126.8 1.6 4 4 26 81
Tue Jul 19 20:45:00 2016 sda 0 0 32 1 4108 3 121.5 0.1 4 4 6 8
Tue Jul 19 20:55:00 2016 sda 0 0 0 2 0 4 2.4 0.0 6 14 6 1
Tue Jul 19 21:05:00 2016 sda 0 0 0 2 0 5 2.5 0.0 5 11 5 1
Tue Jul 19 21:15:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 21:25:00 2016 sda 0 0 0 2 0 4 2.4 0.0 6 15 6 1
Tue Jul 19 21:35:00 2016 sda 0 0 0 1 0 3 2.2 0.0 5 0 5 1
どの device-mapper ボリュームを所有しているか確認します。
# pminfo -a myarchive -f disk.dm.read
disk.dm.read
inst [0 or "vg-swap"] value 638067
inst [1 or "vg-root"] value 1699398
inst [3 or "vg-libvirt"] value 283719
inst [5 or "vg-home"] value 10175251
inst [7 or "docker-253:1-4720837-pool"] value 2441254
inst [273 or "docker-253:1-4720837-bd20b3551af42d2a0a6a3ed96cccea0fd59938b70e57a967937d642354e04859"] value 1218
inst [274 or "docker-253:1-4720837-b4aca4676507814fcbd56f81f3b68175e0d675d67bbbe371d16d1e5b7d95594e"] value 1491
docker ボリューム以外の論理ボリュームの統計を確認します。
# pmiostat -z -a myarchive -x t -x dm -t 10m -S'@Jul 19 19:55:00' -s 5 -P0 -R'vg-*'
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 20:05:00 2016 vg-home 0 0 347 0 44025 0 126.8 1.0 3 3 0 50
Tue Jul 19 20:05:00 2016 vg-libvirt 0 0 0 2 0 5 2.6 0.0 7 8 7 1
Tue Jul 19 20:05:00 2016 vg-root 0 0 0 2 5 12 9.7 0.1 70 33 74 2
Tue Jul 19 20:05:00 2016 vg-swap 0 0 0 0 0 0 4.1 0.0 25 25 0 0
Tue Jul 19 20:15:00 2016 vg-home 0 0 631 0 79965 0 126.7 1.9 3 3 0 100
Tue Jul 19 20:15:00 2016 vg-libvirt 0 0 0 1 0 3 2.0 0.0 4 10 4 1
Tue Jul 19 20:15:00 2016 vg-root 0 0 0 1 4 10 10.6 0.1 66 41 73 3
Tue Jul 19 20:15:00 2016 vg-swap 0 0 0 0 0 0 4.0 0.0 68 68 0 0
Tue Jul 19 20:25:00 2016 vg-home 0 0 522 0 65960 0 126.4 2.0 4 4 0 100
Tue Jul 19 20:25:00 2016 vg-libvirt 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 20:25:00 2016 vg-root 0 0 1 1 28 12 14.7 0.2 56 30 77 5
Tue Jul 19 20:25:00 2016 vg-swap 0 0 0 0 0 0 4.0 0.0 59 59 0 0
Tue Jul 19 20:35:00 2016 vg-home 0 0 501 0 63784 0 127.3 2.0 4 4 0 100
Tue Jul 19 20:35:00 2016 vg-libvirt 0 0 0 2 0 4 2.5 0.0 28 37 28 3
Tue Jul 19 20:35:00 2016 vg-root 0 0 1 2 12 12 11.3 0.1 55 34 62 2
Tue Jul 19 20:35:00 2016 vg-swap 0 0 0 0 0 0 4.0 0.0 33 33 0 0
Tue Jul 19 20:45:00 2016 vg-home 0 0 485 0 61965 0 127.8 2.0 4 4 0 100
Tue Jul 19 20:45:00 2016 vg-libvirt 0 0 0 1 0 3 2.2 0.0 7 12 7 1
Tue Jul 19 20:45:00 2016 vg-root 0 0 0 1 4 10 11.6 0.0 15 17 15 1
Tue Jul 19 20:45:00 2016 vg-swap 0 0 0 0 0 0 4.0 0.0 13 13 0 0
vg-home LVM 論理ボリュームにはトラフィックがすべてあるようです。
# pmiostat -z -a myarchive -x t -x dm -t 10m -S'@Jul 19 19:45:00' -s 15 -P0 -R'vg-home'
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 19:55:00 2016 vg-home 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:05:00 2016 vg-home 0 0 347 0 44025 0 126.8 1.0 3 3 0 50
Tue Jul 19 20:15:00 2016 vg-home 0 0 631 0 79965 0 126.7 1.9 3 3 0 100
Tue Jul 19 20:25:00 2016 vg-home 0 0 522 0 65960 0 126.4 2.0 4 4 0 100
Tue Jul 19 20:35:00 2016 vg-home 0 0 501 0 63784 0 127.3 2.0 4 4 0 100
Tue Jul 19 20:45:00 2016 vg-home 0 0 485 0 61965 0 127.8 2.0 4 4 0 100
Tue Jul 19 20:55:00 2016 vg-home 0 0 479 0 61362 0 128.0 1.9 4 4 0 100
Tue Jul 19 21:05:00 2016 vg-home 0 0 467 0 59751 0 128.0 2.0 4 4 0 100
Tue Jul 19 21:15:00 2016 vg-home 0 0 440 0 56380 0 128.0 2.0 4 4 0 100
Tue Jul 19 21:25:00 2016 vg-home 0 0 405 0 51875 0 128.0 2.0 5 5 0 100
Tue Jul 19 21:35:00 2016 vg-home 0 0 367 0 46996 0 128.0 2.0 5 5 0 100
Tue Jul 19 21:45:00 2016 vg-home 0 0 326 0 41727 0 128.0 2.0 6 6 0 100
Tue Jul 19 21:55:00 2016 vg-home 0 0 242 0 31030 0 128.0 1.7 7 7 0 85
Tue Jul 19 22:05:00 2016 vg-home 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 22:15:00 2016 vg-home 0 0 0 0 0 0 0.0 0.0 0 0 0 0
sosreport を確認すると、vg ボリュームグループは、以下の physvols を使用します。
#
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda1 vg lvm2 a-- 232.88g 0
/dev/sdb2 vg lvm2 a-- 230.88g 0
/dev/sdc vg lvm2 a-- 232.88g 0
したがって、pmiostat を使用してこのデバイスを確認します。
# pmiostat -z -a myarchive -x t -t 10m -S'@Jul 19 19:45:00' -s 10 -P0 -R'sd[abc]'
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 19:55:00 2016 sda 0 0 0 1 0 3 2.0 0.0 5 0 5 1
Tue Jul 19 19:55:00 2016 sdb 0 0 0 1 1 10 10.8 0.0 8 12 7 1
Tue Jul 19 19:55:00 2016 sdc 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:05:00 2016 sda 0 0 0 2 0 5 2.7 0.0 7 8 7 1
Tue Jul 19 20:05:00 2016 sdb 0 0 347 1 44030 12 126.4 1.1 3 3 78 50
Tue Jul 19 20:05:00 2016 sdc 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:15:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 10 4 1
Tue Jul 19 20:15:00 2016 sdb 1 0 630 1 79970 10 126.7 2.0 3 3 66 100
Tue Jul 19 20:15:00 2016 sdc 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:25:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 20:25:00 2016 sdb 1 0 522 1 65988 12 126.2 2.1 4 4 77 100
Tue Jul 19 20:25:00 2016 sdc 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:35:00 2016 sda 1 0 419 2 53299 4 126.8 1.6 4 4 26 81
Tue Jul 19 20:35:00 2016 sdb 0 0 82 1 10496 12 125.5 0.5 6 5 69 19
Tue Jul 19 20:35:00 2016 sdc 0 0 0 0 0 0 0.0 0.0 0 0 0 0
Tue Jul 19 20:45:00 2016 sda 0 0 32 1 4108 3 121.5 0.1 4 4 6 8
Tue Jul 19 20:45:00 2016 sdb 0 0 0 1 4 10 12.8 0.0 17 16 17 1
Tue Jul 19 20:45:00 2016 sdc 0 0 452 0 57858 0 127.9 1.8 4 4 0 93
Tue Jul 19 20:55:00 2016 sda 0 0 0 2 0 4 2.4 0.0 6 14 6 1
Tue Jul 19 20:55:00 2016 sdb 0 0 0 1 3 10 12.1 0.0 24 21 24 1
Tue Jul 19 20:55:00 2016 sdc 0 0 479 0 61362 0 128.0 1.9 4 4 0 100
Tue Jul 19 21:05:00 2016 sda 0 0 0 2 0 5 2.5 0.0 5 11 5 1
Tue Jul 19 21:05:00 2016 sdb 0 0 0 1 7 12 10.5 0.1 34 20 38 1
Tue Jul 19 21:05:00 2016 sdc 0 0 467 0 59751 0 128.0 2.0 4 4 0 100
Tue Jul 19 21:15:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 21:15:00 2016 sdb 0 0 0 1 2 10 12.0 0.0 19 15 19 1
Tue Jul 19 21:15:00 2016 sdc 0 0 440 0 56380 0 128.0 2.0 4 4 0 100
Tue Jul 19 21:25:00 2016 sda 0 0 0 2 0 4 2.4 0.0 6 15 6 1
Tue Jul 19 21:25:00 2016 sdb 0 0 4 1 150 11 32.4 0.0 9 3 31 1
Tue Jul 19 21:25:00 2016 sdc 0 0 405 0 51875 0 128.0 2.0 5 5 0 100
vg ボリュームグループの physvols は線形で、sdb、sda、sdc の順にビジーになります。これは、疑似ワークロードが、vg-home 論理ボリュームを絶えず読み込むためです。これは、pmchart を使用するとより明確になります。
pmchart の IOSTAT ビュー:
残りの iostat 列を表示する別のタブ:
pmiostat: デバイス選択とアグリゲーションオペレーター
pmiostat (バージョン 3.11.2 以降) では、コマンドラインオプション -R regex および -G sum|avg|min|max が新機能として追加されました。regex は、利用可能なデバイスのサブセットを選択します (sd デバイス、または -x dm フラグが指定された場合は device-mapper 論理デバイスのいずれか)。 選択したデバイスだけが以下を報告します。
# pmiostat -z -a myarchive -x t -t 10m -S'@Jul 19 19:45:00' -s 4 -P0 -R'sd[ab]$'
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 19:55:00 2016 sda 0 0 0 1 0 3 2.0 0.0 5 0 5 1
Tue Jul 19 19:55:00 2016 sdb 0 0 0 1 1 10 10.8 0.0 8 12 7 1
Tue Jul 19 20:05:00 2016 sda 0 0 0 2 0 5 2.7 0.0 7 8 7 1
Tue Jul 19 20:05:00 2016 sdb 0 0 347 1 44030 12 126.4 1.1 3 3 78 50
Tue Jul 19 20:15:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 10 4 1
Tue Jul 19 20:15:00 2016 sdb 1 0 630 1 79970 10 126.7 2.0 3 3 66 100
Tue Jul 19 20:25:00 2016 sda 0 0 0 1 0 3 2.0 0.0 4 0 4 1
Tue Jul 19 20:25:00 2016 sdb 1 0 522 1 65988 12 126.2 2.1 4 4 77 100
regex の最後の $ に注意してください。それ以外では、sdaa、sdab などが一致します。
-G フラグは、-R フラグを使用して提供された regex に一致するデバイス、もしくは -R が提供されていない場合はデフォルトですべてのデバイスで、統計のアグリゲーションが利用できます。たとえば、以下のように hinv.map.scsi メトリクスをクエリーすることで、HBTL scsi-id を確認できます。
# pminfo -a myarchive -f hinv.map.scsi
hinv.map.scsi
inst [0 or "scsi0:0:0:0 Direct-Access"] value "sda"
inst [1 or "scsi1:0:0:0 Direct-Access"] value "sdb"
inst [2 or "scsi2:0:0:0 Direct-Access"] value "sdc"
inst [3 or "scsi3:0:0:0 Direct-Access"] value "sdd"
たとえば、sda と sdb の統計 (たとえば、同じターゲットへの代替パス、もしくは同じ PCI バスに代替パスである可能性があるため、そのトラフィックの総計) を計算したい場合があるとします。
# pmiostat -z -a myarchive -x t -t 10m -S'@Jul 19 19:45:00' -s 4 -P0 -R'sd[ab]$' -Gsum
# Timestamp Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
Tue Jul 19 19:55:00 2016 sum(sd[ab]$) 0 1 0 2 1 13 12.8 0.0 12 12 12 1
Tue Jul 19 20:05:00 2016 sum(sd[ab]$) 0 1 347 3 44030 17 129.1 1.1 10 11 85 51
Tue Jul 19 20:15:00 2016 sum(sd[ab]$) 1 0 630 2 79970 13 128.7 2.0 7 13 70 101
Tue Jul 19 20:25:00 2016 sum(sd[ab]$) 1 1 522 3 65988 15 128.2 2.1 8 4 80 101
デバイス名の列は、提供される regex パターンとして報告されます。-Gsum フラグを使用していても、%util 列が常に平均化します。
非補間モード
デフォルトでは、すべての PCP 監視ツールで補間メカニズムを使用して、基本的なネイティブサンプリング間隔とは異なるレポート間隔を指定することができます。利用方法については、PCPIntro(1) を参照してください。補間を使用したくない場合があります。たとえば、blocktrace(1) データと pmiostat データを相互に関連付ける場合は、タイムスタンプを完全に一致させる必要があります。補間を無効にするには、pmrep または pmiostat で -u フラグを使用します。
-u フラグは -t フラグと互換性がありません。補間を使用しないとサンプリング間隔を変更することができません。常に、データが本来記録される基本的なサンプリング間隔と同じになります。
各プロセスの I/O を報告するツール
pcp-atop(1) コマンドで、各プロセスの I/O 統計と、システムレベルの豊富なその他のパフォーマンスデータを調べるのに使用できます。すべての PCP ツールのように、pmlogconf 設定が適切に有効になっている場合に限り、pcp-atop はアーカイブをリプレイします (上述を参照)。各プロセスの I/O 解析については、pcp -a ARCHIVE atop -d フラグを使用します。特に proc データが存在する場合は、大きなアーカイブで atop を実行すると非常に時間がかかるため、サンプリング間隔はおそらく非常に長い期間を指定する必要があります。多数のオプションがあります。プロセスの I/O には、-d フラグが一番便利です。
# pcp atop --help
Usage: pcp-atop [-flags] [interval [samples]]
or
Usage: pcp-atop -w file [-S] [-a] [interval [samples]]
pcp-atop -r file [-b hh:mm] [-e hh:mm] [-flags]
generic flags:
-a show or log all processes (i.s.o. active processes only)
-R calculate proportional set size (PSS) per process
-P generate parseable output for specified label(s)
-L alternate line length (default 80) in case of non-screen output
-f show fixed number of lines with system statistics
-F suppress sorting of system resources
-G suppress exited processes in output
-l show limited number of lines for certain resources
-y show individual threads
-1 show average-per-second i.s.o. total values
-x no colors in case of high occupation
-g show general process-info (default)
-m show memory-related process-info
-d show disk-related process-info
-n show network-related process-info
-s show scheduling-related process-info
-v show various process-info (ppid, user/group, date/time)
-c show command line per process
-o show own defined process-info
-u show cumulated process-info per user
-p show cumulated process-info per program (i.e. same name)
-C sort processes in order of cpu-consumption (default)
-M sort processes in order of memory-consumption
-D sort processes in order of disk-activity
-N sort processes in order of network-activity
-A sort processes in order of most active resource (auto mode)
specific flags for raw logfiles:
-w write raw data to PCP archive folio
-r read raw data from PCP archive folio
-S finish pcp-atop automatically before midnight (i.s.o.#samples)
-b begin showing data from specified time
-e finish showing data after specified time
interval: number of seconds (minimum 0)
samples: number of intervals (minimum 1)
ブロックされたプロセスを検出
I/O パフォーマンス解析においては、ブロックされたタスク (つまり D 状態のプロセスや、割り込み不可 (UN) なスリープ) を呼び出すのが一般的なタスクです。これは、pmchart で、proc.runq.runnable プロセスと proc.runq.blocked プロセスの数を表示することで簡単に確認できます。
# pmchart -z -a myarchive -t 10m -O-0 -s 400 -v 400 -geometry 800x450 -c CPU
特定のプロセスを監視するのに pmrep ツールや pcp-pidstat ツールなどを使用することもできます。pcp-pidstat ツールは、ブロックされたプロセスを検出および監視する機能を追加するように現在開発されています。
参考資料
ナレッジベース
- Index of Performance Co-Pilot (PCP) articles, solutions, tutorials and white papers
- PCP Data Sheet
- How do I install Performance Co-Pilot (PCP) on my RHEL server to capture performance logs
- What are all the Performance Co-Pilot (PCP) RPM packages in RHEL?
- How to use Performance Co-Pilot
- How do I gather performance data logs to upload to my support case using Performance Co-Pilot (PCP)
- How can I merge multiple PCP archives into one for a system level performance analysis covering multiple days or weeks
- How can I use Performance Co-Pilot (PCP) to capture a "once-off" performance data archive log for a specific interval of time
- How is Performance Co-Pilot (PCP) designed and structured?
- What are the typical Performance Co-Pilot (PCP) deployment strategies?
- How can I customize the Performance Co-Pilot logging configuration
- How can I change the default logging interval used by Performance Co-Pilot (PCP)?
- Are Red Hat planning to include PCP (Performance Co-Pilot) in RHEL?
- How do I configure a firewall on a RHEL server to allow remote monitoring with Performance Co-Pilot (PCP)?
- How does Performance Co-Pilot (PCP) compare with sysstat
- Side-by-side comparison of PCP tools with legacy tools
- How to use a non-default PMDA with PCP?
- pmiostat fails to replay a PCP archive log created on a RHEL6 system
- Overview of Additional Performance Tuning Utilities in Red Hat Enterprise Linux 7
- Interactive web interface for Performance Co-Pilot
- How can I run PCP services in a Docker container?
- How can I convert a collectl archive into a Performance Co-Pilot (PCP) archive?
Comments