SE の雑記

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

SQL Database の新しいエディションの特性を調べてみる

leave a comment

パフォーマンス向上が行われましたので、SQL Database の新しいエディションの特性を調べてみる (2014/7 版) を投稿しました。
最新の情報はこちらをご覧ください。

 

現在はプレビューですが、SQL Database で新しく、Basic / Standard エディションが提供され、各エディションに応じてパフォーマンスレベルが設定され、今までは Premium を除くとベストエフォートだったものがパフォーマンス目標がたてられるようになりました。

Azure SQL Database Service Tiers and Performance Levels

image

 

これにより、各エディションに応じてトランザクションレートが異なってきます。
今まではスケールアウトが性能を伸ばす方法だったかと思いますが、エディションとパフォーマンスレベルを変更することにより、スケールアップができるようになったようですね。

SQL データベースの料金詳細

image

Azure SQL Database Service Tiers (Editions)

image

DTU については、Azure SQL Database Service Tiers and Performance Levels に記載されている以下の記述になるかと。具体的な値については記載されていないようですね。

Database Throughput Unit (DTU): The resources powering each performance level are represented in DTUs. It combines CPU, memory, physical reads, and transaction log writes into a single unit. A performance level with 5 DTUs has five times more power than a performance level with 1 DTU.

新しいエディションでは料金体系も変更になり、今までのデータベースの実際の使用量から、エディション / パフォーマンスレベルに応じた課金体系となるようです。

image
image

 

 

■性能特性を調べてみる


それでは本題に入ってみます。

以下のように複数のデータベースを作成して性能特性を見てみたいと思います。
image

 

今回、性能特性を見るために使うクエリは以下になります。
テスト用のテーブルを作成し、5,000 件の INSERT をして、待ち事象を確認するというものになります。

<br />SET NOCOUNT ON <br />GO <br />CREATE TABLE Table_1 <br />( <br />c1 uniqueidentifier, <br />c2 char(1000), <br />CONSTRAINT PK_Table_1 PRIMARY KEY (c1) <br />) <br />GO <br />SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_type ASC <br />GO <br />INSERT INTO Table_1 VALUES(NEWID(), NEWID()) <br />GO 5000 <br />SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_type ASC <br />GO <br />

 

まずは、現状の SQL Database で使用されることの多い、Business エディションで実行してみたいと思います。

SQL Database ではデータを 3 重化していますので、そのための ACK の応答 (SE_REPL_COMMIT_ACK) と、今回は INSERT のクエリを実行していますので、ログの書き込みに伴う待ち (WRITELOG) が大半を占めています。

image

続いて Basic で実行してみます。

先ほどは 1:53 で終了していたのですが、9:19 かかっています。

特筆してみた方がよさそうな待ち事象としては、LOG_RATE_GOVERNOR でしょうか。

Business の場合は、SE_REPL_COMMIT_ACK / WRITELOG が高い値を示していましたが、Basic の場合は、これらに加えて、LOG_RATE_GOVERNOR が高い値を示しており、処理実行中のトータルとして、435 秒 (7分15秒) 待ちが発生したようです。

GOVERNOR ということから、ログ書き込みのトランザクションレートを調整するための調整機構が入っているのかもしれないですね。

データ冗長化のための待ちの前にこの調整による待ちが入っているようで、これらの待ちが影響して、7分程度の処理の差が出ているのかもしれません。

image

続いて、Standard S1 の実行結果がこちらになります。

こちらは、4:35 で終了しています。

Basic の場合と、待ちの発生傾向は同じになっていますが、LOG_RATE_GOVERNOR は 162 秒 (2 分 42秒) となっているため、Basic と比較して低い値となっています。

image

最後に、Standard S2 の実行結果になります。

こちらは、処理時間が、3:03 で LOG_RATE_GOVERNOR が 62 秒 程度となっています。

image

最終的な待ち事象の結果がこちらです。

データの挿入系の処理の場合は、DTU が異なることで、書き込み性能に差が出てくるようですね。

wait_type Business Basic Standard S1 Standard S2
Count Time (ms) Count Time (ms) Count Time (ms) Count Time (ms)
ASYNC_TRANSPORT_STREAM 3 0 3 0 3 0 2 0
CMEMTHREAD 9 0 36 4 4 0 0 0
LOG_RATE_GOVERNOR 0 0 8,956 435,217 5,407 162,228 2,831 62,191
PAGEIOLATCH_EX 2 10 1 1 2 1 0 0
PAGEIOLATCH_SH 0 0 0 0 0 0 0 0
PAGEIOLATCH_UP 1 0 1 0 1 0 1 0
PAGELATCH_EX 2 0 2 0 1 0 3 0
RESOURCE_GOVERNOR_IDLE 0 0 0 0 1 7 0 0
SE_REPL_COMMIT_ACK 5,000 12,932 5,000 14,726 5,000 13,676 5,000 12,977
SE_REPL_QUEUE_TRUNCATE 0 0 1 0 0 0 0 0
SE_REPL_QUEUE_XACT_ACK 0 0 6 1 0 0 0 0
SOS_SCHEDULER_YIELD 37 0 1 0 15 14 24 0
WRITE_COMPLETION 4 2 4 3 4 4 4 3
WRITELOG 5,002 6,933 5,002 9,655 5,002 8,021 5,002 7,724

 

ポータルから各種メトリックを取得したものが以下になります。

Standard S1 の情報が個人的に納得いっていないですが…。

imageimage

imageimage

取得できるメトリックも既存のものと新しいものでは異なっており、新しいエディションのものは取得できる情報が増えています。

imageimage

 

 

最後にSQL Query Stress を使って、以下のクエリを実行してみたいと思います。

 

<br />SELECT COUNT(*) FROM Table_1 WITH (NOLOCK) <br />ORDER BY NEWID() <br />

左上からBusiness  / Basic / Standard S1 / Standard S2 となります。

データの件数はすべて同じなのですが、処理時間やエラーの発生状況が異なっています。

imageimage

imageimage

Basic で発生したエラーは以下になります。

Resource ID : 2. The session limit for the database is 150 and has been reached. See ‘http://go.microsoft.com/fwlink/?LinkId=267637’ for assistance.

Login failed for user ‘xxxx’.

This session has been assigned a tracing ID of ‘XXXXXXXXXXXXXXXXXXX’.  Provide this tracing ID to customer support when you need assistance.

既存の Web / Business エディションの終了予定日もすでにアナウンスされていますので、新しいエディションを使用する際には、性能特性を意識しておいた方がよいのかもしれないですね。

image

2014/5/5 追記

Premium エディションでも測定してみました。

P1 / P2 の順になります。

# 無償分の枠がなくなって P3 は試せませんでした。

P1/P2 ともに 1:57 で処理が終了しました。

P1 の実行結果を見ると [LOG_RATE_GOVERNOR] の発生が少なくなっており、P2 では発生していません。

今回のクエリの INSERT 負荷では P1 / P2 ともに調整が行われても同程度の性能となるようですね。

image

image

 

wait_type Premium P1 Premium P2
Count Time (ms) Count Time (ms)
ASYNC_TRANSPORT_STREAM 0 0 0 0
CMEMTHREAD 0 0 0 0
LOG_RATE_GOVERNOR 33 497
PAGEIOLATCH_EX 1 0 1 0
PAGEIOLATCH_SH 0 0 0 0
PAGEIOLATCH_UP 1 0 1 0
PAGELATCH_EX 3 0 2 0
RESOURCE_GOVERNOR_IDLE 0 0 0 0
SE_REPL_COMMIT_ACK 5,000 13,411 5,000 12,853
SE_REPL_QUEUE_TRUNCATE 0 0 0 0
SE_REPL_QUEUE_XACT_ACK 2 0 0 0
SOS_SCHEDULER_YIELD 34 0 28 0
WRITE_COMPLETION 4 3 4 2
WRITELOG 5,002 7,354 5,002 7,346

 

wait_type Business Basic Standard S1 Standard S2 Premium P1 Premium P2
Count Time (ms) Count Time (ms) Count Time (ms) Count Time (ms) Count Time (ms) Count Time (ms)
ASYNC_TRANSPORT_STREAM 3 0 3 0 3 0 2 0 0 0 0 0
CMEMTHREAD 9 0 36 4 4 0 0 0 0 0 0 0
LOG_RATE_GOVERNOR 0 0 8,956 435,217 5,407 162,228 2,831 62,191 33 497
PAGEIOLATCH_EX 2 10 1 1 2 1 0 0 1 0 1 0
PAGEIOLATCH_SH 0 0 0 0 0 0 0 0 0 0 0 0
PAGEIOLATCH_UP 1 0 1 0 1 0 1 0 1 0 1 0
PAGELATCH_EX 2 0 2 0 1 0 3 0 3 0 2 0
RESOURCE_GOVERNOR_IDLE 0 0 0 0 1 7 0 0 0 0 0 0
SE_REPL_COMMIT_ACK 5,000 12,932 5,000 14,726 5,000 13,676 5,000 12,977 5,000 13,411 5,000 12,853
SE_REPL_QUEUE_TRUNCATE 0 0 1 0 0 0 0 0 0 0 0 0
SE_REPL_QUEUE_XACT_ACK 0 0 6 1 0 0 0 0 2 0 0 0
SOS_SCHEDULER_YIELD 37 0 1 0 15 14 24 0 34 0 28 0
WRITE_COMPLETION 4 2 4 3 4 4 4 3 4 3 4 2
WRITELOG 5,002 6,933 5,002 9,655 5,002 8,021 5,002 7,724 5,002 7,354 5,002 7,346

 

検索については 1 秒程度の差となっていました。

imageimage

どちらの場合も Standard と比較して性能は出ていますね。

Written by masayuki.ozawa

5月 3rd, 2014 at 1:03 pm

Posted in SQL Database

Tagged with

Leave a Reply

*