tl;dr it seems the memory limit is not reflected in
/sys/fs/cgroup/memory/memory.limit_in_bytes, causing dotnet runtime to exceed memory usage.
I decided to give fly.io a go as a hosting platform for dockerized dotnet (.net 5) web app.
For this purpose I am using a free plan to deploy the simple test ASP.NET 5 app I have.
Unfortunately the app fails on boot; it is being killed because it exceeds the memory limit.
I was quite surprised because I had it recently ran on a similar platform that still provides free plan. Although they provide 2x the memory available here in the free plan, the app never exceeded ~150 Mb. And definitely, not during the boot.
I ran it locally in a docker container limiting the memory to 200M and it ran just fine.
no cgroup limit:
After some further investigation - I believe dotnet runtime respects cgroup memory limits (*)
However it looks the fly.io runtime doesn’t set these values.
Looking at the following file content:
For the local docker (limited to 200m) it is
For the other hosting (limited to 512m) it is
For fly.io (free plan, 256m) it is
My guessing is, because of the cgroup limit not being set correctly, dotnet is not aware of a current limit. It therefore keeps allocating more memory and gets killed eventually.
(*) - didn’t do debugging but this code seems to be relevant runtime/Interop.cgroups.cs at main · dotnet/runtime · GitHub