Recommended container limits for dotnet-monitor

One of the recurring questions I get around the usage of dotnet-monitor is on the topic of recommended container limits. If, like me, you do not come from a Kubernetes background let’s dig in on the fundamentals a bit here and learn together.

Requests and Limits are the mechanism Kubernetes uses to control resources (CPU and memory) consumed by your pod.

Requests represent what the containers are guaranteed to get, so if a container requests a specific resource Kubernetes will only schedule it on a node that can supply that resource. Limits work the other way, they ensure that a container never goes above a particular value.

CPU resources are defined as millicores and are denoted by the unit m. For example if your container needs 3 full cores to run you would indicate that with the value of 3000m, or if you need half a core you would put 500m. Memory resources are defined in bytes, and you normally define a Mebibyte value (Mi). However, you can use anything from bytes up to units of Petabyte. It bears repeating when defining the Request limit defining a values greater than your nodes can meet, it result in pod never getting scheduled.

Request and Limits for dotnet-monitor

So back to my original point, our engineering team have developed a set of recommended Requests and Limits for dotnet-monitor, as of the time of this writing they are as follows:

resources:
  requests:
    memory: "32Mi"
    cpu: "50m"
  limits:
    memory: "256Mi"
    cpu: "250m"

How much memory and CPU consumed by dotnet-monitor is dependent on what is being executed, here are few scenarios to consider:

• Metrics consume a negligible amount of resources, although using custom metrics can affect this.
• Operations such as traces and logs may require memory in the main application container that will automatically be allocated by the runtime.
• Resource consumption by trace operations is also dependent on which providers are enabled, as well as the buffer size allocated in the runtime.
• It is not recommended to use highly verbose log levels while under load. This causes a lot of CPU usage in the dotnet-monitor container and more memory pressure in the main application container.
• Dumps also temporarily increase the amount of memory consumed by the application container.

Photo by Joshua Hoehne on Unsplash