キャッシュおよびメモリ マネージャーのパフォーマンスのトラブルシューティング
Windows Server 2012 以前は、2 つの主な潜在的な問題により、特定のワークロードで使用可能なメモリがほぼ枯渇するまでシステム ファイル キャッシュが増加していました。 このような状況になり、システムのパフォーマンスが低下した場合、サーバーがこれらの問題のいずれかに直面しているかどうかを判断できます。
監視対象カウンター
メモリ \ 長期平均スタンバイ キャッシュ ライフタイム (秒) < 1800 秒
Memory\Available (バイト、キロバイト、または メガバイト 単位)
メモリ \ 常駐システム キャッシュのバイト数
「メモリ \ 使用可能なメガバイト数」が少なく、同時に「メモリ \ 常駐システム キャッシュのバイト数」が物理メモリのかなりの部分を消費している場合は、「RAMMAP」を使用してキャッシュが使用されている場所を確認できます。
システム ファイル キャッシュに NTFS メタファイル データ構造が含まれている
この問題は、次の図に示すとおり、RAMMAP 出力のアクティブなメタファイル ページ数が多いことを示しています。 この問題は、何百万ものファイルがアクセスされているビジー状態のサーバーで発生した可能性があります。その結果、NTFS メタファイル データがキャッシュから解放されない状態です。
この問題は、以前は DynCache ツールによって軽減されていました。 Windows Server 2012 以降では、アーキテクチャが再設計され、この問題は発生しなくなりました。
システム ファイル キャッシュにメモリにマップされたファイルが含まれている
この問題は、RAMMAP 出力にアクティブなマップされたファイル ページが多数あることを示します。 これは通常、サーバー上の一部のアプリケーションが、FILE_FLAG_RANDOM_ACCESS フラグが設定された CreateFile API を使用して多数の大きなサイズファイルを開いていることを示します。
この問題については、サポート技術情報の記事 2549369 で詳しく説明されています。 FILE_FLAG_RANDOM_ACCESS フラグは、キャッシュ マネージャーがファイルのマップされたビューをメモリ内に可能な限り長く保持することを示しています (メモリ マネージャーがメモリ不足を示さないまで)。 同時に、このフラグは、ファイル データのプリフェッチを無効にするようにキャッシュ マネージャーに指示します。
この状況は、Windows Server 2012 以降のワーキング セット トリミングの改善によってある程度軽減されましたが、問題自体は、主に FILE_FLAG_RANDOM_ACCESS を使用しないアプリケーション ベンダーが対処する必要があります。 アプリケーション ベンダーの代替ソリューションとしては、ファイルにアクセスする際に低いメモリ優先度を使用するというケースがあります。 これは、SetThreadInformation API を使用して実現できます。 メモリの優先度が低いページは、より積極的にワーキング セットから削除されます。
Windows Server 2016 以降のキャッシュ マネージャーは、トリミングの決定を行う際に FILE_FLAG_RANDOM_ACCESS を無視してこれをさらに軽減します。そのため、FILE_FLAG_RANDOM_ACCESS フラグなしで開いたその他のファイルと同様に処理されます (キャッシュ マネージャーでは、このフラグを引き続き使用して、ファイル データのプリフェッチを無効にします)。 このフラグを使用して多数のファイルを開き、真にランダムな方法でアクセスした場合でも、システム キャッシュの肥大化を引き起こす可能性があります。 アプリケーションでは FILE_FLAG_RANDOM_ACCESS を使用すしないことを強くお勧めします。
リモート ファイルのダーティ ページのしきい値を常に超えている
リモート クライアントからの書き込み中にシステムの速度が低下する場合、この問題が発生している可能性があります。 この問題は、高速リモート クライアントから低速のサーバーの宛先に大量のデータが書き込まれる場合に発生する可能性があります。
Windows Server 2016 以前では、このようなシナリオでは、キャッシュ内のダーティ ページのしきい値に達すると、書き込みスルーが発生した場合と同様に動作します。 これにより、大量のデータがディスクでフラッシュされる可能性があります。これにより、ストレージが遅い場合に長い遅延が発生し、リモート接続ではタイムアウトが発生する可能性があります。
Window Server 2016 以降では、タイムアウトの可能性を減らす軽減策が設けられています。 リモート書き込み用に個別のダーティ ページしきい値が実装され、これがインライン フラッシュが超過した場合に実行されます。 これにより、書き込みの負荷が高いアクティビティ中に不定期に速度が低下する可能性がありますが、ほとんどの場合、タイムアウトのリスクは排除されます。 このリモートダーティ ページの既定のしきい値は、ファイルあたり 5 GB です。 構成およびワークロードによっては、異なる数の方がパフォーマンスが向上します。
デフォルトのサイズの 5GB が構成で適切に機能しない場合は、十分なパフォーマンスが得られるまで、制限を 256MB 単位で増やしてみることをお勧めします。 次の点に注意してください。
このレジストリ キーの変更を有効にするには、再起動が必要です。
RemoteFileDirtyPageThreshold の単位はページ数です (キャッシュ マネージャーによって管理されるページ サイズ)。 つまり、必要なサイズ (バイト単位) を 4096 で割った値で設定する必要があります。
推奨値は、128 MB <= N <= 使用可能なメモリの 50% です。
このしきい値を -1 に設定すれば、完全に無効にすることができます。 リモート接続のタイムアウトが発生する可能性があるため、これはお勧めできません。
たとえば、10,737,418,240 バイト/4096 = 2,621,440 (10 進数の DWORD 値の 2621440) である 10GiB に制限を設定する場合。
このしきい値は、次のレジストリ値を使用して制御できます。
- キー:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management- 型:
DWORD - 値の名前:
RemoteFileDirtyPageThreshold - 値データ: 10 進数 - ページ数 (キャッシュ マネージャーによって管理されるページ サイズ)。
- 型: