SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server 2019 の新機能の ハイブリッドバッファープールを試してみる

leave a comment

SQL Server 2019 では新機能として、ハイブリッド バッファー プール (Hybrid Buffer Pool) という機能が新しく追加されます。

ドキュメントベースではなんとなく動作を理解できていたのですが、実際の動作を確認できていなかったので、軽くではありますが動作を試してみました。

SQL Server は、ハードウェアの進化に合わせて、高速なストレージを有効に活用するための機能が追加されています。

SQL Server 2012 では、フェールオーバークラスターインスタンス (FCI / AlwaysOn FCI) で、tempdb については、各ノードのローカルディスク上に配置ができるようになりました。

通常、FCI はデータベースについては、両ノードから参照ができる共有ディスク / 共有フォルダ上に配置する必要があるのですが、SQL Server 2012 以降は、tempdb については、この制約が外れました。

これにより、クラスター環境でも、各ノードのローカルディスクとしてサーバーに直結されている SAS/SATA の SSD や、NVMe の SSD といった高性能なディスク上に tempdb を配置することが可能となりました。

image

 

SQL Server 2016 SP1 になると NVDIMM の活用が新たに加わりました。

「Tail of Log Caching」(ログ末尾のキャッシング) と呼ばれる機能が追加されました。

通常の変更では、トランザクションをコミットしたタイミングで、メモリ上のログバッファの内容をトランザクションログファイルに書き出し、永続化を行う必要があります。

image

SQL Serer 2014 で遅延持続性 (Delay Durability) という設定が追加され、コミット処理実行時にトランザクションログファイルへの書き込み完了を待たずに、クライアントに処理完了を返すというようなオプションが追加されました。
(WRITELOG の待ち事象の完了を待たずに、トランザクションを完了させる)

image

遅延持続性は、トランザクションログファイルの書き込みが完了しなくても、処理を完了とみなすためトランザクションの永続性と引き換えにログ書き込みの性能を向上させるような手法となっていました。

Tail of Log Caching は遅延持続性の永続性に対しても問題を解消しながら、トランザクションログの書き込みを高速に実施する手法となります。

通常はコミットを行ったタイミングでトランザクションログファイルに書き込み、トランザクションを永続化します。

Tail of Log Caching については、ログバッファは、メモリではなく NVDIMM (Storage Class Memory : SCM) 上に確保するような動作になります。

NVDIMM は不揮発性メモリとなりますので、メモリと同じ、DIMM のスロットに搭載し高速な I/O を実現しながら永続性のある書き込みを保証するストレージとなります。
(予期せぬシャットダウンに備えてバッテリーが必要となりますが)

この特性を活かし、ログバッファを NVDIMM 上に確保し、コミット時にトランザクションログファイルにフラッシュするのではなく、いくつかのコミットをまとめてフラッシュするというような動作を行うことで、トランザクションログの書き込みの応答を効率化させるという手法となります。
(クライアントから見た場合はログバッファにコミットレコードが書き込めた段階で処理が完了)

image

 

SQL Server 2019 では NVDIMM の活用方法が 2 つ増えます。

今回は触れていませんが、Enlightenment Mode によるファイルシステムとストレージスタックをバイパスした、NVDIMM 上のデータベースのファイル書き込みが一つ目の追加された機能となります。

この機能については、CTP 2.2 時点では、SQL Server 2019 on Linux のみとなっており、SQL Server 2019 on Windows ではサポートが行われていないようです。
(Enlightment Mode によるアクセスがサポートされていないだけで、NVDIMM 上にデータベースを配置することは Windows でも可能です)

For this preview release, enlightenment of files on persistent memory devices is only available on Linux. SQL Server on Windows supports persistent memory devices starting with SQL Server 2016 (13.x).

もう一つの機能追加が、本投稿で試した ハイブリッド バッファー プールとなります。
この機能は CTP 2.2 時点でも、SQL Server 2019 on Windows / SQL Server 2019 on Linux の両方で使用することができます。

ハイブリッド バッファー プールは NVDIMM をバッファー プールとして活用するものになります。
バッファー プールとして、外部のストレージを活用するというと、SQL Server 2016 で追加されたバッファー プール拡張 (Buffer Pool Extension) を思い浮かべる方がいらっしゃるかもしれませんが、それとは異なるアプローチです。

ハイブリッド バッファー プールは、NVDIMM の高速なアクセス性能を活かし、「NVDIMM 上に格納しているクリーンなデータについては、メモリ上のバッファプールに配置することなくアクセスを行う」というテクノロジーとなっています。
(NVDIMM 上のデータに変更が発生した場合 (ダーティーなページとなった場合) は、メモリ上にデータを配置し、クリーンなデータについては、NVIDMM 上に配置したままとするテクノロジです)

ハイブリッドバッファー プールを使用しない、通常の動作で、データの読み取りが発生した場合を考えてみます。

データファイル上に存在しているデータに対してのアクセスが行われると該当のページをメモリ上に配置し、キャッシュアウトされるまでは、メモリ上のデータが読み込まれることになります。

image

通常の動作でデータにアクセスを行った場合、メモリの使用状況は次のようになります。

今回は NVDIMM 上に配置された 2GB 程度のデータに対してアクセスを実施しているのですが、「Data Base Cache Memory (KB)」が 2GB 程度となっており、「Total Server Memory (KB)」も類似の値となっています。
image

このことから、「データが SQL Server で確保されているメモリ上にキャッシュされており、キャッシュに SQL Server の物理メモリが使用されている」ということが確認できます。

それでは、ハイブリッド バッファー プールを有効にするとどうなるでしょうか。
同じデータにアクセスした結果が以下となります。

image

「Data Base Cache Memory (KB)」は先ほどと同様に、 2GB 程度となっているのですが、「Total Server Memory (KB)」については、380 MB 程度となっており、「SQL Server が確保しているメモリサイズ」が先ほどとな大幅に異なっていることが確認できます。

このことから「データをキャッシュしたという扱いになっているが、キャッシュ領域は SQL Server の物理メモリを使用していない」ということが確認できます。

image

これがハイブリッド バッファー プールの基本的な動作となります。

NVDIMM を DAX (Direct Access) モードで使用する必要がある構成となりますが、この場合、NVDIMM 上のデータには高速にアクセス可能となります。

NVDIMM は DIMM スロットに装着する必要がありますので、SCM を搭載した場合は、物理メモリで利用可能な DIMM スロットとのトレードオフになるのではないでしょうか。
そのため、高速な NVDIMM と物理メモリ上の二か所にデータが保持されるのは、効率的ではないと考えられます。
これを解消し、クリーンなページについては、NVDIMM 上でキャッシュしている扱いとさせることがこの機能の基本的な考え方ではないでしょうか。

「クリーンなページ」のみ、NVDIMM から直接アクセスされますので、更新されたデータについては、メモリ上にキャッシュされることなります。

先ほどの 2GB のデータに対して UPDATE をかけてみます。
そうすると次のように、Total Server Memory が上昇していますので、物理メモリ上で処理が行われたことが確認できます。

image

CHECKPOINT (ダーティーなページをフラッシュ) → 再度全件検索を行った場合は次のようになり、NVDIMM 上のクリーンなデータがキャッシュされていることが確認できます。
image

UPDATE を実行した際の Database Cache Memory の動作がきちんと把握できていないのですが、Database Cache Memory (KB) と、Total Server Memory (KB) の情報を利用することで、「どの場所にあるデータをキャッシュ済みデータとして取り扱っているか」が確認できるのではないでしょうか。

現時点では、 sys.dm_os_buffer_descriptors からはデータのキャッシュが物理メモリなのか NVDIMM なのかという判断が一目でできる項目はなさそうなのですが、今後、ハイブリッド バッファー プールの情報を取得するような DMV 等が出てくると調査がはかどりそうですね。
(buffer_descriptors の is_modified である程度の推測はできるのかもしれませんが)

ハイブリッド バッファー プール上のデータベースのテーブルについては、In-Memory OLTP ではなく、行ストアの状態でも、高速にアクセスが行えますので汎用的な高速化手法として利用できる可能性があるのではないでしょうか。

Written by masayuki.ozawa

2月 21st, 2019 at 11:52 pm

Posted in SQL Server

Tagged with ,

Leave a Reply

*