SE の雑記

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

P11 を例とした SQL Database の環境情報の取得

leave a comment

SQL Database を触ろうと思ったら、Premium にP11 というパフォーマンスレベルが増えていました。
image

今までは、P6 (以前の P3) の 100 DTU が最大でしたが、P11 で 1750 DTU / 1TB のデータベースがサポートされるようになったようです。
SQL Database の価格 も更新がされているようです。

image

Azure SQL Database Service Tiers and Performance Levels は、まだ更新がされていないようですが、これもそのうち更新されるかと思います。

P11 の環境を確認しがてら、いつもどのようにして環境情報を取得しているかをまとめてみたいと思います。

SQL Database では DMV からの情報取得ができますが、すべての DMV が使用できるわけではありませんので、使用できる DMV を組み合わせて把握する必要があります。

最初に、CPU の個数を取得してみたいと思います。
SQL Server であれば、sys.dm_os_sys_info から CPU の個数を取得することができますが、SQL Database ではこの DMV は使用することができません。

そこで、sys.dm_os_schedulers から情報を取得します。

スケジューラーの情報からは、NUMA ノードと CPU のマッピングの情報を確認することができます。

SELECT * FROM sys.dm_os_schedulers where is_online = 1 and status = 'VISIBLE ONLINE'

このクエリを 4 コアの SQL Server で実行すると以下のようになります。

image

それでは、P11 で実行してみたいと思います。

image

この実行結果から、以下のことがわかります。

  • parent_node_id から、0 / 1 の 2 NUMA ノード構成となっている。
  • cpu_id から、NUMA ノード 0 に 0 ~6 までの 7 コア、NUMA ノード 1 に 9 ~ 15 までの 7 コアが割り当てられている。
  • スケジューラーの総数から、SQL Database として 14 コアを使用することができる。

次に、ディスクの情報を確認してみたいと思います。

ディスクの情報は細かく確認することができず、sys.sysfiles から現状のサイズとファイルの割り当て状況を確認できるぐらいになるかと思います。

select
fileid,groupid,name,filename,
size * 8 / 1024 AS size_MB, maxsize * 8 / 1024 AS maxsise_MB, growth * 8 / 1024  AS growth_MB
from sys.sysfiles

P11 では、1TB まで使用することができるということになっていますが、maxsize_MB から、データベースファイルの最大サイズで、これを制御していることが確認できますね。

image

データベースのファイルの割り当てや I/O の発生状況については、sys.dm_io_virtual_file_stats から確認することができますので、性能を測定する際には、ここから取得できる情報も役に立ちます。

select * from sys.dm_io_virtual_file_stats (DB_ID(), NULL)

image

 

最後に、メモリの情報を確認してみたいと思います。

メモリについても sys.dm_os_sys_info から確認ができるとよいのですが、DMV が使用できないため「どれだけのデータがキャッシュできるか」という観点での測定となるかと思います。

テストのために以下のようなクエリを実行します。

SET NOCOUNT ON
GO
CREATE TABLE Test(Col1 char(1000))
DECLARE @cnt int = 1
WHILE (@cnt <= 2000000)
BEGIN
	IF @@TRANCOUNT = 0
		BEGIN TRAN
	INSERT INTO Test VALUES(NEWID())
	IF @cnt % 50000 = 0
	BEGIN
		COMMIT TRAN
		BEGIN TRAN
	END
	SET @cnt += 1
END
IF @@TRANCOUNT > 0
	COMMIT TRAN

 

実行することで「1000 バイト× 2,000,000 = 2,000,000,000 = 2GB」のデータが格納されることになります。

実行後のデータベースのファイルの状態を sys.files から取得してみた結果がこちらになります。

約 2GB 程度まで拡張が行われていることが確認できますね。

image

この状態でどの程度データをキャッシュしているかを以下のクエリで確認します。

select page_type,SUM(row_count) row_count,count(*) * 8 / 1024 page_MB
from sys.dm_os_buffer_descriptors where database_id = DB_ID()
group by page_type

約 2.2GB のデータがキャッシュされていることが確認できます。

image

SQL Database では、リソースの使用状況を sys.dm_db_resource_stats から確認することができます。

select * from sys.dm_db_resource_stats

image

現状、2.2GB のデータをキャッシュしていますが、これは全体として使用できるメモリの「2.4%」であることが、この情報から確認することができます。

2.2 GB で 2.4% ですので、この 41.6 倍程度まではキャッシュできると想定することができます。

2.2 × 41.6 = 91.52 ですので、P11 では 91 GB 程度、キャッシュに使用できるのではと想定することができます。

CPU コア数としては 14 コアですので、CPU については、7%程度が 1 コアをフルに使っている状態となるかと。

以下は、仮想マシンの D シリーズのインスタンスとなりますが、スペック的には D14 に近いもので動作していそうですね。

image

Share

Written by Masayuki.Ozawa

9月 23rd, 2015 at 3:52 pm

Posted in SQL Database

Tagged with

Leave a Reply