sql-server - 遅い - sqlserver 高速 化 設定




SQL Serverの適切なWindows O/Sページファイルサイズ (6)

SQL Serverを実行しているWindows 2003サーバーの適切なページファイルサイズを把握している人はいますか?


高性能を求めているなら、ページングを完全に避けたいので、ページファイルのサイズはそれほど重要ではありません。 DBサーバーに可能な限り多くのRAMに投資します。


アプリケーションのワーキングセットのサイズの方が大きいほど、戻り値が小さくなるようになります。 キャッシュのヒット率が大幅に変化するまで、サイズを徐々に増減させることで、これを見つけることができます。 ただし、キャッシュのヒット率が90%を超える場合は、おそらくOKです。 一般的には、RAMの割り当てを超えていないことを確認するために、実動システムでこれを監視する必要があります。


RAMのサイズに関係なく、物理RAMの1.5倍以上のページファイルが必要です。 これは、1 TBのRAMマシンを持っていても、ディスクに1.5 TBのページファイルが必要です(狂った音ですが、本当です)。

プロセスがVirtualAlloc / VirtualAllocEx経由でMEM_COMMITメモリを要求するとき、要求されたサイズはページファイルに予約されている必要があります。 これは、最初のWindows NTシステムでは当てはまりましたが、今日でも、Win32での仮想メモリの管理を参照してください。

メモリがコミットされると、メモリの物理ページが割り当てられ、ページファイルにスペースが確保されます。

いくつかの非常に奇妙なケースを除いて、SQL Serverは常にMEM_COMMITページを要求します。 また、SQLは、できるだけ多くのバッファプールを予約しておく(VASで予約しコミットする) 動的メモリ管理ポリシーを使用しているため、SQL Serverは起動時にページファイル内のスペースの膨大な予約を要求します。 ページ・ファイルのサイズが適切でないと、エラー801/802がSQLのERRORLOGファイルおよび操作で表示されます。

これは、管理者が大きなRAMがページファイルの必要性を排除すると誤って想定しているため、常に混乱を招く。 実際には逆に、大きなRAMはページファイルの必要性を増やします。なぜなら、Windows NTメモリマネージャーの内部的な働きがあるからです。 予約されたページファイルは、うまくいけば使用されていません。


Remus(私が大いに尊敬する人物)に対するすべての敬意をもって、私は強く反対します。 ページ・ファイルがフル・ダンプをサポートするのに十分な大きさであれば、毎回フル・ダンプを実行します。 非常に大量のRAMを使用している場合は、小さな瞬間が大きな停電となる可能性があります。

1回の一時的な問題がある場合は、サーバに1 TBのRAMをディスクに書き込まなくてはなりません。 繰り返し発生する問題がある場合は、ページ・ファイルを増やしてフル・ダンプを取り込むことができます。 あなたが完全なダンプを取得するようにPSS(または完全なダンプを分析する資格のある他の人)からisntructedされるまで、これを行うのを待つでしょう。 ごくわずかのDBAが完全ダンプを分析する方法を知っています。 とにかくポップアップするほとんどの問題のトラブルシューティングにはミニダンプが十分です。

さらに、サーバーが1 TBのフルダンプを許可するように構成されていて、定期的な問題が発生した場合、空きディスク容量はどれくらいありますか? あなたは1週間のうちにSAN全体をいっぱいにすることができます。

ページファイル1.5 * RAMは、3または4 GBのRAMを搭載したSQL Serverを使用していて幸運だった頃の標準です。 これはもはや事実ではありません。 ページのファイルをWindowsの既定のサイズとすべての運用サーバーの設定にします(ただし、メモリ負荷が発生しているSSASサーバーを除く)。

わかりやすくするために、私は2GBのRAMから2TBのRAMまでのサーバーで作業しました。 11年以上経過した後、私は1回だけフル・ダンプをキャプチャするためにページング・ファイルを増分しなければなりませんでした。


マイクロソフト社によると、「コンピュータのRAM量が増えるにつれて、ページファイルの必要性が減る」 その後、パフォーマンスログを使用して実際に使用されているページファイルの量を判断する方法について説明します。 ページファイルを最初に1.5Xのシステムメモリに設定してから、推奨される監視を行い、調整してください。

64ビットバージョンのWindowsの適切なページファイルサイズを確認する方法


この場合、合計物理RAMの1.5倍という通常の推奨は最適ではありません。 この非常に一般的な推奨事項は、すべてのメモリが「通常の」プロセスで使用されていることを前提として提供されています。通常は、メモリが所属するアプリケーションプロセスに対して大量のパフォーマンス問題を発生させることなく、

SQL Serverを実行しているサーバー(通常は非常に大量のRAMが搭載されているサーバー)では、物理RAMの大部分はSQL Serverプロセスにコミットされており、正しく構成されていれば物理メモリにロックされており、 。 SQL Serverは、ディスクI / Oを削減するために、プロセスに割り当てられたRAMの大部分をデータキャッシュとして使用し、パフォーマンスを念頭に置いて、独自のメモリを非常に慎重に管理します。 これらのデータキャッシュページをページファイルにページアウトするのは理にかなっていません。なぜなら、まずRAM内のデータをディスクI / Oを減らすことだけだからです。 (Windowsオペレーティングシステムでも、ディスクキャッシュと同様に使用可能なRAMを使用してシステムの処理速度を向上させています).SQL Serverは既に独自のメモリ空間を管理しているため、このメモリ空間をページング可能と見なしてはならず、サイズ。

Remusによって言及されたMEM_COMMITに関しては、用語は混乱している。なぜなら、仮想メモリ用語では、「予約」は実際の割り当てを決して参照するのではなく、別のプロセスによるアドレス空間(物理空間ではない) コミットできるメモリは基本的に物理RAMとページファイルサイズの合計に等しく、MEM_COMMITを実行するとコミットされたプールで使用可能な量が減少します。 このとき、ページファイルに一致するページ割り当てられませ 。 コミットされたメモリページが実際に書き込まれると、仮想メモリシステムが物理メモリページを割り当て、おそらく別のメモリページを物理RAMからページファイルにバンプします。 MSDNのVirtualAlloc関数リファレンスを参照してください。

Windows OSは、アプリケーションプロセスと独自のディスクキャッシュメカニズムとの間のメモリ圧迫を追跡し、ロックされていないメモリページを物理ページファイルからページファイルにバンプする時期を決定します。 私の理解では、ロックされていない実際のメモリ空間に比べてページファイルが大きすぎると、Windowsがページファイルに過度にアプリケーションメモリをページアウトし、その結果アプリケーションがページミス(パフォーマンス低下)の影響を受けます。

サーバーが他のメモリを必要とするプロセスを実行していない限り、4GBのページファイルサイズは十分に大きくなければなりません。 メモリ内のページをロックできるようにSQL Serverを設定している場合は、SQL Serverの最大メモリ設定を考慮して、OSや他のプロセス用に物理RAMを利用できるようにする必要があります。

SQL Serverの802のエラーは、システムがデータキャッシュのページをもうコミットできないことを示しています。 ページファイルサイズを増やすことは、Windowsが非SQL Serverプロセスからメモリをページアウトすることができる限り、この状況で役立ちます。 このような状況でSQL Serverメモリをページファイルに拡大できるようにすると、エラーメッセージが取り除かれる可能性がありますが、最初はデータキャッシュの理由が早いため、逆効果です。





windows