ほぼ同時にほぼ毎日突然メモリが解放される

Windows AzureにeコマースWebサイトを実行するVMがいくつかありますが、最近、Telegraf、InfluxDb、Grafanaを使用してこれらのマシンを監視しています。数週間データを収集した後、メモリ使用可能メトリックに関連する奇妙なパターンに気づきました。

毎日ほぼ同じ日に、解放されているメモリの量が急激に増加していることに気づきました。非常に限られたDevOpスキルのために、何が原因なのか理解できません。

このパターンを示すグラフは次のとおりです。

私の質問は、次のようなものにつながる可能性があるのは何ですか？メモリリークのせいだと疑いがちですが、...空きメモリが70％を下回ることはなく、トラフィックが最も多い2つのVMでのみ発生します。

このようなものが表示されたときに心配する必要がありますか？

PS：私が実行している各Windowsサービスとw3wpプロセスのPrivate e Virtualバイトのメトリックの収集を開始しました...ただし、このメトリックはメモリリークがあるかどうかを確認するのに非常に信頼性が高くないことを読みましたが、しかし、少なくとも、ある種の傾向を取得して、それが上記のパターンと相関しているかどうかを確認しようとします。

他のシステム、特にJavaベースのデータツールで、これと同じ「ノコギリ波」のパターンを見てきました。あなたの説明に基づいて、あなたは.NETガベージコレクション（これは.NETアプリであると想定しています）を見ていると思います 。Javaと.NETはどちらもメモリ管理された言語であり、ガベージコレクションを使用するフレームワークです。

メモリリークは、典型的には、メモリ管理を欠いているフレームワークに、またはガベージコレクタをオーバーライドするか、混乱されるメモリ管理フレームワーク上でプログラムに見出されます。

これらが最もトラフィック量の多いサーバーであるという事実は理にかなっています。.NETフレームワークが必要に応じてメモリを割り当てると、ガベージコレクターが定期的に起動し、ガベージコレクションアルゴリズムを使用して未使用のメモリを回収します。特定のパフォーマンスの問題を追跡しているのでない限り、このメモリ使用パターンは問題ではないと思います。

このグラフがこのように見える理由がわかったと思います。

また、ASP.NETアプリケーション/エラーの合計パフォーマンスカウンターのメトリックも収集しています。メモリ使用可能サージが発生すると同時に、合計エラーメトリックが0にリセットされることに気付きました。

msdnによると、このカウンターは、アプリケーションの再起動/シャットダウンが発生するたびに0にリセットされます。

これにより、このメモリ使用可能のノコギリパターンの原因は、アプリケーションの再起動が原因であると考えられます。

これが私のチャートがどのように見えるかです：

更新

これは、W3WPプロセスのプライベートバイトがリサイクルの制限に達したために発生します（アプリプールでプライベートバイトの制限が構成されています）。Private Bytesチャートをよく見ると、メモリ使用量が650MBから3.2GBに、数時間後に3.6GBから16.6GBに跳躍し、異常が発生していることがわかります。これはリサイクルが行われるときです。