自宅の Hyper-V の管理には SCVMM 2012 RC を使用しています。
気づいたら SCVMM のデータベースのサイズが 700MB を超えていたので、これはいかんと思いデータベースをメンテナンスしてみました。
SCVMM のような製品で自動作成してくれるデータベースをどこまで触っていいのかはわかりませんので自己責任で作業をしています。
データベースのサイズを縮小したところ、今までバーチャルマシンの作成ウィザードでホストの選択で操作できるようになるまでに時間がかかっていたのですがかなりスムーズに画面が表示されるようになりました。
# 因果関係は調べていないのでたまたまかもしれませんが。
Contents
■SQL Server のサービスアカウントと最大メモリの設定
SQL Server と SCVMM を同居させており、ローカルシステムで SQL Server を起動している場合に設定を考えた方が良い点になります。
# Users グループのユーザーの場合は、後述のAWE API はデフォルトで権限が付与されていないため、ワーキングセットのトリミングで回避できるかもしれません。
SQL Server をローカルシステムの権限で稼働させている場合、[SeLockMemoryPrivilege] の権限が付与されています。 
これは、[メモリ内のページのロック] の権限となります。 
この権限が付与されている場合、AWE API が使用されて SQL Server のメモリが確保されますので他のプロセスでメモリが必要になった場合でも SQL Server で確保しているメモリがページングアウトされません。
# ワーキングセットのトリミング (他のプロセスのメモリ要求によって SQL Server で取得しているメモリを開放する) が発生しない状態となります。
SQL Server のメモリ管理 – Part 3
64 ビット バージョンの SQL Server でのバッファー プール メモリのページングを削減する方法
SQL Server のインストール直後の状態では max server memory の上限は最大まで設定されているため、SQL Server に割り当てが許可されているメモリは広大な値となっています。 
x64 の SQL Server の場合は、[AWE を使用してメモリを割り当てる] が有効になっていなくても、メモリ内のページのロックの権限が付与されている場合は AWE API が使用されます。SQL Server のログを見ると [Using locked pages for buffer pool] が出力されていることから確認できます。 
そのため、SQL Server が次々にメモリを確保すると他のプロセスで使用できるメモリが足りなくなる可能性があります。
# AWE API が使用されている場合、メモリが足りなくなったときにワーキングセットのトリミングが発生しないので SQL Server で確保している物理メモリの解放が行われません。
SCVMM と SQL Server を同居させる場合は、他のプロセスで使用可能なメモリを確保するために max server memory を明示的に指定し、SQL Server で使用可能なメモリの上限を設定しておいた方が良いかと思います。
SCVMM のデータベースにはデフォルトで 90 日間のジョブの履歴が格納されますの SQL Server がログの情報をキャッシュした場合、かなりのメモリサイズになると思いますので。
■データベースの自動拡張サイズ
SCVMM のデータベースの自動拡張のサイズですが、デフォルトでは以下の設定になっています。 
データファイルの拡張が [1MB] 単位、ログファイルの拡張が [10%] 単位となっています。
データファイルの拡張が 1MB 単位ということはかなり頻繁にデータファイルの拡張が行われているということになります。
データファイルの拡張が発生している最中は、拡張が終了するまでデータの書き込みができませんので処理が瞬間的に中断することになります。
これはかなり効率が悪いですよね。
ログファイルの拡張は 10% 単位となっていますが、初期のログファイルのサイズは小さいので最初のうちは頻繁にファイルの拡張が発生することになります。
また、ログファイルは拡張時に拡張した分に対して内部的に複数の仮想ログファイルに分割されます。仮想ログファイルの個数が多いと管理オーバーヘッドが高くなったりもします。
これも効率は悪そうですよね。
ということでデータファイルとログファイルの拡張サイズは適切なサイズを手動で設定するように変更しています。
ローカルシステムアカウントで SQL Server を起動している場合は [SeManageVolumePrivilege] (ボリュームの保守タスクを実行) が付与されているのでファイルの瞬時初期化が使用でき、データファイル拡張時の時間を短縮することができるのですが、Administrators グループに所属していないユーザーで SQL Server を起動している場合は、この権限を明示的に付与しないと瞬時初期化は使えませんので、設定を検討したほうが良いかもしれません。
データベース ファイルの初期化 
■データ / インデックスの圧縮
SQL Server の Enterprise Edition を使用している場合にしか設定できませんが。Enterprise Edition を使用している場合はデータの圧縮をすることができます。
私の使用している環境では、テーブルのサイズは以下のようになっています。
# Management Studio のレポートを使用して表示しています。 
履歴系のテーブルのデータサイズが大きいようですね。
テーブルのサイズが大きい、[dbo.tbl_PCMT_PerfHistory_Raw] では 175 MB 程のデータが格納されています。
このテーブルを SQL Server の圧縮機能を使用して圧縮してみたいと思います。 
今回はテーブル (クラスター化インデックス) と非クラスター化インデックスをページ圧縮で圧縮してみました。
圧縮後のサイズがこちらになります。 
圧縮前は 175 MB だったものが、50 MB まで圧縮されています。
CPU 使用率とのトレードオフになりますが、圧縮をすることでデータサイズが減り、メモリ上で使用される領域も減りますのでメモリの負荷低減につながります。
# ディスクから読み取るデータのサイズも減りますのでディスク負荷の低減にもつながります。
トップ 10 テーブルぐらいを圧縮してみるとメモリの使用量を減らすことができるかもしれないですね。
ジョブの実行履歴保存期間を減らすことでデータのサイズを減らすこともできますのでこちらも検討ですね。
# 最短で 20 時間以内のデータのみ保存する用に指定できそうですので。
■データベースチューニングアドバイザで作られたインデックスは必要??
削除してよいのかどうか、かなり微妙なのですが、SCVMM のデータベースには SQL Server のデータベースチューニングアドバイザ (DTA) により、アドバイスされたインデックスがいくつか残っています。
|
USE [VirtualManagerDB] |
RTM になったら削除されている or 名称が変わっているといいのですけどね。
必要だから設定しているのか、削除し忘れなのかが DTA の標準の名称だと判断がしづらいですよね。
# インデックスの使用状況を見ればいいのですがそこまではやっていません。
不要なインデックスは更新コストを上げるだけですので。
■バックアップ圧縮
SCVMM の管理コンソールから SQL Server のデータベースのバックアップを取得することが可能です。 
この時に実行されるクエリですが以下のようなクエリとなっています。
| exec sp_executesql N’BACKUP DATABASE @DatabaseName TO DISK = @BackupFile’,N’@DatabaseName nvarchar(16),@BackupFile nvarchar(44)’,@DatabaseName=N’VirtualManagerDB’,@BackupFile=N’C:tempVirtualManagerDB-10092011-054820.bak’ |
BACKUP DATABASE を使用して単純なクエリが実行されていますね。
SQL Server 2008 R2 以降は Standard Edition を使用していてもバックアップ圧縮が可能になっています。
SCVMM のバックアップ機能ではバックアップ圧縮の制御ができませんので、SQL Server のインスタンスレベルでバックアップ圧縮の使用をデフォルトで有効にしておくことで、SCVMM の管理コンソールからバックアップを実行した際に圧縮した状態にすることが可能です。
インスタンスレベルでバックアップ圧縮をしたい場合は、SQL Server で以下のクエリを実行しておきます。
|
sp_configure ‘backup compression default’, 1 |
上記のような設定+α を使用している検証環境で実施しているのですが、今のところは快調に動作しています。