はじめに
パフォーマンス障害が発生した際のパフォーマンスチューニングの目的と流れについて、先日記事にしてみましたが、今回から、具体的な調査方法について記載してみたいと思います。
この記事では、OSのパフォーマンス調査についてまとめてみます。
前提条件
サーバーOSは、Windows、Redhat系Linuxを想定しています。
パフォーマンス調査を行う対象のシステムは、Webサーバー(Apache)、APサーバー(Tomcat)、DBサーバー(Oracle)で構成される、シンプルなWebシステムを想定しています。
Windowsサーバーでのパフォーマンス調査
イベントログ
Windowsのイベントログは、パフォーマンス調査というより、システムに繋がらないなど、障害調査で確認する事が多いものですが、「システム」および「アプリケーション」のイベントログにエラーなどがないか、障害発生時にサービスの再起動などのイベントが発生していないか確認します。
「セキュリティ」イベントログは、セキュリティ関連の調査などで確認する事が多いですが、まれに、サーバー高負荷時に、RDP接続した事により、不安定な状態になる事もあるため、一応確認しておいてもよいかもしれません。
※少し前の話ですが、あるシステムで、APサーバーからFileサーバーへのアクセスがDos攻撃と判断され、ファイルへのアクセスが遮断されていた事がイベントログから判明した事がありました。
なお、イベントログはバイナリ、テキスト、XMLまたはCSV形式で出力する事ができますが、Winodwsサーバーのバージョン毎にバイナリの形式が異なり、解析する人のPCで確認ができない場合があるので、イベントログは、CSV形式などのテキスト形式で出力するようにします。
パフォーマンスモニター
Windowsには、標準でパフォーマンスモニター(perfmon)というツールが搭載されており、CPU、メモリ使用率、ディスク、ネットワークアクセスといった、OS全体やプロセス単位でのパフォーマンス情報を確認、収集する事が可能です。
パフォーマンス調査を行う際、OS全体の状況を確認する事で、どのような処理やミドルウェアに問題がありそうか、OS設定等に問題がないか、ざっくり切り分けする事ができます。
Windowsのパフォーマンスログは、一定時間毎に特定のフォルダ以下に出力する事が可能です。GUIで確認する事もできますが、パフォーマンス問題発生時の状況が確認できない場合がある為、確認したいカウンタの値を数秒から数十秒毎などの間隔で定期的に出力しておく事をお勧めします。
なお、パフォーマンスログは、拡張子が.blgであるバイナリ形式で出力し、必要に応じてrelogコマンドを使用して、バイナリ形式からCSV形式に変換し解析するようにします。
パフォーマンスログをCSV形式で出力する事も可能ですが、ログ収集を開始した後に起動したプロセスのパフォーマンス情報が取得できない仕様になっているので、バイナリ形式での出力が推奨されています。
パフォーマンスログの収集方法については、以下を参照ください。
※パフォーマンスログの出力による負荷は、それほど大きくはありませんが、出力間隔や出力するカウンタ数により、1日で数百KB～数MB程度のディスク容量が必要になるため、ディスクの空き状況や負荷状況を確認の上、出力設定するようにしてください(定期的に削除したり圧縮する事も可能です)。
※ディスクの空き容量が十分あるようであれば、プロセス毎のカウンタも含め、全てのカウンタを出力するでもよいと思います。
パフォーマンスモニターで確認したいカウンタ
以下に、パフォーマンス調査時に確認したいカウンタを記載します。
| カテゴリ | カウンタ | 判断基準(目安) | カウンタの意味と傾向 |
|---|---|---|---|
| CPUリソース | \Processor(_Total)% Processor Time | 95%以上 | CPU使用率を表し、常に閾値を超える場合はCPUボトルネックが疑われる。あわせて%Total User Time(ユーザモードで実行されたCPU使用率)を取得。この値が常に高い場合は、アプリケーション処理のためにCPUが使用されたことを意味している。この状態でパフォーマンスに問題がある場合には、CPUボトルネックと考えられるため、CPUのアップグレードや負荷分散を検討する必要がある。※ただし、CPU使用率が高くても、Processor Queue Lengthの値が低い場合は、OS的にはパフォーマンス上の問題がない場合もある。 |
| ランキュー | System\Processor Queue Length | CPUコアあたり2未満 | CPU待ち行列にあるスレッド数を表す(実行中のものは含まない)。マルチコア/マルチプロセッサシステムの場合は、閾値も比例する。この値が閾値を超える場合は、該当サーバーが同時アクセス過多やCPUを占有する遅い処理によりCPUボトルネックとなっていると考えられ、このサーバーのミドルウェア、アプリケーションの調査が必要と考えられる。 |
| メモリリソース | \Memory\Available Mbytes | メモリの空きが10%以下 | プロセスが利用可能な物理メモリの容量(メモリ空き容量)。閾値を下回る場合はRAMの増設を検討する必要がある。減少傾向がみられる場合はメモリリークの可能性あり。但し、メモリが多い環境の場合、空きが10%以下でも、数GBの空きがあれば、問題ない場合が多い。 |
| ページング(メモリとディスクとの読み書き)の状況 | \Memory\Pages /sec | 20以内 | 秒間あたりでメモリ上に無いデータがディスクから読み書きされた回数。このカウンタにはページング回数だけでなく、アプリケーションやミドルウェアを起動するなどして、新しくファイルを開いたりした回数なども含まれる。アプリケーション起動後も継続してこのカウンタの値が大きい(閾値を超える)場合、ページングが多く発生している可能性があり、物理メモリの容量が足りていない可能性がある。※ページングが多発している場合、OSレベルのパフォーマンス悪化となる為、早急な対処が必要。 |
| プロセス毎のメモリリソース | \Process(_Total)\Working Set | 参考値として取得 | アプリケーションが使用するメモリサイズのうち物理メモリ上で確保されているメモリ領域。この値が大幅に増減する場合は、メモリ不足の可能性あり。 |
| ディスクリソース(物理ディスク) | \PhysicalDisk(*)\Avg.Disk Queue Length | ディスクごとに2未満 | サンプリング間隔中に、選択したディスクのキューで待機している読取りおよび書込みリクエストの平均数。アクセス可能な物理ディスク数ごとに継続的に2を超えない状態が望ましい。参考値として、Current Disk Queue Lengthの値も確認。この値が閾値を超える場合は、該当サーバーのディスクI/Oがボトルネックになっていると考えられ、このサーバーのミドルウェア、アプリケーションの調査が必要と考えられる。 |
この他、プロセス毎の「%Processor Time」や「Page Faults/sec」を確認する事で、どのミドルウェアやプロセスがサーバーリソースをどの程度使っているか確認ができます。
少し古い記事ですが、パフォーマンスモニターの確認観点として、以下が参考になると思います。
システムの特性にもよりますが、Webアプリケーションでは、一般的にWeb/ApplicationサーバーはCPUボトルネック(「Processor Queue Length」の値が大きくなる)に、Databaseサーバーは、データをキャッシュするメモリ不足による、ディスクI/O待ちが(「Avg.Disk Queue Length」の値が大きくなる)ボトルネックになる傾向があります。
調査の際には、各サーバーのCPU使用率、メモリの空き容量をざっと確認し、ページングの頻度が問題無い事を確認したら、「Processor Queue Length」、「Avg.Disk Queue Length」 の値について確認し、CPUボトルネックなのか、I/Oがボトルネックなのか切り分けしてみるとよいと思います。
なお、ページングの頻度が多い場合は、物理メモリが足りていないため、OS設定、ミドルウェアなどへのメモリ割り当ての見直しが早急に必要になる場合があります(場合により、OSのメモリリークの不具合の可能性もあります)。
タスクマネージャ、リソースモニター
パフォーマンスモニターのパフォーマンスログが出力されていない場合は、パフォーマンス悪化時のタスクマネージャやリソースモニターの画面キャプチャを確認します。
「Processor Queue Length」や「Avg.Disk Queue Length」といった情報は確認できないため、全体およびプロセス毎のCPU使用率、ページファイルの使用量、全体およびプロセス毎のハードフォルト回数(リソースモニター)、全体およびプロセス毎のメモリ使用量、全体の利用可能メモリ(スタンバイ領域も利用可能である事に注意)、ディスクのキューの長さ(リソースモニター)といった内容を確認します。
Sysinternals Suite
Microsoft社が提供しているトラブルシューティングツールがいくつかあり、これらをまとめてWindows Sysinternalsと呼びます。Sysinternals Suiteは、Windows Sysinternalsが提供しているツールのうち、便利なものをまとめたものです。
※ツールの内訳は、以下で確認可能です。
この中で、以下は、OS関連問題のトラブルシューティングに有用なツールだと思いますので、紹介だけしておきます。
Process Explore(procexp64.exe)
各プロセス(スレッド)に関する詳細情報の確認、プロセスが開いたファイル、DLL等の確認やプロセスの終了等が可能。
RAMMAP(RAMMap.exe)
物理メモリの利用状況の詳細を確認できるツール。OSのメモリ関連の問題(メモリリーク等)調査が可能。
TCP View(Tcpview.exe)
netstatの情報+ネットワークを利用しているプロセス情報等が確認可能。
Linuxサーバーでのパフォーマンス調査
syslog
Windowsのイベントログと同様、syslogは、パフォーマンス調査というより、システムに繋がらないなど、障害調査で確認する事が多いものですが、エラーなどがないか、障害発生時にサービスの再起動などのイベントが発生していないか確認します。
ログの確認対象や確認方法については、以下などが参考になると思います。
sar
sarは、Windowsにおけるパフォーマンスモニター(ログ)＋αに相当するもので、CPU、メモリ、ディスクI/O、ネットワーク通信状況など様々な情報が記録されています。
各種リソース情報は、デフォルトでは10分間隔で取得され、/var/log/sar以下に過去1ヶ月分程度の期間分のファイルが日毎に出力されます(取得間隔や保管期間の変更も可能です)。
/var/log/sar以下には、バイナリ形式のsaXX(XXの部分は日付)ファイルと、テキスト形式のsarXX(XXの部分は日付)ファイルが保管されています。
saXXファイルは、sarコマンドで確認するためのもので、サーバーにログインして直接コマンドで状況を確認する際に利用するものです。
しかし、sarのバージョンにより、バイナリ形式のsaXXファイルは互換性が無く、例えばRHEL8で取得したsaXXファイルをUbuntuなどのsarコマンドで確認しようとしても、確認できない場合があるので、基本的には、テキスト形式のsarXXファイルを収集し、内容を確認するようにします。
sarファイルで確認したいポイント
Windowsのパフォーマンスログの確認ポイントと概ね一緒です。
| カテゴリ | 確認する項目 | 判断基準(目安) | 値の意味と傾向 |
|---|---|---|---|
| CPU使用率 | %user、%systemの値 | 合わせて95%以上 | CPU使用率を表し(%userは、ミドルウェアやアプリケーション、%systemはカーネル)、常に閾値を超える場合はCPUボトルネックが疑われる。ただし、CPU使用率が高くても、ランキュー、ロードアベレージの値が低い場合は、OS的にはパフォーマンス上の問題がない場合もある。 |
| ランキュー、ロードアベレージ | runq-sz、ldavg-1、ldavg-5、ldavg-15 | CPUコアあたり2未満 | 閾値を超える場合は、該当サーバーが同時アクセス過多やCPUを占有する遅い処理によりCPUボトルネックとなっていると考えられ、このサーバーのミドルウェア、アプリケーションの調査が必要と考えられる。 |
| 空きメモリ | kbmemfree、kbbuffers、kbcachedの値の合計 | メモリの空きが10%以下 | 最近のOSでは、buffers、cachedの領域もメモリ再利用が可能な場合が多く、freeの値だけでは空きを判断できない。閾値を下回る場合はRAMの増設を検討する必要がある。減少傾向がみられる場合はメモリリークの可能性あり。但し、メモリが多い環境の場合、空きが10%以下でも、数GBの空きがあれば、問題ない場合が多い。 |
| スワップ | pswpin/s、pswpout/s、kbswpusedの値など | 0より大きい値 | 基本的には0を目指す。定常的にスワップが発生している場合、物理メモリの容量が足りていないと考えられる。※スワップが多発している場合、OSレベルのパフォーマンス悪化となる為早急な対処が必要。 |
| ディスクI/O待ち | avgqu-sz、awaitの値 | avgqu-szの値：デバイス毎に2未満 | avgqu-szは、平均待ち行列長を表す。await(レスポンスタイム)が大きくなっている場合、I/O待ちが発生していると考えられ、このサーバーのミドルウェア、アプリケーションの調査が必要と考えられる。 |
sarコマンドの使い方や、各項目の意味、設定変更方法などは、以下が参考になると思います。
top
topコマンドでは、サーバーのリソース状況、プロセス毎のリソース使用状況の概要を確認できます。
パフォーマンス障害が発生した際、サーバーにログインできる場合は、まずtopコマンドで状況を確認しつつ、sarやvmstatの結果を確認したりします(確認ポイントは、sarと同様です)。
各項目の意味やtopコマンドのオプションなどについては、以下が参考になると思います。
vmstat
vmstatコマンドでは、仮想メモリやCPU、ディスクI/Oなどの統計情報を確認できます。
topコマンドと同様に、サーバーにログインし状況を確認したい場合に利用します。
sar、top、vmstatとで、同じ意味でも項目の表示名が違っていたりしますが、CPU使用率(us+sy)、メモリの空き状況(free+buff+cache)、スワップの有無(si、so)、ランキュー待ち(r値)、I/O待ち(b値)の状況を確認するという事自体は、sarと同様です。
各項目の意味やvmstatコマンドのオプションなどについては、以下が参考になると思います。
アンチウィルスソフトの設定
OSのパフォーマンス調査で、意外と原因になりやすいものとして、アンチウィルスソフトの設定があります。
少なくとも、以下のような検討はしておくことをお勧めします。
- システムで利用するミドルウェア(本記事の前提では、apache、tomcat、oracle)が利用するディレクトリ以下や、NFSやSMBでマウントされている外部ストレージ領域をウィルススキャンの除外対象にする
- アプリケーションが利用するファイルデータについても、可能な限りスキャンの除外対象とする(全文検索のIndexファイルやアプリケーションログ、キャッシュファイルなど)
- Webサーバーなど、アプリケーションが利用するポートに対するポートスキャン設定(大きなファイルをアップロードすると、CPUが100%で張り付いたまま固まったり、必要な通信が遮断される場合がある)
おわりに
今回は、OSのパフォーマンス調査についてまとめてみました。
次回以降、apache、tomcat、oracleといったミドルウェアのパフォーマンス調査方法についてもまとめていきたいと思います。
参考書籍
10年以上前に出版された本ですが、インフラエンジニア必読の本の1つだと思います。本記事でも参考にしています。
2019年に、新装版も出ています。