バッファープール拡張

適用対象:SQL Server

SQL Server 2014 (12.x)で導入されたバッファープール拡張は、不揮発性ランダムアクセスメモリ (ソリッドステートドライブ) 拡張としてのデータベースエンジンバッファープールへのシームレスな統合を実現することで、I/O スループットを大幅に向上させます。バッファープール拡張機能は、すべての SQL Server エディションで使用できるわけではありません。詳しくは、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。

バッファープール拡張機能の利点

SQL Server データベースの主な目的はデータの格納と取得であるため、データベースエンジンの主要な特性は頻繁なディスク I/O ということになります。ディスク I/O 操作は多くのリソースを消費するうえ、完了するのに比較的長い時間がかかるため、 SQL Server では I/O の効率を上げることに重点を置いています。バッファープールは、 SQL Serverのプライマリメモリの割り当て元となります。バッファー管理は、この効率向上を実現するための重要なコンポーネントです。バッファー管理コンポーネントは 2 つのメカニズムから構成されています。1 つはデータベースページに対するアクセスと更新を行うバッファーマネージャーで、もう 1 つはデータベースファイルの I/O 数を削減するためのバッファープールです。

データページとインデックスページがディスクからバッファープールに読み込まれ、変更されたページ (ダーティページとも呼ばれます) がディスクに書き戻されます。サーバーチェックポイントおよびデータベースチェックポイントでメモリ不足が発生すると、バッファーキャッシュ内のホットな (アクティブな) ダーティページがキャッシュから削除され、機械式ディスクに書き込まれた後、再度キャッシュに読み込まれます。これらの I/O 操作は、通常、4 KB から 16 KB のデータの順序で、ランダムな読み取りと書き込みを小さくします。小規模なランダム I/O パターンの場合、頻繁なシークが発生して機械式ディスクのアームが動き続けるため、I/O 待機時間が長くなり、システムの総 I/O スループットが低下します。

このような I/O ボトルネックを解決するための一般的な方法は、DRAM を増設するか、または高パフォーマンス SAS スピンドルを追加する方法です。これらのオプションは役に立ちますが、大きな欠点があります。DRAM はデータストレージドライブよりもコストが高く、スピンドルを追加すると、ハードウェアの取得に伴う設備投資が増加し、消費電力の増加とコンポーネントの故障の確率の増加によって運用コストが増加します。

バッファープール拡張機能は、不揮発性ストレージ (通常は SSD) でバッファープールキャッシュを拡張します。この拡張により、より大きなデータベースのワーキングセットをバッファープールに格納でき、その結果、RAM と SSD の間の I/O のページングが強制的に実行されます。これによって、小規模なランダム I/O の処理が実質的に機械式ディスクから SSD に移行されます。 SSD は待機時間が短くランダム I/O のパフォーマンスに優れているため、バッファープール拡張によって I/O スループットが大幅に向上します。

バッファープール拡張機能の利点を次の一覧に示します。

ランダム I/O のスループットの向上
I/O 待機時間の削減
トランザクションのスループットの向上
より大きなハイブリッドバッファープールによる読み取りパフォーマンスの向上
現在および将来の低コストのメモリドライブを使用できるキャッシュアーキテクチャ

概念

バッファープール拡張機能に関連する用語を次に示します。

任期	説明
ソリッドステートドライブ (SSD)	ソリッドステートドライブは、データをメモリ (RAM) に永続的に格納します。詳細については、 Wikipedia の定義を参照してください。
バッファ	SQL Server では、バッファーはメモリ内の 8 KB のページであり、データページまたはインデックスページと同じサイズです。したがって、バッファーキャッシュは 8 KB 単位のページに分割されます。バッファーマネージャーが別のデータを読み取るためのバッファー領域を必要とするまで、そのページはバッファーキャッシュ内に残ります。データは、変更された場合にのみディスクに書き戻されます。これらのメモリ内の修正されたページは、"ダーティページ" と呼ばれます。ディスク上のデータベースイメージと同等の場合、ページはクリーンです。バッファーキャッシュ内のデータは、ディスクに書き戻す前に何度でも変更できます。
バッファープール	バッファーキャッシュとも呼ばれます。バッファープールは、キャッシュされたデータページを利用するためにすべてのデータベースで共有されるグローバルリソースです。バッファープールキャッシュの最大サイズと最小サイズは、起動時、または SQL Server のインスタンスが sp_configureを使用して動的に再構成されるときに決定されます。このサイズにより、実行中のインスタンスで任意のときにバッファープールにキャッシュできる最大ページ数が決まります。バッファープール拡張機能によってコミットできる最大メモリは、マシン上で実行されている他のアプリケーションによって制限される可能性があります。これらのアプリケーションで大量のメモリ負荷が発生した場合に備えます。
Checkpoint	チェックポイントによって、予期しないシャットダウンやクラッシュの後の復旧中に、トランザクションログに格納されている変更をデータベースエンジンが適用するための最適なポイントが作成されます。チェックポイントは、変更されたページとトランザクションログ情報をメモリからディスクに書き込み、さらにトランザクションログに関する情報を記録します。詳細については、「Database Checkpoints (SQL Server)」 (データベースチェックポイント (SQL Server)) をご覧ください。

詳細

SSD ストレージは、ディスクストレージサブシステムではなく、メモリサブシステムの拡張として使用されます。つまり、バッファープール拡張ファイルによって、バッファープールマネージャーが DRAM と NAND フラッシュメモリの両方を使用し、SSD を使用した不揮発性ランダムアクセスメモリ上に "微温" ページ用のはるかに大きなバッファープールを保持できるようになります。これにより、DRAM としてのレベル 1 (L1) と SSD 上のバッファープール拡張ファイルとしてのレベル 2 (L2) から成る複数レベルのキャッシュ階層が作成されます。データの安全性を維持するため、L2 キャッシュにはクリーンなページのみが書き込まれます。バッファーマネージャーは、L1 キャッシュと L2 キャッシュの間のクリーンなページの移動を処理します。

次の図は、バッファープールのアーキテクチャを他の SQL Server コンポーネントに関連して示した概要図です。

SSD バッファープール拡張機能アーキテクチャの図。

有効な場合、バッファープール拡張は、SSD 上のバッファープールキャッシュファイルのサイズおよびファイルパスを指定します。このファイルは SSD 上のストレージの連続的なエクステントで、 SQL Serverインスタンスの起動時に静的に構成されます。ファイルの構成パラメーターの変更は、バッファープール拡張機能が無効になっている場合にのみ実行できます。バッファープール拡張を無効にすると、すべての関連する構成設定がレジストリから削除されます。バッファープール拡張ファイルは、SQL Server インスタンスがシャットダウンされると削除されます。

容量の制限

SQL Server Enterprise エディションでは、バッファープール拡張機能の最大サイズは、 max server memory (MB)の値の 32 倍になります。

SQL Server Standard エディションでは、 max server memory (MB)の値の 4 倍のバッファープール拡張機能の最大サイズを使用できます。

ベストプラクティス

次のベストプラクティスに従うことをお勧めします。

バッファープール拡張機能を初めて有効にした後は、SQL Server インスタンスを再起動して、パフォーマンスの最大の利点を得る必要があります。
物理メモリのサイズ (max server memory (MB)) とバッファープール拡張機能のサイズの比率が 1:16 以下になるように、バッファープール拡張機能を設定します。 1:4 から 1:8 の範囲の低い比率が最適な場合があります。 max server memory (MB) オプションの設定については、「サーバーメモリ構成オプション」を参照してください。
運用環境で実装する前にバッファープール拡張を徹底的にテストします。運用環境に入ったら、ファイルに構成を変更したり、機能をオフにしたりしないでください。これらのアクティビティは、機能を無効にするとバッファープールのサイズが大幅に小さくなるため、サーバーのパフォーマンスに悪影響を及ぼす可能性があります。無効にすると、機能をサポートするために使用されるメモリは、SQL Server のインスタンスが再起動されるまで再利用されません。ただし、機能が再び有効になっている場合は、インスタンスを再起動せずにメモリが再利用されます。