Riesige Menge an nicht verwaltetem Speicher im IIS-Anwendungspool. Es ist normal?

Wir versuchen herauszufinden, warum unsere in IIS gehosteten Anwendungen den gesamten Arbeitsspeicher auf unseren VMs verbrauchen, und dazu habe ich einige Speicherprofilerstellungs-Tools heruntergeladen, mit denen ich experimentieren kann. Ich habe zuerst JetBrains 'dotMemory ausprobiert, merkte aber schnell, dass der meiste Speicher im Anwendungspool-Prozess nicht verwaltet wurde und dass dotMemory nicht sehr nützlich war, da es sich hauptsächlich um die Analyse des verwalteten Speichers handelt.

Beachten Sie, dass der Pool insgesamt 221 MB verwendet, aber nur 19 MB verwaltet wird. NET-Speicher.

Nachdem ich mit dotMemory herumgespielt habe, habe ich beschlossen, ein anderes Tool auszuprobieren und habe von ANGS Memory Profiler von RedGate erfahren.

ANTS injiziert etwas in die Anwendung, das eine Menge von diesem Speicher verbraucht, aber es zeigt immer noch einige absurde Mengen von physischem RAM, die verwendet werden:

Ist das für ein sehr einfaches WebAPI-Projekt akzeptabel? Wir bemerkten, dass unsere VM bei einigen gehosteten Projekten eine Speicherauslastung von 95% bis 100% erreichte, was dazu führte, dass die Maschine sehr langsam war. Wir haben versucht, alle 4 Anwendungen im selben Anwendungspool zu vereinheitlichen, aber dies ergab nur ungefähr die gleichen Ergebnisse: Die gesamte Speicherauslastung des einzelnen Pools entsprach der von allen 4 getrennten.

Sie können aus den Grafiken erkennen, dass die CLR alleine bis zu 80MB Speicher zu fressen scheint. Wie können wir die Speichernutzung von IIS-Anwendungspools senken? Ich habe gelesen, dass Das Ändern der Pools in den x86-Modus reduziert den Overhead des Speichers erheblich und probierte es einige Minuten lang aus, was zu einer guten Reduktion auf fast die Hälfte des gesamten RAM führte, aber selbst wenn ich diesen Weg gehen würde, würde ich gerne Wissen Sie, warum solche einfachen Projekte so viel RAM auf IIS essen.

Wir verwenden eine der grundlegenderen Azure-VMs mit nur 1,7 GB RAM, und diese vier sehr einfachen Webanwendungen (zwei MVC-Websites und zwei WebAPI-Projekte) führen die VM bereits zu Boden.

Aus irgendeinem seltsamen Grund scheinen die Pools auf unseren lokalen Entwicklungscomputern weniger RAM zu verwenden. Es scheint auch keine Speicherlecks zu geben, da das Erstellen von Snapshots an zufälligen Punkten immer die gleiche sehr hohe, aber konstante Speicherauslastung ergibt. Wir sind sehr vorsichtig mit dem Code, um immer verfügbare Objekte zu entfernen, und wir verwenden die strengsten Einstellungen für FxCop mit null Problemen.