SQL Server に適切な Windows O/S ページファイルのサイズ
https://stackoverflow.com/questions/2588
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
SQL Server を実行する Windows 2003 サーバーの適切なページファイル サイズに関する適切な経験則を知っている人はいますか?
解決
RAM のサイズに関係なく、物理 RAM の少なくとも 1.5 倍のページファイルが必要です。これは、1 TB RAM マシンを使用している場合でも当てはまり、ディスク上に 1.5 TB のページファイルが必要になります (馬鹿げているように聞こえますが、本当です)。
プロセスが VirtualAlloc/VirtualAllocEx 経由で MEM_COMMIT メモリを要求する場合、要求されたサイズをページファイルに予約する必要があります。これは最初の Win NT システムにも当てはまり、現在でも当てはまります。を参照してください。 Win32 での仮想メモリの管理:
メモリがコミットされると、メモリの物理ページが割り当てられます スペースはPageFileに予約されています.
極端に奇妙なケースを除いて、SQL Server は常に MEM_COMMIT ページを要求します。SQL が使用するという事実を考慮すると、 動的メモリ管理 可能な限り多くのバッファ プールを事前に予約するポリシー (予約および コミットする VAS の観点から)、SQL Server は起動時にページファイル内に大量のスペースの予約を要求します。ページファイルのサイズが適切でない場合、エラー 801/802 が SQL の ERRORLOG ファイルと操作に表示され始めます。
管理者は RAM が大きければページファイルが必要ないと誤って想定するため、これは常に混乱を引き起こします。実際にはその逆が起こり、RAM が大きいと、Windows NT メモリ マネージャの内部動作が原因で、ページ ファイルの必要性が増加します。予約されたページファイルは、できれば使用されないことが望ましいです。
他のヒント
リーマス（私が非常に尊敬しています）に敬意を表しますが、私は強く反対します。ページ ファイルがフル ダンプをサポートできるほど大きい場合は、毎回フル ダンプが実行されます。非常に大量の RAM を搭載している場合、これにより小さな瞬発が大きな停止につながる可能性があります。
1 回限りの一時的な問題が発生した場合に、サーバーが 1 TB の RAM をディスクに書き出す必要がなくなるのは望ましくありません。問題が繰り返し発生する場合は、ページ ファイルを増やして完全なダンプをキャプチャできます。PSS (または完全なダンプを分析する資格のある他の人) から完全なダンプをキャプチャするよう指示されるまで、これを行うのは待ちます。完全なダンプを分析する方法を知っている DBA は非常に少数です。とにかく発生するほとんどの問題のトラブルシューティングには、ミニダンプで十分です。
さらに、サーバーが 1 TB のフル ダンプを許可するように構成されており、問題が繰り返し発生する場合、どれくらいの空きディスク容量を手元に用意しておくことをお勧めしますか?1 つの週末で SAN 全体がいっぱいになる可能性があります。
幸運にも 3 GB または 4 GB の RAM を搭載した SQL Server があった時代には、ページ ファイルの 1.5 * RAM が標準でした。これはもう当てはまりません。すべての運用サーバー (メモリ不足が発生している SSAS サーバーを除く) では、ページ ファイルを Windows の既定のサイズと設定のままにします。
明確にするために、私は 2 GB の RAM から 2 TB の RAM までの範囲のサーバーを使用してきました。11 年以上経ちますが、完全なダンプをキャプチャするためにページング ファイルを増やす必要があったのは 1 回だけです。
Microsoftによると、「コンピューターのRAMの量が増えると、ページファイルの必要性が低下します。」その記事は、パフォーマンスログを使用してページファイルの量を判断する方法について説明します。 実は 使用されています。まずページ ファイルを 1.5 倍のシステム メモリに設定してから、推奨されるモニタリングを実行し、そこから調整を行ってください。
アプリケーションのワーキングセットのサイズまでは大きいほど効果があり、利益が逓減し始めます。キャッシュ ヒット率に大きな変化が見られるまで、サイズをゆっくりと増減させることで、これを見つけることができます。ただし、キャッシュ ヒット率が 90% 以上であれば、おそらく問題ありません。一般に、運用システム上でこれに注目して、RAM 割り当てを超えていないことを確認する必要があります。
最近、SQL Server の 1 つで完全に絞り込むことができなかったパフォーマンスの問題が発生し、実際に Microsoft サポート チケットの 1 つを使用して、トラブルシューティングを手伝ってもらいました。SQL Server で使用する最適なページファイル サイズが判明し、Microsoft は次のことを推奨しています。 RAM 容量の 1 1/2 倍.
高いパフォーマンスを求める場合は、ページングを完全に回避する必要があるため、ページ ファイル サイズはそれほど重要ではありません。DB サーバーに可能な限り多くの RAM に投資します。
多くの調査を行った結果、Windows 2003 Enterprise x64 上で Enterprise x64 を実行する専用 SQL Server にはページ ファイルがありません。
簡単に言えば、ページ ファイルは OS によって管理されるファイルのキャッシュであり、SQL には独自の内部メモリ管理システムがあります。
参照されている MS の記事は、ファイル共有などのすぐに使えるサービスを実行している OS に対するアドバイスであるとは言えません。
ページ ファイルがあると、SQL OS だけがその仕事を実行できるときに Windows が助けようとするため、ディスク I/O に負担がかかるだけです。
この場合、通常推奨される合計物理 RAM の 1.5 倍は最適ではありません。この非常に一般的な推奨事項は、すべてのメモリが「通常の」プロセスによって使用されているという前提の下で提供されます。通常、メモリが属するアプリケーション プロセスに重大なパフォーマンスの問題を発生させることなく、最も使用されていないページをディスクに移動できます。
SQL Server を実行しているサーバー (通常、非常に大容量の RAM を搭載) の場合、物理 RAM の大部分は SQL Server プロセスにコミットされ、(正しく構成されている場合) 物理メモリにロックされ、ページファイルにページアウトされないようにする必要があります。 。SQL Server は、パフォーマンスを考慮して自身のメモリを非常に注意深く管理し、プロセスに割り当てられた RAM の大部分をデータ キャッシュとして使用してディスク I/O を削減します。そもそもそのデータを RAM に置く唯一の目的はディスク I/O を減らすことであるため、これらのデータ キャッシュ ページをページファイルにページアウトすることは意味がありません。(Windows OS も、システム動作を高速化するために、ディスク キャッシュと同様に利用可能な RAM を使用することに注意してください。) SQL Server はすでに独自のメモリ領域を管理しているため、このメモリ領域は「ページ可能」とみなされるべきではなく、ページファイルの計算に含めるべきではありません。サイズ。
Remus 氏が言及した MEM_COMMIT に関しては、仮想メモリ用語では「予約」は実際の割り当てを指すのではなく、別のプロセスによるアドレス空間 (物理空間ではなく) の使用を防ぐことを指すため、用語が混乱を招きます。「コミット」できるメモリは基本的に物理 RAM とページファイルのサイズの合計に等しく、MEM_COMMIT を実行すると、コミットされたプールで使用可能な量が減るだけです。します ない その時点で、ページファイル内に一致するページを割り当てます。コミットされたメモリ ページが実際に書き込まれるとき、つまり、仮想メモリ システムが物理メモリ ページを割り当て、場合によっては別のメモリ ページを物理 RAM からページファイルにバンプするときです。MSDN を参照してください VirtualAlloc関数 参照。
Windows OS は、アプリケーション プロセスと独自のディスク キャッシュ メカニズム間のメモリ負荷を追跡し、ロックされていないメモリ ページを物理メモリからページファイルにバンプするタイミングを決定します。私の理解では、実際のロックされていないメモリ領域に比べてページファイルが大きすぎると、Windows がアプリケーション メモリをページファイルに過剰にページアウトし、その結果、アプリケーションがページ ミス (パフォーマンスの低下) の影響を受ける可能性があると考えています。
サーバーがメモリを大量に消費する他のプロセスを実行していない限り、ページファイルのサイズは 4GB あれば十分です。メモリ内のページのロックを許可するように SQL Server を設定している場合は、OS 自体や他のプロセスに使用できる物理 RAM を残すように SQL Server の最大メモリ設定を設定することも考慮する必要があります。
SQL Server の 802 エラーは、システムがデータ キャッシュにこれ以上ページをコミットできないことを示します。ページファイルのサイズを増やすことは、Windows が SQL Server 以外のプロセスからメモリをページアウトできる限り、この状況でのみ役立ちます。この状況で SQL Server メモリがページファイルまで増加することを許可すると、エラー メッセージが表示されなくなる可能性がありますが、そもそもデータ キャッシュの理由について前述したように、逆効果です。
