RAMディスク上のSQL Server tempdb?


11

弊社のベンダーアプリケーションデータベースは非常にTempDBを集中的に使用しています。

サーバーは、SQL 2012 Enterprise SP3を実行する40コアおよび768GB RAMの仮想(VMWare)です。

TempDBを含むすべてのデータベースは、SANのTier 1 SSDにあります。tempdbデータファイルは10個あり、それぞれ1GBに事前に拡張されており、自動拡張されることはありません。70 GBのログファイルと同じです。トレースフラグ1117および1118は既に設定されています。

sys.dm_io_virtual_file_statsは、tempdbのデータとログファイルで過去1か月に50テラバイトを超えて読み書きされ、累積io_stallが250時間または10日であることを示しています。

過去2年間、ベンダーのコードとSPはすでに調整されています。

現在、大量のメモリがあるため、tempdbファイルをRAMドライブに配置することを考えています。tempdbはサーバーの再起動時に破壊/再作成されるため、サーバーの再起動時にフラッシュされる揮発性メモリに配置するのが理想的です。

低い環境でこれをテストしましたが、CPUが遅いtempdbドライブで待機するのではなく、より多くの作業を行っているため、クエリ時間は短縮されましたが、CPU使用率が増加しました。

他の誰かが、高oltp本番システムのtempdbをRAMに配置しましたか?大きな欠点はありますか?具体的に選択または回避するベンダーはありますか?


多分あなたはベンダーがtempDBを使いすぎていますか?
パパラッツォ2017年

@Max、その質問は、tempdbがディスクに書き込むかどうかという問題の一部にのみ回答します。tempdbから読み取らない
d -_- b

1
SANレベルでSSDを使用しても、ネットワーク遅延のため、実際にはそれほどメリットはありません。NVMe SSDをSQL Serverに入れて、tempdbを実行します。
Max Vernon

私は「nvme ssd vs ramdisk」をググっただけで、最初の結果はredditの投稿で、後者は〜3倍速いと主張しています。また、データセンターまで運転してブレードにインストールするよりも簡単です:)
d -_- b

2
Microsoftは、一部のクラスターでPCI-E FusionIOカードを使用しています(使用するローカルディスクでtempdbを引き続き使用できるようにする、マイナーな回避策があります)。Maxが指摘したPCI-Eインターフェイスはかなり高速です。1秒あたりのCPU割り込みを測定して、1秒あたりのリクエスト数が多いかどうかを測定します。ディスクレイテンシは割り込み要求が少ない主な原因の1つであるため(SQL時間ではありません)。
Ali Razeghi 2017年

回答:


7

まず、パッチを適用します。2012Service Pack 1累積更新プログラム10以降を使用していることを確認してください。SQL 2014では、MicrosoftがするのTempDBを変更し、ディスクへの書き込みにはあまり熱心で、彼らは上空2012 SP1 CU10にそれをバックポートするので、それはTempDBの書き込み多くの圧力を軽減することができます。

次に、レイテンシの正確な数値を取得します。sys.dm_io_virtual_file_statsをチェックして、TempDBファイルの平均書き込みストールを確認します。これを行う私のお気に入りの方法は次のいずれかです。

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

ファイルの統計セクションを見て、物理的な書き込みに焦点を当てます。sinceStartupデータにはCHECKDBが実行されている時間も含まれるため、少し誤解を招く可能性があり、TempDBを実際に破壊する可能性があります。

平均書き込みレイテンシが3ミリ秒を超える場合、はい、SANにソリッドステートストレージがある可能性がありますが、それでも高速ではありません。

TempDBのローカルSSDを最初に検討します。適切なローカルSSD(IntelのPCIe NVMeカードのように、特にここで説明するサイズで$ 2k USD未満)のレイテンシは非常に低く、共有ストレージで実現できるよりも低くなっています。ただし、仮想化では、これには欠点が伴います。あるホストから別のホストにゲストをvMotionして、負荷またはハードウェアの問題に対応することはできません。

最後にRAMドライブを検討してください。このアプローチには2つの大きな落とし穴があります。

まず、TempDBの書き込みアクティビティが実際に多い場合、メモリの変更率が非常に高いため、だれもが気づかずにゲストをホスト間でvMotionすることができません。vMotion中に、RAMの内容を1つのホストから別のホストにコピーする必要があります。それがvMotionネットワーク経由でコピーするよりも速く、本当に速く変化している場合は、問題が発生する可能性があります(特に、このボックスがミラーリング、AG、またはフェールオーバークラスターに関係している場合)。

次に、RAMドライブはソフトウェアです。私が行った負荷テストでは、TempDBアクティビティが非常に重い場合の速度に感銘を受けたことはありません。エンタープライズグレードのSSDが追いつかないほど重い場合は、RAMドライブソフトウェアにも負担がかかります。実際に稼働させる前に、これを大幅に負荷テストする必要があります-さまざまなインデックスで多数の同時インデックス再構築などを試し、すべてsort-in-tempdbを使用します。


1

RAMドライブの作成は簡単です。多くの起動可能なLinuxサムドライブとオプティカルドライブは、RAMドライブを作成し、そこにOSファイルを保存します。その後、ルートファイルシステムはメモリ内にあります。Windowsでは、昔は、RAMドライブがデバイスドライバーとしてconfig.sysに読み込まれていました。通常、ドライバはハイメモリにロードされました。私の意見では、これは非常に優れたシンプルなソリューションです。RAMドライブを使用してソリューションを作成した場合は、それについてお聞きしたいと思います。同様のことをしたいのですが、永続的なストレージに書き込みを行い、データベースをRAMに保存したいと思います。私の場合、OSが使用できるよりも多くのRAMをインストールできるマシンがあります。OSが読み込まれる前にRAMディスクを作成すると、OSが他の方法では認識できないRAMを利用できるようになります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.