SQLServerを実行しているWindows2003サーバーの適切なページファイルサイズの目安を知っている人はいますか?
8 に答える
レムス (私が大いに尊敬している) には敬意を表しますが、私は強く反対します。ページ ファイルがフル ダンプをサポートするのに十分な大きさである場合、毎回フル ダンプが実行されます。非常に大量の RAM を使用している場合、これにより小さなブリップが大きな停止につながる可能性があります。
1 回限りの一時的な問題が発生した場合、サーバーが 1 TB の RAM をディスクに書き出す必要はありません。問題が繰り返し発生する場合は、ページ ファイルを増やして完全なダンプを取得できます。PSS (またはフル ダンプを分析する資格のある他の誰か) からフル ダンプをキャプチャするように依頼されるまで、これを行うのを待ちます。完全なダンプを分析する方法を知っている DBA はごくわずかです。とにかくポップアップするほとんどの問題のトラブルシューティングには、ミニダンプで十分です。
さらに、サーバーが 1 TB のフル ダンプを許可するように構成されていて、問題が繰り返し発生する場合、どのくらいのディスク空き容量を手元に用意することをお勧めしますか? 週末だけで SAN 全体がいっぱいになる可能性があります。
ページ ファイル 1.5*RAM は、3 GB または 4 GB の RAM を搭載した SQL Server を持っていた幸運な時代には標準でした。これはもはや当てはまりません。ページ ファイルをすべての運用サーバーで Windows の既定のサイズと設定のままにします (メモリ プレッシャが発生している SSAS サーバーを除く)。
明確にするために、私は 2 GB の RAM から 2 TB の RAM までの範囲のサーバーを使用してきました。11 年以上経った今でも、完全なダンプを取得するためにページング ファイルを増やす必要があったのは 1 回だけです。
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 によってページファイルが不要になると誤って想定しているため、常に混乱が生じます。実際には、Windows NT メモリ マネージャの内部動作のために、RAM が大きいとページファイルの必要性が増します。予約済みのページファイルは、使用されないことを願っています。
Microsoftによると、「コンピュータのRAMの量が増えると、ページファイルの必要性は減ります」。次に、パフォーマンスログを使用して、実際に使用されているページファイルの量を判断する方法について説明します。最初にページファイルを1.5Xシステムメモリに設定してから、推奨される監視を行い、そこから調整を行ってください。
アプリケーションのワーキング セットのサイズが大きいほど、利益が減少し始めます。キャッシュ ヒット率に大きな変化が見られるまで、サイズをゆっくりと増減することで、これを見つけることができます。ただし、キャッシュ ヒット率が 90% 程度を超えていれば、おそらく問題ありません。通常、実稼働システムでこれを監視して、RAM 割り当てを超えていないことを確認する必要があります。
最近、SQL Server の 1 つにパフォーマンスの問題があり、完全に絞り込むことができませんでした。実際には、Microsoft サポート チケットの 1 つを使用してトラブルシューティングを手伝ってもらいました。SQL Server で使用する最適なページファイル サイズが明らかになり、Microsoft の推奨はRAM の量の 1.5 倍になることです。
高性能を求めている場合は、ページングを完全に避けたいので、ページファイルのサイズはそれほど重要ではなくなります。DBサーバーに可能な限り多くのRAMに投資します。
この場合、合計物理 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 を設定した場合は、SQL Server の最大メモリ設定を設定して、OS 自体や他のプロセス用に物理 RAM を使用できるようにすることも検討する必要があります。
SQL Server の 802 エラーは、システムがデータ キャッシュに対してこれ以上ページをコミットできないことを示します。Windows が非 SQL Server プロセスからメモリをページアウトできる限り、ページファイル サイズを大きくしてもこの状況でのみ有効です。この状況で SQL Server のメモリをページ ファイルに拡張できるようにすると、エラー メッセージが表示されなくなる可能性がありますが、最初のデータ キャッシュの理由について前述した点により、逆効果です。
多くの調査の結果、Windows 2003 Enterprise x64 で Enterprise x64 を実行している専用の SQL Server にはページ ファイルがありません。
簡単に言うと、ページ ファイルは OS によって管理されるファイルのキャッシュであり、SQL には独自の内部メモリ管理システムがあります。
参照されている MS の記事は、アドバイスがファイル共有などのすぐに使えるサービスを実行している OS に対するものであるとは限りません。
SQL OS だけがジョブを実行できる場合、Windows が支援しようとするため、ページ ファイルを使用するとディスク I/O に負担がかかります。