Das Gedächtnis wird jeden Tag ungefähr zur gleichen Zeit abrupt freigegeben


10

Ich habe einige VMs unter Windows Azure, auf denen unsere E-Commerce-Website ausgeführt wird, und seit kurzem verwenden wir Telegraf, InfluxDb und Grafana, um diese Computer im Auge zu behalten. Nach ein paar Wochen Datenerfassung habe ich ein seltsames Muster in Bezug auf die Metrik " Speicher verfügbar" festgestellt :

Jeden Tag, fast immer zur gleichen Tageszeit, habe ich festgestellt, dass plötzlich viel Speicher freigegeben wird, was ich aufgrund meiner sehr, sehr begrenzten DevOp-Fähigkeiten nicht herausfinden kann, was dies verursacht.

Hier ist eine Tabelle, die dieses Muster zeigt:

Seltsames Muster

Meine Frage ist: Was könnte zu so etwas führen? Ich bin versucht zu vermuten, dass ein Speicherverlust schuld ist, aber ... Der freie Speicher fällt nie unter 70% und tritt nur in zwei der VMs mit dem meisten Datenverkehr auf!

Sollte ich mir Sorgen machen, wenn ich so etwas sehe?

PS: Ich habe versucht, Metriken für private und virtuelle Bytes für jeden der von uns ausgeführten Windows-Dienste und für den w3wp-Prozess zu sammeln ... obwohl ich gelesen habe, dass diese Metriken nicht sehr zuverlässig sind, um herauszufinden, ob Sie einen Speicherverlust haben. aber zumindest werde ich versuchen, eine Art Trend zu bekommen und zu sehen, ob er mit dem oben gezeigten Muster korreliert.


2
Sie sehen einen üblichen Müllsammler oder Cache, der IMHO reinigt. In welcher Sprache ist Ihre Website fertig? (Dies könnte Ihre App, Ihr Web-Server und sogar das System sein, das einige Aufräumarbeiten durchführt)
Tensibai

Das war etwas, das ich auch vermutet habe ... Es wurde in ASP.NET MVC 4 durchgeführt, daher macht die Theorie der Speicherbereinigung Sinn. Nebenbei bemerkt, die Metriken, die ich für den w3wp-Prozess und den Windows-Dienst gesammelt habe, sehen absolut normal aus.
António Sérgio Simões

Ich weiß fast nichts in ASP, aber ich gehe davon aus, dass es eine Möglichkeit gibt, den Speicherverbrauch und die Speicherbereinigung wie in Java grafisch darzustellen. Dies sollte dazu beitragen, dass dies die Hauptursache ist.
Tensibai

Antworten:


7

Ich habe das gleiche "Sägezahn" -Muster in anderen Systemen gesehen, insbesondere in einem Java-basierten Datenwerkzeug. Basierend auf Ihrer Beschreibung denke ich, dass Sie sich mit der .NET- Speicherbereinigung befassen (vorausgesetzt, dies ist eine .NET-App). Java und .NET sind beide speicherverwaltete Sprachen und Frameworks, die die Speicherbereinigung verwenden.

Ein Speicherverlust tritt normalerweise in Frameworks auf, denen die Speicherverwaltung fehlt, oder in einem Programm in einem speicherverwalteten Framework, das den Garbage Collector überschreibt oder verwirrt.

Die Tatsache, dass dies Ihre Server mit dem höchsten Datenverkehr sind, ist sinnvoll. Sie sehen, dass das .NET Framework nach Bedarf Speicher zuweist, dann startet der Garbage Collector in einem regelmäßigen Zyklus und holt nicht verwendeten Speicher mithilfe der Garbage Collection-Algorithmen zurück. Wenn Sie bestimmte Leistungsprobleme nicht nachverfolgen, ist dieses Speichernutzungsmuster meines Erachtens kein Problem.


Es ist in der Tat eine .NET-App und aufgrund meiner Recherchen in den letzten Tagen macht es sehr viel Sinn, was Sie und @Tensibai geschrieben haben.
António Sérgio Simões

7

Ich denke, ich habe herausgefunden, warum diese Grafik so aussieht.

Ich sammle auch Metriken für den Leistungsindikator für ASP.NET-Anwendungen / Fehler. Insgesamt wurde festgestellt, dass die Metrik "Gesamtfehler" genau zur gleichen Zeit, zu der ein Anstieg des verfügbaren Speichers auftritt, auf 0 zurückgesetzt wird.

Laut msdn wird dieser Zähler bei jedem Neustart / Herunterfahren der Anwendung auf 0 zurückgesetzt.

Dies lässt mich glauben, dass die Ursache für dieses Sägezahnmuster "Speicher verfügbar" in einem Neustart der Anwendung liegt.

So sehen meine Diagramme aus:

Fehler Total ASP.NET Application Memory Surge

AKTUALISIEREN

Dies liegt daran, dass die privaten Bytes des W3WP-Prozesses das Limit für eine Wiederverwertung erreicht haben (im App-Pool ist ein Limit für private Bytes konfiguriert). Bei genauerer Betrachtung des Diagramms "Private Bytes" können wir feststellen, dass etwas Ungewöhnliches passiert, da die Speichernutzung von 650 MB auf 3,2 GB und einige Stunden später von 3,6 GB auf 16,6 GB steigt! Dies ist der Zeitpunkt, an dem das Recycling erfolgt.


2
Dies ist eine viel plausibelere Erklärung. Plötzliche Speicherfreigabe erfolgt fast ausschließlich bei Prozessneustarts. Mechanismen zum Freigeben des Speichers laufender Prozesse sind niemals so scharf und geben den Speicher selten frei, anstatt Speicherplatz auf dem vorab zugewiesenen Heap freizugeben.
Jiri Klouda
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.