Windows(XP、7、Serverなど)の場合、Ctrl+Alt+Del キーで表示する「タスクマネージャ」^{【備考1】}、および表示されるグラフの元となる値は「パフォーマンスカウンタ」と呼ばれる、カーネルが持っている情報を使用しています。視覚的なグラフにすることで、直感的に問題を発見することが出来ます。グラフ描画は、パフォーマンスを確認するのに最適な方法です。

　Windowsに限らず、OracleのOEM(Oracle Enterprise Manager)、またはJP1などで提供される各種ツールもグラフを表示して、パフォーマンス管理を容易にしています。

　ここで大きな問題があります。これらのツールは、パフォーマンス情報を確認しなくてはならない被測定機上で実行されるため、システムリソースを消費してしまう欠点があるのです。Windowsで「パフォーマンスカウンタ」を多く追加する、あるいはJP1で監視項目を追加していく、またはOEMでリフレッシュ間隔を短くして詳細なプロットを表示するなど^{【備考2】}・・・これらのツールは多大なシステムリソースを消費しまい、本来のパフォーマンス問題を捉えることができなくなります^{【備考3】}。

　弊社の開発したツールは被測定機のシステムリソースに影響を与えないように考慮されています。パフォーマンス情報の採取中、CPUリソースは0.5%以下、メモリ消費も抑えています。ディスク入出力回数を低減するため、バイナリで採取する情報もあります。ネットワークは使用しません^{【備考4】}。OracleやWindowのパフォーマンス情報採取ツールは分単位で採取間隔を指定するようにしています。パフォーマンス情報の編集は他のシステムで編集することを前提にしています。グラフ描画はWindows上のMicrosoft ExcelのVBAを使用し、パッチ処理にしています^{【備考5】}。これらを考慮することで、純粋なパフォーマンス情報を分析することが可能になります。

【備考1】	「タスクマネージャ」は同時に一つ実行できますが、複数個実行することはできません。
【備考2】	ORACLE9iハイパフォーマンスチューニングSTATSPACK編によると10分〜15分間隔で採取するのが望ましいとあります。ところがOEMパフォーマンスタブのデフォルトリフレッシュ間隔は15秒です。えぇ〜っ!? 早過ぎないっ!?
【備考3】	JP1で15%ものCPUリソースを消費する事例があります。OEMでは50%ものCPUを消費するケースがあり、他にディスクI/Oやネットワーク帯域を消費する事例がたくさんあります。こうなると、調査しようとする性能問題は見えなくなります。また、サーバの「本来のサービス」を阻害してしまいます。性能管理のために本来のサービスを遅くするなんて本末転倒ですよね!?
【備考4】	リモート接続環境でツールを起動した場合はツール開始時と終了時、ネットワーク上に僅かなパケットが流れます。また、tarアーカイブ、gzip圧縮されたパフォーマンスデータを他のシステムに移動する際は、SFTPやFTPパケットが発生します(これは止むを得ないですよね)。弊社開発の性能情報採取ツールは他のツールとは一線を画しており、パフォーマンス情報採取中は「全くネットワークは使用しない」構造になっています。
【備考5】	「グラフ作成なんて簡単だよ! Excelでテキストファイルを取り込んで、パパッと書きゃいいんだろ!?」と言われる方が多くいらっしゃいます。4〜5個のグラフはそれでも良いですが、何百個にもなると如何ですか? それでも良いという暇な方はこのようなツールは不要です。いつまでも手作業でグラフを描き続けてください・・・もう一つ、カーネルやデバイスドライバ、ORACLEなどの基幹モジュールを開発した方々がたくさんいらっしゃいます。これらの開発者は「必要なカウンタや性能指標だから値を正確に記録し、それらを外部から見えるようにしている」のです。各位の知っている範囲の値はそれらのごくごく一部分であることを理解すべきだと思います。言い換えれば、不要なカウンタや性能指標は記録していないと言うことです。