SQL Database Managed Instance (MI) : CPU とメモリの確認

TL;DR

SQL Database Managed Instance ( MI ) の CPU やメモリの確認方法について、

Azure ポータルでサクッとみれるが、スケールアップ（して諸事情で失敗すると）確認不能になることがある
SSMS のデータベースのプロパティから見ても正確に見れない可能性がある
動的管理ビュー（DMV）使っての確認が確実かなと感じる。

（2018/9月時点）

MI のざっくりな概要と、CPUやメモリの確認方法のメモです。

前置き - SQL Database Managed Instance とは

大規模向けの PaaS の SQL Server

SQL Database Management Instance (MI) は、普通の SQL Server とAzure SQL Database の中間くらいに位置づけられる PaaS のほぼ SQL Server なサービスです。

いまだにオンプレや VM 上ででかい SQL Server を使っており、運用・保守や、サーバー更改で巨額コストを搾取されている方々とっては、まずは Lift & Shift したい場合などの移行先としてよいサービスと感じています。

大規模向けのサービスなので料金もそれなりにします。大規模なデータベースであれば、運用保守面も考慮すれば安いしコスパもよいことは間違いないでしょう。

価格 - Azure SQL Database Managed Instance | Microsoft Azure

2018/10 GA 予定

2018/10 月に GA もすると発表](https://azure.microsoft.com/en-us/updates/azure-sql-database-managed-instance-general-purpose-availability-coming-soon/)されています。

SQL Database との違いは

リソースがデータベース単位に管理される SQL Database と異なり、
MI はリソースが SQL Server 単位で管理されるので、1インスタンスに複数のデータベースを構築してデータベース間をまたいでクエリを発行することとかもできます。

完全に SQL Server と互換があるわけではないので、移行する際は注意が必要です。

公式ドキュメントで以下をみればおおよそ把握できます。

包含データベース機能を有効に活用するとよいかも

ユーザーデータベースの照合順序は自身で決めれますが、サーバー自体の照合順序は固定（SQL_Latin1_General_CP1_CI_AS）です。
ここで問題がありそう（tempdb 使うと照合順序のアンマッチがおきるとか）なら、まずは 包含データベースの設定をすることでクエリを変更せずに解決できる場合が多いかもしれません。

CPU、メモリの確認方法

今回は、vCore 8 (メモリ 44GB）でプロビジョニングした MI を確認てみます。

MI は vCore 数を選択するとメモリのサイズが勝手に決まるので、vCore 数の確認をすればよいです。

まずAzure のポータルでみてみましょう。MI のリソースの概要から見ると、（ストレージのサイズと） vCore 数が表示されます。

f:id:beachside:20180908161631p:plain

概要 > 価格レベル で見るとこんな感じ。

f:id:beachside:20180908161827p:plain

実体験として、スケールアップ中に失敗（権限の問題でこけることがあった...）して表示がおかしくなることがあり、正確に把握するための手段をするためにメモを残したってやつです。

SSMS で確認

まず SQL Server Management Studio ( SSMS ) で MI に接続し、SQL Server のインスタンスを右クリック > プロパティ を見てみましょう。

f:id:beachside:20180908162210p:plain

vCore（ここで表示はプロセッサ） 8 (メモリ 44GB）が見えるはずと思いきや...
いきなりプロセッサが 80、メモリが約440GB も当たってて、課金死亡フラグがチラついて震えます。

f:id:beachside:20180908162221p:plain

もちろん実際に MI にプロビジョニングされた構成とも異なりますのでご安心を。この表示は、基盤となっている VM の総量となるようです。

動的管理ビュー（DMV）で確認

sys.dm_os_sys_info で確認してみましょう。

SELECT cpu_count,
       --format は3桁区切りで表示してるだけですー
       format(physical_memory_kb , N'#,0') physical_memory_kb,　
       format(committed_target_kb, N'#,0') committed_target_kb
FROM sys.dm_os_sys_info;

f:id:beachside:20180908162501p:plain

物理メモリは先ほどプロパティで見た通りですが、実際に割当たってるのはプラン通り44Gっぽい値ですね（微妙に少ない...）

sys.dm_os_performance_counters でも確認できます。

SELECT format(cntr_value,'#,0') cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Memory Manager%'
      AND
      counter_name = 'Target Server Memory (KB)';

運用を加味して、自動またはスケジュールでスケールアップ/ダウンする仕組みを作る際は、これらの DMV で確認してログに残しておいたり問題あればアラート上げるとかすればよさそうです。

雑談

MI で CPU やメモリの割り当ては、 Job Object を利用しているようです。これによって同一の VM 上に SQL Server が相乗りしてもリソースの競合や “noisy neighbor” 問題が起きないようになっていると。
（MI の仕組みとして相乗りすることがあるかは把握してません）

sys.dm_os_job_object で確認してみましょう。

SELECT cpu_rate,
       cpu_affinity_mask,
       process_memory_limit_mb,
       non_sos_mem_gap_mb
FROM sys.dm_os_job_object

f:id:beachside:20180908162528p:plain

cpu_rate: 割り当てられた vCore を利用できる割合。全て使ってることがわかります。
cpu_affinity_mask: 65280 = 1111111100000000（バイナリ形式）で、プロセッサが8つある（と思っていますが...あってるのかな？）
process_memory_limit_mb: プラン通り 44GB が上限に設定されていることがわかります。
non_sos_mem_gap_mb: スレッドスタック、DLL、その他諸々（SQL OS以外）のメモリ割り当て量。4Gくらい使ってますね...あそこで足りなかった分？