SE の雑記

先日、SQL Database Hyperscale のパフォーマンスについては SQL Hyperscale のパフォーマンスのトラブルシューティング診断 で公開されていることを書きました。

通常の SQL Database についてもパフォーマンスの調査時に重要となるリソース割り当てについてのドキュメントが、いくつか公開されていたようです。

• dm_user_db_resource_governance (Transact-sql)
• dm_resource_governor_resource_pools_history_ex (Transact-sql)
• SQL Database のリソース制限およびリソース管理

仕事でない登壇で軽い感じで、SQL Database についてお話させていただく際に、いくつかのセッションでは、「SQL Database のリソースの割り当てですが、頑張れば見れます」というようなことをデモを交えてお話させていただくことがありました。
この時に使用していたのは「sys.dm_user_db_resource_governance」という DMV となり、以前はドキュメントが公開されていなかったはずなのですが、情報が公開されたようです。
SQL Database については、現在は、DTU モデル ではなく、vCore モデル の方が新しいハードウェアの投入などが行われており、実行基盤のハードウェアについては vCore モデルの方が進化を続けているような印象を受けます。
そうはいっても、DTU モデルの方が安価で利用できますので、今も DTU モデルを使用し続けることがあるかと。
vCore モデルについては、利用可能な CPU コア数 / メモリ / 最大 IOPS が明記されており、「割り当てリソースの透明性があり、性能の予測がつけやすい」という特徴があります。
DTU モデルについては、DTU ベースの購入モデルでのサービス レベル に記載されているようなベンチマークによって取得された「相対的な性能値」を元にした指標となっています。
相対的な性能値での表現となっているため「データベースに割り当てられているリソースの透明性がなく、性能の予測が難しい」というような特徴がありました。
「リソースの透明性」ですが、DTU / vCore ともに sys.dm_user_db_resource_governance の情報を活用することで、どちらのモデルでも透明性を得ることができます。
vCore より、DTU モデルを使用した場合のリソース割り当ての情報を知りたいということの方が多いと思いますので、今回は DTU を例にして、情報を見てみましょう。
情報の取得には次のようなクエリを使用してみます。

SELECT
	database_name,
	slo_name,
	dtu_limit,
	max_cpu,
	cap_cpu,
	min_memory,
	max_memory,
	FORMAT(max_db_memory, '#,##0,') AS max_db_memory_MB,
	instance_cap_cpu,
	FORMAT(instance_max_log_rate,  '#,##0,,') AS instance_max_log_rate_MB,
	checkpoint_rate_mbps,
	checkpoint_rate_io,
	FORMAT(primary_min_log_rate, '#,##0,') AS primary_min_log_rate_KB,
	FORMAT(primary_max_log_rate, '#,##0,') AS primary_max_log_rate_KB,
	FORMAT(primary_group_min_io, '#,##0') AS primary_group_min_io,
	FORMAT(primary_group_max_io, '#,##0') AS primary_group_max_io,
	primary_group_min_cpu,
	primary_group_max_cpu,
	primary_pool_max_workers,
	FORMAT(volume_local_iops, '#,##0') AS volume_local_iops,
	FORMAT(volume_type_local_iops, '#,##0') AS volume_type_local_iops,
	last_updated_date_utc
FROM
	sys.dm_user_db_resource_governance

 
今回は、DTU モデルの「S0」と「S1」で情報を取得してみます。
S0 は DTU が「10」、S1 は、DTU が 「20」 となりますので、リソース割り当ての相対比較としては、S1 の方が 2 倍のリソースが割り当てられていることになります。

実際に情報を取得したものが次の画像となります。


全ての値が 2 倍になっているというわけではなありませんが、明確にリソースの割り当てが増えていることが確認できます。
ここで取得されている情報は、実際にパフォーマンスのメトリクスを取得した場合も、類似の値となります。

S1 では、「primary_max_log_rate_KB」が 1.5MB (1,573 KB) となっています。
実際に、ログファイルの I/O の情報を取得してみます。

SELECT GETDATE() AS collect_date,num_of_bytes_written FROM sys.dm_io_virtual_file_stats(DB_ID(), 2)

次のグラフはトランザクションログに書き込みを行う操作を実施している最中に、取得したトランザクションログのファイルに発生しているスループットをグラフ化したものとなります。
グラフの Y 軸はトランザクションログの書き込みバイトサイズを表しているものとなります。

1.6 MB 程度推移していることが確認でき、上記で取得した DMV の「primary_max_log_rate_KB」と同等の書き込みサイズを上限として推移していることが確認できます。

CPU の使用率についても取得してみます。
以下は簡易的な情報の取得を行っていますので、詳細を確認したい場合は sys.dm_resource_governor_resource_pools_history_ex を分析した方が良いかと思います。

select
	FORMAT(
		(select cntr_value from sys.dm_os_performance_counters where instance_name = 'SloSharedPool1' and counter_name = 'CPU usage %') * 1.0  /
		(select cntr_value from sys.dm_os_performance_counters where instance_name = 'SloSharedPool1' and counter_name = 'CPU usage % base')
		* 100
	, '#,##0.##'
	)

 
15% 程度を上限として推移していることが確認できます。

これについては「primary_group_max_cpu」を上限としているということが確認できます。

今まで、SQL Database では、次の DMV を使用して、リソースの使用状況を % で取得することが一般的でした。

• sys.dm_db_resource_stats
• sys.resource_stats

「sys.dm_user_db_resource_governance」の情報と組み合わせることで「実際のリソースの使用状況を確認したうえで、どの程度リソースを使用しているので、その使用状況の % の表示となっているのか？」を確認することができるようになります。
このようなアプローチが可能となると、例えば、オンプレミスの SQL Server から移行を検討した場合に、現在のリソース使用状況を確認したうえで、SQL Database ではどの程度のサイズが必要となるかを、利用可能なリソース上限を元にして検討をする際の精度を向上させることができるようになります。
SQL Database のリソース使用状況は、情報を取得しようと思えば様々な方法で取得することが可能なのですが、今まで公開されている情報では、DTU モデルについては「上限値の具体的な値」を取得することが困難でした。
今回紹介した DMV を使用することで、具体的な上限値を取得することができるようになりますので、メトリクスの情報を取得した際の解析の一助となるのではないでしょうか。