サーバーへのメモリを増やしましたが、ページファイルのサイズを変更する必要がありますか？
Windows Server 2012 R2でSQL Server 2017を実行していて、メモリを256 GBから512 GBに増やしました。仮想メモリの次の構成に気づきました。
- C：[OS] = 2 GB
- G：[データ] =なし
- H：[ログ] =なし
- T：[TEMP] =なし
インストールされているメモリのサイズの1.5倍または2倍にサイズを設定することについては、多くのアドバイスがあります。私はこれを正しく読んでいますか、それとも記事を誤って読みましたか？
SQLは仮想メモリではなくRAMのみを使用する必要があり、OSは2GBの仮想メモリしか必要としないため、仮想メモリについて心配しないことを提案する記事もあります。
RAMの2倍のサイズの推奨は時代遅れで非現実的です。サーバーに32 GBのRAMしかない場合、それは意味があるかもしれませんが、それは無駄です大量のメモリを搭載したシステムで2倍にするための高価なディスク容量。
ページファイルには主に2つの目的があります。
メモリのスワップファイルとして使用します。 SQL Serverと他のアプリケーションが、使用可能なメモリの量を制限するように正しく構成されている場合、この目的には必要ありません。システムがメモリをスワップするためにページファイルを使用する必要がある場合、システムのパフォーマンスは非常に悪くなるため、実質的に停止してすぐに対処する必要があります。したがって、1 TB pagefileを構成すると、システムがディスクへのスワップを開始するときにパフォーマンスが向上せず、100 GBでもスワップする必要がある前に、それについて何かを実行する必要があります。 。
システムがクラッシュした場合にメモリダンプを保持するには（OSがインストールされているボリューム上）。繰り返しになりますが、サーバーに32 GBのRAMしかない場合、システムがクラッシュした場合に完全なメモリダンプを実行するようにサーバーを構成することは理にかなっています。ただし、診断のために完全なメモリダンプが必要になることはめったにありません。カーネルメモリダンプは、大量のメモリを搭載したシステムでは合理的な選択です。また、最近では、2倍の推奨が行われた1996年（またはいつでも）よりも、Windowsのクラッシュの頻度がはるかに少なくなっています。また、システムがクラッシュして1 TBメモリダンプが発生した場合（別のTB free for c：for it）が必要になります）、幸運の圧縮私はカーネルダンプ用に構成し、システムがクラッシュし、Microsoftが問題を診断するために完全なメモリダンプを必要とする場合にのみ変更します。
したがって、あなたが超偏執狂的である（確かに状況によっては正当化される）場合、2 TBを割り当てるために使用されない可能性が高いため、巨大なページファイルを検討する必要があります。ただし、本当に必要になるでしょう。
だから私の答えは、ページファイルのサイズを増やす必要がほとんどないということです。おそらく現在のサイズでは使用されておらず、現在はメモリが多いため、使用される可能性はさらに低くなっています。そのため、大きなディスクでより多くのディスク領域を無駄にする必要がないということになります。
「SQL Server 2017 Administration Inside Out」本から：
Windowsは、SQL Serverを含むすべてのアプリケーションの仮想メモリ用のページファイルを、現在のワーキングセットに使用可能なメモリが不足している場合に使用します。これは、RAM）のセグメントをドライブにオフロード（ページング）することで行われます。ストレージはメモリよりも低速であるため、システムページファイルから作業する場合、ページアウトされたデータも低速になります。
また、ページファイルは、クラッシュフォレンジック分析のためにシステムメモリダンプをキャプチャする役割も果たします。これは、大量のメモリを備えた最新のオペレーティングシステムでのサイズを決定する要因です。
これが、システムページファイルの一般的な推奨事項が、少なくともサーバーの物理メモリ量と同じサイズである必要がある理由です。
もう1つの推奨事項は、ページファイルをシステム管理に設定することです。ただし、メモリが大容量のシステムでは、ページファイルが非常に大きくなる可能性があるため、ページファイルがオペレーティングシステムにある場合は注意してください。システム（OS）ボリューム。これも、ページファイルがOSボリュームから離れて、独自のボリュームに移動されることが多い理由です。
パフォーマンスが大幅に低下するため、SQLサーバーがページファイル（仮想メモリ）を使用しないようにすることが最善です。十分な購入/インストールRAM SQL Serverのニーズをカバーするためのメモリなので、ページファイルをまったく使用する必要はありません
SQL Serverが実際に使用しているRAMメモリの量を確認するには、パフォーマンスカウンターを監視することで実行できます。
Target Server Memory
Total Server Memory
Database Cache Memory
Stolen Server Memory
Plan Cache
Lock Memory
Log Pool Memory
SQL Cache Memory
Free Memory
Connection Memory
Optimizer Memory
Reserved Server Memory
Granted Workspace Memory
それらを見て、SQL Serverが時間とともに消費する量を把握すると、より多くのRAMメモリがサーバーに必要か、または割り当てられているか、512 GBで十分か（またはまたは、クエリ、インデックス作成、テーブル設計を最適化して、RAMの使用量を減らします）
ヒント：Total Server Memoryを探します-これはSQL Serverが消費する合計量です。おおよそTotal Server Memory = Database Cache Memory + Stolen Server Memory + Free Memory
64ビットバージョンのWindowsに適切なページファイルサイズを決定する方法
クラッシュダンプ設定
システムクラッシュ中にクラッシュダンプファイルを作成する場合は、ページファイルまたは専用のダンプファイルが存在し、システムクラッシュダンプ設定をバックアップするのに十分な大きさが必要です。それ以外の場合、システムメモリダンプファイルは作成されません。
詳細については、「システムクラッシュダンプのサポート」セクションを参照してください。
ピークシステムコミット料金
システムコミット料金は、システムコミット制限を超えることはできません。この制限は、物理メモリ（RAM）とすべてのページファイルの合計です。ページファイルが存在しない場合、システムのコミット制限は、インストールされている物理メモリよりもわずかに小さくなります。システムがコミットしたメモリ使用量のピークは、システム間で大きく異なる可能性があります。したがって、物理メモリとページファイルのサイズも異なります。
したがって、クラッシュのトラブルシューティングを行わない限り、「ピークシステムコミットチャージ」に対応できるようにページファイルのサイズを決定します。これは、Windowsで割り当てられる仮想メモリの最大合計量です。 RAM +ページファイルサイズは、観測または予測されたピークシステムコミット料金よりもいくらか大きくする必要があります。
システムがメモリ不足の状態になると、SQL Serverは自動的にメモリ使用量を減らします。 Memory Management Architecture Guide を参照してください。したがって、専用SQL Serverのページファイルの使用量は比較的少なくなります。 SQL Serverのメモリ使用量がサーバーRAMの容量を下回っている状態では、サーバーで実行されている他のプロセスが仮想メモリをコミットするため、ピークシステムコミット料金は数GBだけ追加されます。
したがって、8GBまたは16GBは、通常、SQL Serverに十分なページファイルサイズを超えています。そして、SQLサーバーのRAM使用率を制限するために、最大サーバーメモリをなしに設定します。
SQL Serverが100％の使用率で実行されている場合、トラブルシューティングのために、サーバー上でSQLエージェントジョブ、SSISパッケージ、エクスプローラーやSSMSなどの補助プロセスを実行するのに十分なRAM +ページファイルが必要です。
正常なサーバーのセットアップでは、ページングファイルはまったく必要ありません。 RAMは安価であり、ページングプロセスが開始されるとユーザーは緊張します。また、ページングファイルの存在自体がいくつかのRAMといくつかのCPUを消費することにも注意してください。サイクル。
クラッシュダンプは、最近の運用サーバーで期待するものではありません。クラッシュが繰り返し発生する非常にまれな状況で、ダンプを見ることができる有能な人々のみが、それらを調べます。通常、サーバーはswearされ、再起動されます。自動再起動は、過去20年ほどのWindowsサーバーのデフォルトでした。
ページングファイルの多かれ少なかれ有用なアプリケーションは、スケジュールされた再起動間のメモリリークに対応することです。この場合、実験的にサイズ設定されているため、ページングファイルでリークが解決し、メモリ不足の状態によってサーバーがクラッシュすることはありません。ほとんどのリークはこの方法では管理できず、SQL Serverは2020年の時点ではそれほどリークしていません。
はい、メモリが通常の負荷に対して十分である場合でも、時間外のメモリを大量に消費するタスクがページファイルに溢れる可能性があります。この場合は、さらにRAM=を購入してください。そうしないと、データベースが大きくなるにつれて、問題のあるタスクを時間外に維持できなくなります。