Calculate how much memory to allocate per container based on workload profile.
A container's memory limit should cover its baseline footprint plus the incremental memory each in-flight request consumes at your expected concurrency, with a buffer for garbage collection pauses, connection pools and traffic spikes. Formula: limit = (base + per_request × concurrent) × (1 + overhead / 100). Setting the limit too tight risks OOMKills under load; setting it too loose wastes cluster capacity.
memoryLimit = (baseMemory + perRequestMemory × concurrentRequests) × (1 + overhead / 100)
Load test your service and observe RSS growth under increasing concurrency, or divide the delta between idle and peak memory by the number of concurrent requests during the test.
For predictable workloads, setting them equal avoids being throttled or evicted under memory pressure from neighboring containers. For bursty workloads, a limit 20-50% above the request gives headroom.
The container's cgroup will trigger the OOM killer, terminating the process (or a process inside it) once usage exceeds the limit — this shows up as an OOMKilled container in Docker/Kubernetes.
15-30% is common for most services. JVM-based services with significant GC pause behavior often need 30-50% to avoid GC-triggered spikes causing an OOMKill.