Ich habe eine ASP.NET v4.0-Anwendung auf einen neuen Server migriert, der unter einem Win2008 Server x64-Betriebssystem ausgeführt wird. Da es mit der migrierten asp.net-Anwendung kein Problem zu sein schien, wenn der Anwendungspool auf "32-Bit-Anwendungen aktivieren" gesetzt war = False (sollte standardmäßig auf x64-IIS eingestellt sein), ließ ich ihn im 64-Bit-Modus laufen.ASP.NET 4.0 Worker-Prozess verbraucht 5x mehr Speicher in 64 Bit im Vergleich zu 32 Bit
Dann stellte sich heraus, dass Benutzersitzungen sehr oft unterbrochen werden, weil der Arbeitsprozess seinen virtuellen Speichergrenzwert bald überschreitet. Aus diesem Grund habe ich die gleiche Anwendung und den gleichen Anwendungspool mit nur einer einzigen modifizierten Einstellung getestet - ich habe die Option "32-Bit-Anwendungen aktivieren" auf "True" gesetzt, um sie im "WOW64" -Modus laufen zu lassen; alles andere blieb so wie es war. Ich habe die Arbeitsspeichermenge verglichen, die vom Worker-Prozess in beiden Modi verbraucht wurde, wobei ich absolut das gleiche Arbeitsszenario benutze und das Ergebnis war etwas schockierend für mich:
Ich habe erwartet, dass es passieren kann, dass der Worker-Prozess ein wenig mehr Speicher im 64-Bit-Modus verbrauchen wird, aber dieser Unterschied ist viel zu groß.
Wird solch ein enormer Memory-Effekt als normal angesehen? Ist es möglich, es irgendwie zu reduzieren/zu beheben?
Wir haben etwas ähnliches gesehen - siehe http://support.microsoft.com/kb/912891. Ich wäre jedoch überrascht, wenn das so wäre. – dash
Beliebiger nicht verwalteter Code, Bibliothek von Drittanbietern? Es scheint, dass Sie ein ** Speicherleck ** in x64 haben, da Sie immer wieder recyceln. – Aliostad
@dash interessant. Aber das ist nur für .NET 2.0. – Aliostad