前回の投稿はこちら
Elastic Pool Preview を触ってみる その 1
今回の投稿では軽く性能の特性を見てみようかと思います。
Ignite での情報は Elastic Scale for Microsoft Azure SQL Database が公開されていますのでこちらを参照していただければ。
- プール全体の DTU : 2000
- 各データベースの最大 DTU : 100
の設定となっています。
現状、Elastic Database Pool は Standard の価格レベルのみが使用できるようになっています。
そのため、基本的な性能特性としてはスタンドアロンデータベースの Standard に準拠しているかと思います。
今回は CPU を使用して Elastic Pool の DTU の特性を見てみたいと思います。
CPU のみを利用し続けるクエリを PowerShell から実行しています。
このクエリは Standard S3 (100DTU) で実行した場合にも、平均で同程度の処理時間がかかるものになっています。
現在、一つのデータベースに対して、クエリを実行して CPU を最大限まで使用していますので、最大でも
- 100DTU / 200DTU
が使用されている状態となります。
# データベース単位の最大の DTU は 100 としていますので、プール内の DTU に余裕があれば 100DTU の性能で CPU が利用されます。
これはポータルの Elastic Pool monitoring からも確認することができ、1 つのクエリで 1 つの DB の CPU を張り付けている状態は 50% を推移している形となります。
この状態でプールに含まれているほかの DB に対してクエリを実行してみます。
そうすると以下のように、各 DB でのクエリじっく時間が 2.5 秒平均 (1 クエリの時の倍) になっていることが確認できます。
先ほどまでは 1.3 秒程度で実行されていたものが倍の時間になったので、DTU としても半分くらいの性能に調整が行われ、処理時間が伸びたと考えられます。。
この状態で、さらに 2 つの DB に対してクエリを実行してみます。
そうするとの以下のような処理時間でクエリが実行された状態となります。
最初と比較して、倍の処理時間の状態が 50DTU だとすると 50DTU × 4 で 200 DTU に合わせている感じでしょうか。
それでは追加でもう一つクエリを実行して、5 データベースに対してクエリが実行された状態にしてみたいと思います。
DB04 / DB05 は 2.5 秒程度で処理が実行できていますが、DB01~DB03 については 3.6 秒程度と 50DTU より下の状態で処理が行われていそうですね。
この状態で最大 DTU を 100 → 10 に変更してみます。
そうすると、全体的に 10 秒平均のクエリ実行となったことが確認できます。
20DTU にするとこのような感じです。
最大が 10DTU の場合は 10 秒平均だったものが 20DTU だと 6 秒平均ぐらいになっていますね。
Elastic Pool では全体の CPU 使用率が高くなったときに最大 DTU を操作して、プールに含まれる各 DTU の性能を制限することが容易に行うことができます。
プールとしての DTU についても簡単に変更することができますが、プール側を変更した場合は、接続の切断 / 変更中の接続ができないというような状態となるようですので、この辺は気を付けておく必要がありそうですが。
# 変更の完了にはプールに含まれる DB の数も影響していそうですね。また、DB の接続の切断のタイ
ミングは同時ではなくずれるようですが、どの DB から切断という優先付けはできないようですので、 DTU の更新が終わるまで待ちます。
Elastic Pool のデータベースは重みづけ / 優先付けができないため、特定の DB には必ず一定の DTU を割り当てるということはできません。
たただし、全体を平準化して、一部の DB に負荷がかかっていた場合でも全体としてのスループットを平準化しようとはしているようですので、複数の DB でスパイクが発生した場合でも性能の劣化を抑えようとする動きはしていそうですね。