Database Performance Analyzer (旧Ignite）のレスポンス・タイム分析について

投稿日: 2012年9月30日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

レスポンス・タイム分析は何がアプリケーション・エンドユーザに「待ち」を起こしているか – というDBAと開発者がデータベース管理するにあたって最も重要な基準でアプリケーションとデータベースのパフォーマンスを管理する新しいアプローチです。また待ち時間分析と参照することでITチームはITユーザに対して提供するサービス・レベルを改善することができます。

単にサーバの健全状態を確認し、パフォーマンス・インパクトについて想定を行うより、ウェイト（待ち）とレスポンス(応答）タイム手法は要求されたオペレーションが完了するまでの時間を計測します。最適な実装方法は個別に、個々で計測可能なステップに時間を分類し、アプリケーション遅延を起こしているオペレーションで、どのステップかを正確に識別します。データベースでのもっとも重要な使命は結果を応答するということで、レスポンス・タイムはデータベース・パフォーマンス決定を行う上で最も重要な基準です。

レスポンス・タイム＝プロセス・タイム＋ウェイト・タイム

レスポンス・タイムは実プロセス・タイムとロック、ログ・ファイル、または多くのウェイト・イベントやウェイト・タイプなどの利用可能なリソースの待ちに消費されたセッションの時間の合計です。セッションがCPUをアクセスしている（例：CPUウェイト・タイプ）時にCPUはしばしばI/Oや他のオペレーションがプロセスが続けられる前に完了を待っているいるので、必ずしもアクティブに処理されてはいません。複数のセッションが同じプロセス・リソースを使用して実行している時にはウェイト・タイムは実際のレス分す・タイムに最も大きく影響します。

ウェイト・エベントとウェイト・タイプ

データベースでのレスポンス・タイムを正確に測定するには、時間を蓄積しているステップを個別に識別する必要があります。物理I/Oオペレーション、バッファー操作、ロックによるウェイト、そして他のデータベース・オペレーションに対応するステップはデータベース・ベンダーによって実装されています。SQL Serverではこれらはウェイト・タイプ「Wait Type」と呼ばれ、Oracle, Sybase,DB2ではウェイト・エベント「Wait Event」として参照されます。詳細は各ベンダーごとにユニークですが一般的な考え方は同じです。これらのウェイト・エベント/タイプは各データベース・リソースでのセッション待ちで消費された合計時間を示しています。もしウェイト・エベント/タイプが正確にモニターと分析ができれば、遅延を引き起こすボトルネックとクエリーを正確に判断することができます。

図はレスポンス・タイムのモニター処理を示しています。各SQLクエリー・リクエストはデータベース・インスタンスを通してパスされます。各ウェイト・エベント/タイプ・ステップはSQLパスで黄色の三角マークで示されています。各ステップでの時間を計測することで、総合のレスポンス・タイムを分析することができます。

従来型の統計との違い

一般的なデータベース・パフォーマンス・モニター・ツールはサーバの健全性の計測と実行比率にフォーカスしています。これらの統計の高度なプレゼンテーションでさえもエンドユーザ経験の反映、問題の根源の場所の公開を行っていません。何度オペレーションを行ってもそれが実際にアプリケーションの遅延を起こしたものかどうかは分かりません。

レスポンス・タイム(Ignite) vs. 従来型分析手法とを識別するの主な基準

●リクエストの受付からレスポンスの開始まで実行を起こした時間を計測
●SQLクエリーを個々に分析することでレスポンス・タイムに影響している特定のSQLを分離、評価が可能。有効な情報を提供しないインスタンス全体の合計レスポンス・タイムを計測
●SQLクアリーが処理する個別の内部ステップ(ウェイト・タイプ/イベント)を識別。問題解決には手助けにはならない内部消費時間を無視して、インスタンスをブラック・ボックスとして取扱い。

レスポンス・タイプ分析での実務的な考慮

パフォーマンス・モニターへのレスポンス・タイム・アプローチはそれがパフォーマンスが重要視される環境で効果的に導入されれば、問題解決能力の高いものとなります。Igniteはこの要求に合致する、パフォーマンス・インパクトの低い、エージェントレスな技術を使用しています。エージェントレス・アーキテクチャはプロセスを別システムに行わさせ、実務データベースへの影響は1%以下です。

●エージェントレス・データベース・オペレーション：本番サーバ上でのソフトウェアのテスト、インストール、保守の必要性を除外
●本番データへのパッシブなモニタリング：本当の本番セッションをモニターし、テスト・トランザクションでのシミュレーションを行わない
●24/7の継続したモニタリング：すべてのオペレーションがいつでも詳細に分析できるようにすべてのサーバでのすべてのセッションを継続的にモニタリング。不定期なトレース・ファイルは継続的なカバーはできません。

関連したトピックス