SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Database v12 の性能特性を考える際の参考ドキュメント

leave a comment

ぺんぺん師匠が 9/12までにWeb、BusinessエディションのAzure SQL Databaseは、Basic、Standard、Premiumに移行しよう。自動移行も予告されています、 で書かれていますが、2015/9/12 に SQL Database v11 (v2 と呼ばれることもありますが) から v12 への移行がアナウンスされています。
Web および Business エディションの終了に関する FAQ

v11 で新しいサービス階層を使用している場合には、性能傾向は v12 と似たような形になっているため、傾向はつかめているかと思いますが、Web / Business を使用している場合には、性能傾向がガラッと変わります。

性能傾向をつかむための参考となるドキュメントをまとめてみたいと思います。

最新の情報については Database  から追ってもよいかと。


■参考情報


公式の情報ではありませんが、性能傾向を詳細に検証しているのは、
Microsoft Azure SQL Database Performance Tests: Summary
Azure SQL Database: v12 GA Performance inc. CPU Benchmaring
になるかと思います。

Web / Business と新しいサービス階層の比較についてはこちらの情報がイメージしやすいかと思います。

 

■v12 への移行時のパフォーマンスレベルについて


自分で移行をしない場合、SQL Database の移行はデータベースサイズに応じてパフォーマンスレベルが決定されますので、移行先のパフォーマンスレベルが、現状使用している性能とマッチしていない可能性があります。

そのため、性能については以下のドキュメントを参考にして、どの程度のパフォーマンスレベルが必要かを検討しておく必要があります。
SQL Database の Web/Business データベースを新しいサービス階層にアップグレードする
Azure SQL データベースのパフォーマンス ガイダンス

Web / Business と新しいサービス階層のパフォーマンスを考える際の概念図としては以下のようなものがよくつかわれます。

image

Web / Business では、リソースは共有だったため、同一の環境上に存在しているデータベースの使用状況によって性能にブレがありました。
あまり、使用状況が高いデータベースがいなければ、リソースを潤沢に使うことができますが、他に使用状況が高いデータベースがいる場合には、そのデータベースのリソースの使用状況が影響して、性能が劣化する可能性があります。

新しいサービス階層では、パフォーマンスレベルに応じて使用できるリソースの上限が設定されており、同一の環境上に存在している他のデータベースのリソースの使用状況の影響を受けず、一定の性能を発揮することができるモデルとなっています。

そのため、新しいサービス階層のモデルに移行をすると、

  • 今までと異なり、一定の性能を発揮できる
  • しかし、リソースの使用状況には制限がかかるため、今までと比較すると性能が低下する

というような状況になります。

 

v12 のパフォーマンスレベルとのマッピングの基本的な情報としては、
sys.resource_stats
sys.dm_db_resource_stats
で確認をすることができ、この DMV から性能面でどのパフォーマンスレベルに移行すればよいかを検討することができます。

この DMV では S2 の性能を 100% とした場合の、相対的な利用状況を確認することができます。
sys.oresource_stats は、最大 14 日間分の情報が格納されていますが、5 分間隔の値となっており、細かな間隔の値を確認することができません。
sys.dm_db_resource_stats は 15 秒間隔で情報が格納されるため、上記の DMV より短い間隔の性能が確認できますが、1 時間分の情報となるため、長い期間の情報を確認したい場合は、定期的にデータをユーザーテーブルに格納するというような工夫が必要となってきます。

 

■リソースの制御


パフォーマンスレベルに応じてログイン数やセッション数も変わりますので、以下のドキュメントも確認をしておくとよいかと思います。
Azure SQL データベースのサービス階層とパフォーマンス レベル
Azure SQL データベースのリソース管理
Azure SQL Database Resource Limits 

新しいサービス階層へ移行した際のリソースの制御としては、

  • 同時接続数
  • CPU
  • キャッシュで使用できるメモリ
  • ディスク I/O (ログ / データ)

があるかと思います。
# 厳密には、上記のリソース以外の制御も行われているかと思います。

 

Azure SQL データベース リソース統制 に Web/Business は 180 の同時接続 (厳密にはワーカースレッドだったかと) と記載されていますが、v12 ではパフォーマンスレベルに応じて同時接続が変わってきます。
そのため、v12 に移行することで、同時接続数の変化も発生し、移行前と同じ接続に耐えられない可能性が出てきます。
移行前と同じ接続数に対応するのは S3 の 200 となり、それより小さいパフォーマンスレベルでは 180 の同時接続より少なくなりますので、性能面だけではなく同時接続数も意識をしておく必要があります。

 

以下は私が 2015/5 時点で検証をした際のハードウェアリソースの制御で実施されていると思われる内容の考察となります。
# SQL Database は日々進化していますので最新の情報は適宜確認する必要があるのは留意してください。

 

■CPU についての考察


CPU については使用できる上限がパフォーマンスレベルに応じて変わってきます。
例えばですが、Standard /S2(50 DTU) で 100 % ちょうどの使用状況だったとします。これを Standard/S3 (100DTU) に移行すると大体 50% 程度になるかと思います。

CPU のリソース制御については、

  • CPU の使用上限
  • 利用可能な CPU コア数

が行われており、

  • S3 / P1 で CPU を 1 コア分 100% 使用可能
  • P2 で CPU を 2 コア分 100% 使用可能
  • P3 で CPU を 8 コア分 100% 使用可能

という形になっていそうです。

P2 以上では複数の CPU コアを使用することができますが、単一のクエリについての性能を向上させたい場合などは、対象のクエリが複数のスレッドを使用した並列クエリになっているかが、性能を向上させるためのポイントとなってくるかと思います。
# CPU のコア数が増えることで同時実行性が上がりますので、「同時実行性を上げる」のか、「単一のクエリの実行性を上げるのか」でアプローチが異なってくるかと。

 

■メモリについての考察


メモリについては、

  • データキャッシュで使用できるメモリのサイズ

が、パフォーマンスレベルに応じて異なってきます。

S3 で、大体5GB 程度のデータをキャッシュでき、DTU の性能に応じて、キャッシュで利用できるメモリサイズが変化してきます。

P3 では、45GB 程度は使えそうでしたので、仮想マシンのA7 相当の環境で動作しているのかもしれないですね。

■ディスクについての考察


ディスクについてはデータファイルからのデータ読み込みとトランザクションログへの書き込みで性能差が出てきます。
また、Basic ~ S3 と P1 ~ P3 では、ディスクの基本性能の違い、P2 / P3 では複数コアを使用できるというような基本となる性能が異なってきますので、これらも意識するのが重要となってきます。
ディスクの性能はディスクの IOPS による制限はかかっていそうで、頻繁なディスクアクセスを実施した際の性能に DTU の差が顕著に表れてきます。

極端な例ですが、

  • 1 レコードの INSERT を早くしたい

という場合にはどうすればよいでしょうか。

これですが、

  • Premium のパフォーマンスレベルを使用する

というのが、私の回答となります。

一度の INSERT では数 KB 程度の I/O の発生となりますので、通常、このようなディスクアクセスが IOPS の制限に達することはありません。
# 大量に INSERT を実行した場合は IOPS の制限に達します。今回は 1 件の INSERT を対象としています。

そのため、Basic~S3 では 1 件の INSERT 性能はそれほど変わらないというような状況となることがあります。
1 件の INSERT 性能を上昇させたい場合、ディスクの基本性能を上昇させる必要がありますので、その場合は Premium のパフォーマンスレベルを使う必要が出てきます。

ディスクの性能がネックになってパフォーマンスレベルを変更する場合、ディスク性能を 100% 使っているかどうかがポイントになるかと。
100% に達していない状態では、パフォーマンスレベルを変更して、IOPS の上限を緩和させても性能が想定しているように伸びず、Standard 内で変更するのではなく、Standard → Premium に変更するというようなアプローチを検討する必要が出てきます。

Written by masayuki.ozawa

7月 23rd, 2015 at 11:23 pm

Leave a Reply

*