【祝】Azure日本DC前夜祭!★Japan Windows Azure User Group 3周年 に参加させていただいた際に、「和牛をおいしく食べるには」というLT をさせていただきました。
当日使用した資料は http://sdrv.ms/17IJSHj からダウンロードしていただくことが可能です。
メモリ集中型インスタンス (JAZUG 界隈で和牛と呼ばれているインスタンス) を使ってみた際の内容を発表したものになるのですが、かなり駆け足で進めてしまったので少し補足を。
今回は自宅の検証環境で作成したゲスト OS のイメージをアップロードしていたのですが、SQL Server 2012 をインストール済み / SQL Server のインストールイメージを保存していたのでサイズがそれなりに大きいものになっています。
容量固定の VHD をアップロードしても未使用分は圧縮されてアップロードされていると思いますが、30 GB 近い VHD を複数回アップロードしたのでプロバイダの制限に引っかかってしまいました。
自宅で検証する場合には OS のベースイメージだけをアップロードして、そこから MSDN サブスクリプションから ISO をダウンロードして構築すると制限に引っかからないかもしれないですね。
Azure VM は Windows Server 2012 の Hyper-V を使用しているようなので NUMA 構成のゲスト OS を使用することができます。
SQL Server は NUMA ノードを意識したメモリアクセスができるようになっていますので、このあたりのテストをするのみ XL と A7 を使用することができます。
SQL Server のワーカースレッドの最大数 (max worker threads) はデフォルトでは [0] が設定されています。
[0] が設定されている場合はワーカースレッドの最大数は SQL Server が CPU コア数に応じて自動設定されるのですが、8 コアの場合は、576 が設定されます。
自動設定により設定されている値については sys.dm_os_sysinfo の max_workers_count から確認をすることができます。
最新の Sysinternals の Coreinfo では NUMA ノード間のコストを取得することができるので、これを使って情報を取得しています。
ディスクについては Windows Server 2012 のストレージプールを使用して 16 本のデータディスクをストライピングしています。
数回計測して、妥当だと思われた結果について記載したものがこちらのスライドになります。
# 3, 4 回計測しています。
バッチの実行ですが、HammerDB というツールを使用しています。
HammerDB では master / slave モードがあり、複数の端末からツールを同期して実行することができます。
HammerDB では各ユーザーの負荷の実行はクエリ単位で接続を閉じるのではなく、最初に接続をしたらテストが終了するまで接続をしたままになるようで、1,000 ユーザー程度の負荷をかけた場合には、自動調整されたワーカースレッド数では不足する可能性があるため、max_worker_thread は 1,500 に設定していたりします。
今回は、20 GB 程度のデータベースサイズ (XL のメモリサイズだと不足する程度のデータ量) を使用しています。
データファイルに関しては 8 個で構成し、ログファイルは 1 ファイルとなっています。
このデータは自宅の検証環境で作ったデータベースを Azure Storage に BACKUP DATABASE でバックアップ圧縮を使用して、IaaS の環境でリストアするという方法で作っています。
リストアに関しては、どのディスクレイアウトで試してもあまり速度は変わらなかったのですよね。。。。
# リストアは複数のデータファイルを並列でリストアするという動作ではなかったので、この辺が影響しているのかもしれませんが。
デフォルトの設定だと、[LCK_M_S] も待ちの上位として現れてきます。
うまく、性能差が出なかったので、共有ロックも影響しているのかなと思って、[Is Read Committed Snapshot On] を有効にして共有ロック待ちを低減させるようにしています。
ログ書き込みとディスクとメモリ間の同期については同じトレンドとなっているので、[LCK_M_X] がネックになっているのではと思いました。
[LCK_M_X] が原因で差が出ているのかどうかは細かいところまでは見れていないのですが、以前他の環境でテストした際に、データの母数が少ないとバッチ実行数が伸びなかったことがあったので今回も同様の現象なのかなと。[LCK_M_X] が原因でトランザクション数やバッチ実行数が伸び悩む例としては採番テーブルから番号を取得する処理が有名だったりしますね。
SQLIO の結果では、ディスクの構成によって性能差が顕著に出ているので、SQL Server からの負荷がけでも同様なトレンドは取れると思うのですが、この辺は調査が必要ですね。
現在の Azure の課金は分単位課金で、仮想マシンはシャットダウンしている状態では課金が発生しないので不要な時はシャットダウンしておくと課金を抑えられます。
シャットダウンした場合、起動後に NIC のゴーストデバイスがどんどん増えていきますのでこの辺が気になる場合は、Windows 2000 に現在存在しないデバイスがデバイス マネージャーに表示されない を参考に削除するとよいかと思います。
この資料を作るためにシャットダウンと起動を繰り返していたら 22 個ぐらいはゴーストデバイスができていたので…。
また、リストアのような時間がかかる処理に関しては A7 ではなく XL にサイズを変更してリストアをすることでリストア中の課金を抑えることもできます。
和牛をおいしく食べるための研究はもう少ししないといけないですね。