前回の投稿ではハードウェアコンポーネント別にパフォーマンスの計測・確認の方法を紹介しました。今回は、標準的なパフォーマンスカウンタ以外に利用可能なカウンタの紹介や、前回紹介したカウンタの具体的な活用方法を紹介したいと思います。
■ ■ ■
Active Directoryドメインサービスのパフォーマンス確認
データコレクタセット(データコレクタセットについては下記コラム参照)には、管理者が手動で作成する「ユーザー定義」と呼ばれるものと、あらかじめシステム側で定義されている「システム」がある。「システム」のデータコレクタセットには、目的別に見るべきカウンタの一覧が並んでおり、言ってみればパフォーマンス計測を行うときのノウハウが詰まっている。そのため、これを使わない手はないだろう。
ここでは、システムデータコレクタセットからActive Directoryドメインサービスのパフォーマンスを確認する「Active Directory Diagnostics」というデータコレクタセットを使ってみよう。システムデータコレクタセットのプロパティを開くと、下の画面のように最初からいくつかのカウンタが入っていることが確認できる。そのため、ドメインコントローラーのサーバー上で、このデータコレクタセットをそのまま開始すれば、Active Directoryドメインサービスのパフォーマンスの計測が開始できる。
ちなみに、データコレクタセットに含まれる、代表的なActive Directoryドメインサービスのカウンタを紹介しておく。
・DirectoryServicesDS Client Binds/Sec
ドメインコントローラに接続(バインド)したクライアントの数を表す(1秒あたり)。この数を見ることで、ドメインコントローラを利用するクライアントの数を見ることができ、ドメインコントローラに求められるパフォーマンスを確認することができる。ベースラインと比較をすれば、サービス開始当初に比べてどの程度のクライアントがドメインコントローラを利用するようになったかという増加を見ることができ、サーバー増強の必要性なども間接的に確認できるようになる。
1秒あたりのドメインコントローラに対する読み取りアクセス数を確認するときはDirectoryServicesDS Directory Reads/Secカウンタが利用できる。
・DirectoryServicesDRA Inbound Bytes/Sec
ドメインコントローラが他のドメインコントローラからレプリケーションによって受信したデータのバイト数です(1秒あたり)。Active Directoryドメインサービスでは、定期的に他のドメインコントローラとの間でレプリケーションが行われる。このときに1秒間にどのくらいのデータを受信したかを見ることで、レプリケーションが正しく行われているか、レプリケーションのパフォーマンス、そしてレプリケーションの傾向を知ることができる。
サイト内とサイト間でわけてレプリケーションデータのバイト数を確認した場合、サイト内はDirectoryServicesDRA Inbound Bytes Not Compressed (Within Site) /Secカウンタ、サイト間はDirectoryServicesDRA Inbound Bytes Compressed (Between Sites, After Compression)/Secカウンタでそれぞれ計測できる。
・Process%Processor Time – インスタンス:Lsass
Lsassはドメインコントローラの基礎となるプロセスで、このプロセスによってプロセッサの使用率が高くなっている場合には、ドメインコントローラが過負荷な状態にあると判断できる。原因は色々あるが、主なところでは、自身がブリッジヘッドサーバーであることによるサイト間レプリケーションの処理、PDCエミュレータとしての処理が過負荷の原因として挙げられる。そのため、ブリッジヘッドサーバーの役割やPDCエミュレータの役割などを他のドメインコントローラへ移動させて、Lsassプロセスに変化があるかチェックするとよいだろう。
ファイルコピーのパフォーマンス確認
次は実際に計測した情報から、パフォーマンスを確認する方法を紹介したい。
ここでは、ファイルコピーのスピードが遅くなるケースを取り上げる。
ファイルコピーを行っているときに、一定のスピードでファイルコピーが行われていたのに、 突然ファイルコピーのスピードが遅くなってしまうケースがある。
(100MB/s程度で推移していたファイルコピーが16.1MB/sまで低下している)
上の画面だけを見れば、利用できるネットワークの帯域が少なくなったと考えるかもしれない。 しかし、パフォーマンスモニタを使えば、もっと違うことが見えてくる。
では、実際にパフォーマンス計測を行う。
ここでは、4つのハードウェアから1つのカウンタを採用し、計測することとしよう。
・Processor%Processor Time
・MemoryPages/Sec
・Physical Disk%Disk Time
・Network InterfaceBytes Total/Sec
計測を開始してから、ファイルコピーを開始する。
すると、次のようなグラフが現れた。
まずは、Network InterfaceBytes Total/Secから(グラフ太字参照)。
12:49:45からグラフの最後(12:51:11)までファイルをコピーしている。
ファイルコピーのスピードが遅くなった12:50:25あたりから、グラフが下がっていることが確認できる。
続いて、ディスクのPhysical Disk%Disk Timeについて。
ファイルコピーを開始した12:49:45の直後から、激しくディスクアクセスが発生していることが確認できる。
しかも、ネットワークのスピードが遅くなった12:50:25以降も同じようなアクセスを繰り返している。
本来であれば、ネットワークが遅くなり、受け取るデータ量が少なくなれば、ディスクへの書き込みは待ち状態になる(ディスクアクセスが減る)のに、そうなっていないところを見ると、少なくともネットワーク遅延がボトルネックになっているわけではないのだろうか？という予測ができる。
続いてメモリ(MemoryPages/Sec)を見てみよう。
ファイルコピーのスピードが低下した12:50:15あたりから、ページングが激しく起きていることが確認できる。ページングは物理メモリから仮想メモリへ(もしくは仮想メモリから物理メモリへ)のデータ移動の回数を表しているため、ファイルコピーに必要な物理メモリが足りなくなって、仮想メモリを使うことになった。
そして、仮想メモリにアクセスしなければならない時点で、パフォーマンスは落ちるので、全体として、ファイルコピーのスピードが遅くなってしまったのではないか？
という予測がたてられるのである。
ちなみに、Processor%ProcessorTimeカウンタはご覧のとおり、ファイルコピーに何の影響も及ぼしていないことが確認できる。
ここまでのところでファイルコピーをケースにパフォーマンス計測とその分析方法を見ていただいた。
ファイルコピーのスピードが遅くなった場合、表面的な部分だけを見て
「ネットワークが遅い」などと判断するのではなく、パフォーマンスモニタを使えば、問題の本質に切り込めることがおわかりいただけるだろう。
コラム：チューニングが必要なサーバーコンポーネント
サーバーアプリケーションによっては、設定ファイルを開いてパラメータを変更したり、レジストリを変更したり、と様々なチューニングが行われる。そうしたチューニングを行ったときに、どの程度のパフォーマンスの改善があるのかを確認したい場合、データコレクタセットの「構成データコレクタ」を利用することをお勧めする。
データコレクタセットではこれまで、システムコンポーネントのパフォーマンスを計測するために利用してきたが、同じくデータコレクタセット内の構成データコレクタを使うと、レジストリやファイルの情報を追跡することもできる。
また、構成データコレクタで収集可能なデータは次のとおりだ。
収集可能なデータ 説明 レジストリ 特定のレジストリキー内に格納されているデータを収集 管理パス WMIクエリを実行し、コンピュータの状態情報を収集 ファイルキャプチャ データコレクタセットを実行した時点での、コンピュータ内にある特定のファイルを収集(ファイルごとコピー) 状態のキャプチャ コンピュータに接続されているNICの状態(プロパティ内の情報)を収集
データコレクタセットで収集した情報はレポートを通じてその結果を確認することができる。レポートは「信頼性とパフォーマンス」管理ツールの「レポート」から参照することができる。
データコレクタセットは、パフォーマンス計測を行う「Performance Counter」と構成情報を収集する「Configuration」の2つがセットになって構成されているので、パフォーマンス計測したデータとその時点での構成データコレクタ情報がまとめて保存されることになる。前述のように、レジストリを修正しながらパフォーマンスチューニングをするような場合、パフォーマンス計測をしながらその時点でのレジストリ値を保存することができる。そうすれば、どの時点でのレジストリ値がパフォーマンスを考慮した場合に良い設定なのかを後から振り返ることができる。
