SQL Azureを徹底活用

第5回SQL Azureパフォーマンスチューニングのための情報収集

今回は、SQL Azureのパフォーマンスチューニングをする際に、どのような情報を参照することができるのかを紹介します。

パフォーマンスチューニングの機会

オンプレミス、クラウドに関わらず、システムを開発し運用していくと、パフォーマンスチューニングをする必要性が生じることがあります。開発をしているとき、テスト(負荷テスト)をしているとき、運用を始めたとき、運用開始して時間が経過したとき、それぞれの段階でシステムのレスポンス性能に満足がいかず、パフォーマンスチューニングを検討する必要性がでてくる可能性があります。

システム全体で性能ネックの箇所を特定し、チューニングをしていくことになります。性能ネックがSQL Azure部分にあることが判明した場合、どのような性能問題が発生しているのかを切り分けるためには、いろいろな情報を参照することになります。今回は、参照できる情報と参照方法について紹介します。

SQL AzureのレスポンスタイムとNW通信

SQL Azureに関わる性能は、データベースの処理時間とNW通信時間の2つから構成されます図1⁠。

図1 SQL Azureのレスポンスタイム
図1 SQL Azureのレスポンスタイム

NW通信時間は、アプリケーションサーバーとデータベースサーバー間、クライアントアプリケーションとデータベースサーバー間の通信時間が影響します。アプリケーションサーバーとデータベースサーバー間の通信時間が最小になるのは、SQL Azureと同じデータセンターにサービスをデプロイしたときです。

NW通信時間を調べるには、データベースの処理時間が限りなく0になるSQLを発行することです。たとえば、⁠SELECT 1」を発行した時のレスポンスタイムがNW通信時間の近似値となります。SQL Server Management Studioで、レスポンスタイムを計測することができます図2⁠。

図2 通信時間(の近似値)を計る方法
図2 通信時間(の近似値)を計る方法

全世界6ヵ所から、全世界6ヵ所にあるWindows Azureデータセンターまでの通信時間を計測した結果が、Tech ED North America 2011のセッション資料に参考情報として掲載されていますMicrosoft SQL Azure Performance Considerations and Troubleshootingので、SQL Azureサーバーの配置場所選択時の参考にしてください。

また、筆者のBlogでも概要を紹介しています。

SQL Azureの処理時間に関係するもの

まず、ざっくりとしたデータベースでの処理概要を説明します。SQL Azureの処理時間に関わるコンポーネントとして、CPU、メモリ、HDDがあります図3⁠。

図3 SQL Azureの処理時間に関わるコンポーネント
図3 SQL Azureの処理時間に関わるコンポーネント

参照SQLを発行すると、CPUでコンパイルし、必要なデータをHDDから読み込みメモリに展開し、結果を返します。一時テーブルやソート処理時など必要に応じて、tempdbを使用します。更新SQLを発行すると、参照クエリ時の処理に加え、メモリ内のデータ更新、トランザクションログ更新、データ領域の更新が追加されます。

チューニングのポイントは、物理I/Oを減らし、CPU処理を減らすことです。それらを減らすためにメモリが活用されます。メモリには、SQLのコンパイル結果やユーザデータなどが格納され、再利用することで物理I/OやCPU処理を減らしています。しかし、メモリ容量も有限なので、メモリに格納する情報量を少なくするように留意する必要があります。

SQL Azureでの全体的な情報収集

オンプレミスのSQL Serverでは、パフォーマンスカウンターや(サーバー関連の)動的管理ビューで取得することができ、サーバ全体の状況把握をしやすくなっています。しかし、SQL Azureでは、パフォーマンスカウンターや(サーバー関連の)動的管理ビューが提供されていません。

SQL Azureでのサーバー情報の収集方法が2つあります。

1つめは、SQL Azure管理ポータルを利用することです。SQL Azure管理ポータルで確認できるのは、CPUの使用時間の確認です。管理ポータルでは、1日ごとのCPU使用時間が表示されます図4⁠。

図4 SQL Azure管理ポータルでCPU使用時間を知る方法
図4 SQL Azure管理ポータルでCPU使用時間を知る方法

2つめは調整サービスのエラーログを収集することです。SQL Azureは、リソースを他のユーザと共有するモデルで提供されており、全ユーザが均等にリソースを使用できるように調整サービスが実装されています。調整サービスは、リソースを極端に占有すると強制的に切断するサービスです。調整サービスにより強制切断されると切断理由がエラーコードで返され、エラーコードをデコードすることで切断理由を調べることができます。

調整サービスの詳細とデコード方法は、前述したTech EDのセッションで紹介されていますMicrosoft SQL Azure Performance Considerations and Troubleshootingので、参考にしてください。エラーコードを記録し収集することで、リソース不足による問題が発生している場合は、どのような問題が発生しているのかを切り分けることができます。

SQL Azureでの問題あるクエリ情報の収集

SQL Azureでは、サーバーチューニングがSQL Azure Federationによるデータベース分割しか選択肢がないため、クエリチューニングがメインのパフォーマンス・チューニングとなります。

SQL Azure管理ポータルで、実行回数順、CPU使用時間順、物理I/O順にクエリを並べ替えて表示することができます図5⁠。

図5 SQL Azure管理ポータルでクエリ表示
図5 SQL Azure管理ポータルでクエリ表示

クエリをクリックすることで、クエリの詳細情報が表示されます図6⁠。

図6 クエリの詳細情報表示
図6 クエリの詳細情報表示

クエリプランのリンクをクリックすることで、クエリプランがグラフィカル表示されます図7⁠。

図7 クエリプランの表示
図7 クエリプランの表示

まとめ

SQL Azureでのパフォーマンスチューニングは、クエリチューニングとなります。クエリチューニング後は、CPU実行時間や調整サービスのエラーログを解析することで全体状況を監視します。クエリチューニングでの対応が困難になってきたら、SQL Azure Federationによるデータベースの分割を検討することになります。

おすすめ記事

記事・ニュース一覧