It’s possible your ASP.NET Core app running on Linux could run out of memory from time to time because the garbage collector may not consider container memory limits.
To ensure the best experience use dotnetcore 2.0.2+ with Pivotal Cloud Foundry ERT 1.11.15+.
dotnetcore 1.x has no possibility to recognize the memory limit of cgroups. Fortunately dotnetcore 2.0.0 introduces the concept of recognizing cgroup limits.
dotnetcore 2.0.0 still does not recognise cgroup memory limits in containerized environments. This will only be fixed in dotnetcore 2.0.2.
ERT did not provide the cgroup endpoint in garden-runc, therefore dotnetcore didn’t recognize the memory limit of the container and only used the VM memory size. This was fixed in ERT 1.11.15.
The amount of memory allocated by .NET Core is related to the amount of cores and CPUs in the system. Therefore we do see large differences between environments and the memory footprint for small applications due to the amount of CPUs and cores in the system. By Default in systems with only one physical CPU dotnetcore will use Workstation Garbage Collection, while on systems with more than one CPU it will use Server Garbage Collection. The heuristic of Server Garbage Collection does prefer throughput over memory use.
Similar to not recognizing the correct memory in a container, the correct CPU share assigned to the container is currently not shared with dotnetcore. This will be fixed in dotnetcore 2.0.2