Ich hab in den letzten Tagen relativ viel Zeit damit verbracht rauszufinden warum eine meiner Web-APIs (ASP.NET Core) öfters OutOfMemory Exceptions wirft. In meinem Dev-System konnte ich diese nicht nachvollziehen, works on my machine könnte man sagen ;-)

Der Fehler trat schon immer in Situationen auf in denen das System komplexere Aufgaben zu bearbeiten hatte, einen größeren Bericht zusammenstellen beispielsweise.

AppService & -plan dick genug

Der AppService lief in einem AppService aus dem Premiun-Fach, also mehr als genug RAM um so einen Bericht zu generieren und die Speicherauslastung war meinen Metriken zufolge auch selten über 25% - seltsam also dass da irgendwie der Speicher nicht reichen sollte.

Bits, wir brauchen mehr Bits

Relativ schnell dachte ich an die RAM Beschränkung von 32bit Anwendungen, aber ein Blick in die Configuration des AppServices ergab, dass wir schon auf 64bit standen. Recherchen im Netz (StackOverflow, MSDN) brachten mir irgendwie immer die gleichen 2 Angaben:

• Die Einstellung im AppService Blade soll unter Configuration auf “64-bit” stehen
• Der AppServicePlan muss mindestens Basic oder höher sein

beides war bei mir der Fall.

Über die Advanced Tools / Kudu bin ich dann im Process Explorer auf die ersten Hinweise gestoßen. Die Einstellung wirkt sich auf den IIS-Prozess aus, dieser läuft dann auch im 64bit Modus. Das hält ihn jedoch offensichtlich nicht davon ab den eigentlichen Applikation-Prozess mit der 32bit dotnet Runtime zu starten.

Die Lösung

Die Lösung hab ich dann in einem Diskussionsthread in den GitHub-Issues zum ASP.NET Core gefunden. Im AppService muss offenbar eine x64bit Runtime installiert werden. Warum das so ist, weiß ich nicht, denn die nötigen Executables unter c:\Program Files\dotnet\ sind auch ohne diese Extension auf den Maschinen drauf, wie man mit der Console leicht prüfen kann.

Nachdem die Extension installiert war, lief meine Anwendung zunächst gar nicht mehr. Das kann ich mir aktuell auch immer noch nicht erklären, hierzu gern eine Nachricht an mich, wenn jemand eine Idee hat. Die Anwendungen standen immer auf Target “Any CPU” und laufen lokal auch ohne Probleme im x64-Mode. Die CI-Pipeline gibt außer “-c Release” auch nichts anderes vor. Nachdem ich also Target auf “x64” geändert hatte und das ganze nochmal neu deployed habe ging es dann.

Nach ein paar Minuten haben die User wohl auch gemerkt dass man jetzt freier Speicher atmen darf.

OutOfMemory-Exception hab ich seither nicht mehr beobachtet. Nice.