次の方法で共有

スロットルのトラブルシューティング (Windows Server AppFabric キャッシュ)

  • [アーティクル]

Windows Server AppFabric キャッシュ ホストで物理メモリが少なくなると、キャッシュ ホストはスロットルと呼ばれる状態になる場合があります。 使用可能な物理メモリが増えて調整された状態が解除されるまで、キャッシュ クラスターは調整されたキャッシュ ホストに存在するキャッシュにはデータを書き込みません。

スロットルの診断

スロットルの最も明らかな影響はアプリケーションに現れます。 キャッシュに書き込もうとすると、DataCacheException エラーが発生します。 例外の詳細については、「RetryLater (Throttled) (Windows Server AppFabric キャッシュ)」を参照してください。 スロットルがキャッシュ クラスターで問題になっていることを確認するには、以下のテストを使用できます。

  • Get-CacheClusterHealth Windows PowerShell コマンドを使用します。 キャッシュが Throttled カテゴリのパーセンテージになっているキャッシュ ホストがあるかどうかを調べます。

  • 各キャッシュ ホストのイベント ビューアーで Operational ログを有効にし、"サービスは調整済みです" という内容のイベント 116 を探します。

  • パフォーマンス モニターを使用して、各キャッシュ ホストで Memory | Available MBytes を追跡します。 この値が全物理メモリの 15% より低下すると、キャッシュ ホストは調整済みになります。 キャッシュ ホストのメモリが CacheSize 設定の 4% 以下になっても、スロットルが発生します。

調整済みのサーバーでは削除実行も増加することに注意してください。 削除の問題の詳細については、「削除のトラブルシューティング (Windows Server AppFabric キャッシュ)」を参照してください。

ヒント

ここで説明したツールの詳細については、「正常性の監視ツール (Windows Server AppFabric キャッシュ)」を参照してください。

スロットルの解決

スロットルの解決について決定する前に、それが発生した理由をよく理解することが重要です。 次の表では、可能性のある原因と推奨される解決策を示します。

スロットルの原因 説明と解決策

他のプロセスによるメモリの大量使用

キャッシュ ホストで他のプロセスが大量にメモリを使用している可能性があります。 キャッシュ サービス用に確保されたメモリ量によっては、低メモリ状態になる可能性があります。 パフォーマンス モニターの Process | Private Bytes カウンターを使用して各プロセスで使われているメモリを表示することにより、この問題を検出できます。 キャッシュ サービス DistributedCacheService.exe が最大のメモリ消費者でない場合、高い割合でメモリを消費しているプロセスを探します。 1 つの解決策は、問題のあるプロセスをキャッシュ ホストではない他のサーバーに移動します。 コンピューターに物理メモリを追加することもできます。

ヒント

Set-CacheHostConfig を使用してキャッシュ ホスト用のキャッシュ サイズを設定できますが、この制限は削除実行を開始するタイミングを決定するだけです。 キャッシュ サービス用のメモリがそのレベルに保たれることを保証するものではありません。 詳細については、「削除のトラブルシューティング (Windows Server AppFabric キャッシュ)」を参照してください。

キャッシュ サービスによるメモリの大量使用

この問題は、タスク マネージャーまたはパフォーマンス モニターを使用してキャッシュ サービス DistributedCacheService.exe が使用しているメモリを表示することで識別できます。 1 つ以上のキャッシュで有効期限または削除が無効になっている可能性があります。 これは低メモリ状態を促進します。 クラスター内のキャッシュを調べるには、Windows PowerShell コマンドの Get-Cache -MaxRegions 0 を使用します。 Get-CacheConfig コマンドを使用するとキャッシュごとの設定を確認できます。 有効期限と削除の詳細については、「有効期限と削除」を参照してください。 キャッシュ クラスターに対する要求が能力を超えている可能性もあります。 キャッシュ ホストに物理メモリを追加する、またはクラスターにキャッシュ ホストを追加するといった対策があります。

コレクションが行われていない .NET メモリ

.NET のガベージ コレクションは自動的に行われますが、コレクションの間に、コレクションされていないメモリによってキャッシュ ホストの低メモリ状態が引き起こされる場合があります。 この場合は、Windows PowerShell コマンド Invoke-CacheGC を調整されたキャッシュ ホストで使用して、完全なガベージ コレクション サイクルを強制的に実行できます。 低メモリ状態が解消されない場合、コレクションされていない .NET メモリは要因ではありません。

カスタム領域

アプリケーションでは CreateRegion メソッドを使用してカスタム領域を作成できます。 これらの領域は常に特定のキャッシュ ホスト上の 1 つのユニットとして存在します。 アプリケーションが大量のデータを 1 つの領域に格納すると、他のキャッシュ ホストには使用できるメモリがあっても、1 つのキャッシュ ホストが調整される可能性があります。 どのキャッシュ ホストがカスタム領域用に選択されるのかを確実に知ることはできないので、クラスターの各キャッシュ ホストにメモリを追加するのが 1 つの解決策です。 もう 1 つの解決策は、アプリケーションの設計を変更して、領域に格納するデータを減らすか、または複数の領域を使用するようにします。

タグ ハッシュ テーブル

複数の AppFabric キャッシュ メソッドでは、項目を関連するタグと共にキャッシュに格納できます。 タグを使用すると内部的なハッシュ テーブルが作成されますが、このテーブルは関連する項目が削除された後でも削除されません。 これはメモリ リークではありませんが、AppFabric キャッシュ サービスによって使用される全体的なメモリの増加につながります。 時間が経つと変化するタグをアプリケーションで使用すると、メモリ低下の原因になる可能性があります。

関連項目

概念

サーバーの問題のトラブルシューティング (Windows Server AppFabric キャッシュ)

  2011-12-05