La mémoire est brusquement libérée chaque jour à peu près à la même heure

J'ai quelques machines virtuelles sur Windows Azure qui exécutent notre site Web de commerce électronique, et dernièrement, nous avons commencé à utiliser Telegraf, InfluxDb et Grafana pour garder un œil sur ces machines. Après quelques semaines de collecte de données, j'ai remarqué un motif étrange lié à la métrique de mémoire disponible :

Tous les jours presque toujours à la même période de la journée, j'ai remarqué qu'il y avait une quantité abrupte de mémoire libérée qui, en raison de mes compétences DevOp très très très limitées, je ne peux pas comprendre ce qui est à l'origine de cela.

Voici un graphique qui montre ce modèle:

Ma question est: qu'est-ce qui pourrait conduire à quelque chose comme ça? Je me sens tenté de soupçonner qu'une fuite de mémoire est à blâmer, mais ... La mémoire libre ne descend jamais en dessous de 70% et ne se produit que dans deux des machines virtuelles avec le plus de trafic!

Dois-je m'inquiéter quand je vois quelque chose comme ça?

PS: J'ai commencé à rassembler des métriques pour les octets privés et virtuels pour chacun des services Windows que nous avons en cours d'exécution et pour le processus w3wp ... bien que j'ai lu que ces métriques ne sont pas très fiables pour savoir si vous avez une fuite de mémoire, mais au moins je vais essayer d'obtenir une sorte de tendance et voir si elle est en corrélation avec le schéma ci-dessus.

J'ai vu ce même modèle "en dents de scie" dans d'autres systèmes, en particulier un outil de données basé sur Java. Sur la base de votre description, je pense que vous examinez le garbage collection .NET (en supposant qu'il s'agit d'une application .NET.) Java et .NET sont tous deux des langages et des cadres gérés par la mémoire qui utilisent le garbage collection.

Une fuite de mémoire se trouve généralement dans les cadres qui manquent de gestion de la mémoire, ou dans un programme sur un cadre géré par la mémoire qui remplace ou déroute le garbage collector.

Le fait que ce soient vos serveurs les plus fréquentés est logique. Vous voyez le framework .NET allouer de la mémoire selon les besoins, puis le garbage collector entre en action sur un cycle régulier et récupère la mémoire inutilisée à l'aide des algorithmes de collecte de déchets. À moins que vous ne suiviez des problèmes de performances spécifiques, je ne pense pas que ce modèle d'utilisation de la mémoire soit un problème.

Je pense avoir découvert pourquoi ce graphique ressemble à ceci.

Je collecte également des métriques pour le compteur de performances totales Applications / Erreurs ASP.NET, et j'ai remarqué qu'exactement en même temps qu'une surtension de mémoire disponible se produit, la métrique Total Errors se remet à 0.

Selon msdn, ce compteur est réinitialisé à 0 chaque fois qu'un redémarrage / arrêt d'application se produit.

Cela m'amène à croire que la cause de ce motif en dents de scie disponible en mémoire est due au redémarrage de l'application.

Voici à quoi ressemblent mes graphiques:

METTRE À JOUR

Cela se produit car les octets privés du processus W3WP ont atteint la limite pour un recyclage (nous avons une limite d'octets privés configurée dans le pool d'applications). Et en regardant de près le graphique des octets privés, nous pouvons voir que quelque chose d'anormal se produit parce que l'utilisation de la mémoire passe de 650 Mo à 3,2 Go et quelques heures plus tard de 3,6 Go à 16,6 Go! C'est à ce moment que le recyclage a lieu.