インスタントファイル初期化：セットアップ中の影響

最近、Erin Stellato（@erinstellato）が、データベースの作成または復元時にインスタントファイル初期化（IFI）がパフォーマンスに与える影響についてブログに書いています。彼女は、SQL Server 2016のセットアップにより、インストール中にSQL Serverサービスに適切な権限を付与できるようになったと説明しています（これについては、SQL Server2016の最新ビルドのCTP3.0セクションでも説明しました）：

これで、SQLServerのセットアップ中にファイルの即時初期化を有効にできます

キーは新しいオプションです（構成ファイルでも指定できます）：

gpeditに移動し、権限を正しく割り当て、サービスを再起動することを忘れずに、後でデータベースを作成または復元するのにかかる時間を大幅に短縮できるのは素晴らしいことです。しかし、私にとってはるかに大きな利点は、セットアップ中にIFIを早期に利用して、より大きなtempdbファイルを構成できることです。

現在、セットアップ中にいくつかの制限があります。たとえば、tempdbファイルの数は8（またはコアの数のいずれか少ない方）に制限されており、各ファイルのサイズは最大1,024MBにしか達しません。これらの制限はUIで適用されており、無人インストールの構成ファイルでより大きなサイズを指定することで回避できる可能性があると思いましたが、それも機能しませんでした。 （ログによると、「TempDBファイルサイズの値8192は1024 MBを超えており、インストール時間に影響を与える可能性があります。小さいサイズに設定して、インストール後に変更できます。」）個人的には、この日は時代を経て、取得できるストレージの速度とサイズにより、データファイルサイズの1GBの上限は人為的に低くなっています。そこで、Connectの提案を提出しました：

• 接続＃2457759：tempdbデータファイルは1024MBに制限しないでください

そして、CTPサイクルの早い段階で、制限が実際には1GBではなく256MBとして適用されたときに、Brent Ozar（@BrentO）が同様のアイテムを提出したことが指摘されました。

• 接続＃1841076：TempDBセットアップの初期サイズが小さすぎます

64 x 1 GBのファイルをサポートできるモンスターマシンがなく、それも現実的なテストではないため、それぞれ1GBの8つのtempdbデータファイルに対するIFIの影響をテストすることにしました。私は一種の古い学校なので、4つの異なる.iniファイルを作成し、テストごとに変更する行を強調表示しました（IFIとそうではなく、8 x 1,024 MBのファイルと比較します）。これらのループを複数回実行するため、IFIが有効になっているかどうかに応じて異なるインスタンス名を使用することが重要でした。サービスアカウントに権限を付与すると、インスタンスを削除するだけでは削除されないためです。 （そして、これらのアカウントを個別に設定することもできましたが、これらのテストを簡単に再現できるようにしたかったのです）。

これが私が使用したバッチファイル（構成ファイルと同じフォルダーに配置）で、各組み合わせを使用してインスタンスを3回インストールしてからアンインストールし、セットアップ時間をテキストファイルに記録しました。アンインストールとクリーンアップは無視します。

いくつかの注意事項：

• D:\setup.exeから2行を変更する必要がある場合があります セットアップディレクトリへのパス。
• これを実行する前に、システムを再起動する必要がある場合があります。
• UACがすべての反復で中断しないように、昇格したコマンドプロンプトからバッチファイルを実行することをお勧めします。

3つの異なるシステムでテストを実行しました：

• 4コアとSSDストレージを備えたWindows10VM
  4 x 8MB、次に4 x1,024MBのベースラインテスト
• 8コアとPCIeストレージを備えたWindows10VM
  4 x 8 MB、4 x 1,024 MB、8 x1,024MBのベースラインテスト
• 16コアのWindows2012R2VMと8台の10KSASドライブのデュアルチャネルRAID10アレイ
  4 x 8 MB、4 x 1,024 MB、8 x 1,024 MB、および16 x1,024MBのベースラインテスト

出力ファイルは、ここに貼り付けることができる一連の挿入ステートメントを生成しました：

CREATE TABLE #x
(
  [server] varchar(32),
  [test]   varchar(32),
  [start]  time(2),
  [end]    time(2)
);
 
-- inserts pasted here
 
SELECT [server],[test],AVG(DATEDIFF(SECOND,[start],[end])*1.0)
FROM #x
GROUP BY [server],[test];

平均化および丸められた、それぞれ10回のテストのタイミングは次のとおりです（クリックして拡大）：

予想通り、低速ドライブ上の大きなファイルではIFIが重要になります

セットアップには、全体的に1分強かかります（管理ツールなしでセットアップを実行するのは素晴らしいことです）。唯一の逸脱は、実際には、ファイルサイズが機械式ドライブで大きくなり始め、ファイルの即時初期化が無効になっている場合でした。これにショックを受けたふりをすることはできません。

結論

SSDまたはPCIeを使用している場合、ファイルの即時初期化によって状況が悪化することはありませんが、tempdbデータファイルの古風なファイルサイズの制限が損なわれていない限り、セットアップ中に明確なメリットはありません。現在のルールでは、この影響を（1 GB x使用可能なコアの数）を超えてテストすることは不可能のようです。ただし、低速のメカニカルドライブを使用している場合は、8GBまたは16GBのデータのみを初期化する場合でも、顕著な違いがあります。ディスクヘッドを移動する必要がある場合、ゼロ化にはかなりのコストがかかります。とはいえ、セットアップに75秒かかるか2分かかるかは、大規模な計画ではかなり重要ではありません（数百台のサーバーをインストールしているが、何らかの理由で自動化していない場合を除く）。したがって、ここでの大きな利点は利便性であり、インストールが成功した後、サービスアカウントに必要なボリューム権限を付与することを忘れないでください。考えてみれば、この新しい構成オプションは、実際のインストール中に節約された時間以外に、多数のサーバーの自動インストールで実際にはるかに効果を発揮する可能性があります。

• 構成ファイルとバッチファイルをダウンロードします

（次のテストでは、既存のtempdbファイルをインストール後に1,024MBよりもはるかに大きいサイズに拡張するのにかかる時間を調べます。 。）