2005年09月17日

パフォーマンス監視とチューニング

○ パフォーマンスチューニングのストラテジ
応答時間の最適化
  特定クエリ、アプリケーションのパフォーマンスを向上
  アプリケーション、環境、およびユーザーに関する知識が必要
スループットの最適化
  システム構成、トランザクション設計、クエリの作成
  SQL Server がデータアクセス、同時実行、および OS との対話を行う方法に関する知識が必要

○ パフォーマンスチューニング方法の選択
アプリケーションの応答時間およびサーバーのスループットを最適化する方法
  クライアントアプリケーションのチューニング
    検索を制限するクエリを記述
    有用なインデックスの作成
    ロックの競合を最低限にし、デッドロックを避ける
    競合を減らし、同時実行を増やすストアドプロシージャを使用
    必要に応じてサーバーからデータおよび処理をオフロード
  データベースのチューニング
    論理設計/物理設計の改良
  SQL Server のチューニング
    ストレージデザインを評価、設定オプションの調整
  ハードウェア構成のチューニング
    メモリ、プロセッサ、ディスク、ネットワーク等

○ パフォーマンスチューニング方法の開発
パフォーマンスのための設計
  アプリケーション設計の段階でパフォーマンスを考慮
  ユーザー要件の確認
  データ内容の確認
  データベースの適切設計
    … 正規化/非正規化の使用
    … リレーショナルスキーマ、スタースキーマ、スノーフレークスキーマの設計
  ストアドプロシージャの作成、テスト
  インデックスストラテジの設計
  メンテナンスおよび監視の実施のスケジュール化
パフォーマンスの計画
  テスト環境からベースラインを決定
  リソース、負荷、パフォーマンスに対するサーバー操作のパラメータ定義
  スループットおよび応答時間の目標
  全アクションの文書化、結果測定
  シミュレートされた実運用環境のベンチマーク
  データベースのトランザクション分析
  パフォーマンス問題の識別
  パフォーマンスベースラインの決定

○ パフォーマンスベースラインの決定
データベースのパフォーマンスに影響を与える要因
 
作業負荷 サーバーアクティビティ量
スループット 一定時間内のクエリ総数
システムリソース ハードウェアの物理容量
最適化 アプリケーションおよびデータベースの設計
競合 データレコードの競合
ベースライン決定のための材料
  データベースアクティビティのピーク時間/オフピーク時間
  クエリおよびバッチの応答時間
  バックアップおよび復旧に要する時間

○ パフォーマンスボトルネックの検出
調査内容の決定
  メモリ、CPU、ディスク I/O、ユーザー接続、ロックの監視
許容範囲の認識
  ベースラインより極度に高い/低い値 → ボトルネック
  システム監視時に SQL Server 上で作業負荷シミュレーションを行うことで実際の限界を検出
posted by w@ko at 17:23|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。