Container Resource Limit Calculator
Kubernetes requests ≠ limits. Set requests too high → nodes idle at 30% allocatable. Set limits too low → OOM killer at 2 AM on a Saturday deploy. Model the full resource envelope — requests, limits, runtime overhead, OS headroom — before the kubelet makes the decision for you.
📐 Workload Profile
Profile your app: QPS, concurrency, runtime (JVM/V8/Go). The engine computes heap, GC overhead, thread stacks, OS headroom, and CPU sizing. Get limits that survive a production spike.
Container Memory Sizing: Why Guesswork Causes Out-of-Memory Kills
In Kubernetes-orchestrated production environments, container OOM (Out of Memory) kills remain one of the most frequent causes of application outages. The root cause is rarely a memory leak — it is almost always a resource limit misconfiguration where the declared resources.limits.memory does not account for the runtime's internal memory overhead beyond application heap.
How This Calculator Works
This tool applies runtime-specific memory models derived from production profiling and vendor documentation. Each runtime has fundamentally different memory dynamics:
| Runtime | Heap / Working Set | Overhead Components | Key Pitfall |
|---|---|---|---|
| Java (JVM) | -Xmx heap + metaspace + code cache + thread stacks (~1 MB per thread default) + direct byte buffers + JIT compilation cache + GC bookkeeping | JVM internal overhead typically 20–35% beyond -Xmx. Native memory (NMT) is not tracked by heap dumps. | Setting container limit = -Xmx causes OOM because GC, threads, and native memory live outside the heap. The JVM can consume 1.3–1.5× the max heap size under load. |
| Node.js (V8) | V8 heap (young + old generation) + external buffers (Buffer/C++ addons) + HTTP agent socket buffers + per-request closure allocations | V8 heap limit is ~1.4 GB by default on 64-bit. External memory (Buffers, ArrayBuffers) lives outside the V8 heap and can exceed it dramatically under streaming workloads. | Node's event loop can hold thousands of in-flight request objects simultaneously. A 100 KB payload × 1,000 concurrent requests = 100 MB just in request buffers — outside the V8 heap. |
| Go | Go heap (managed by the GC with per-goroutine stacks starting at 2 KB and growing dynamically) + fixed-overhead runtime structures | Goroutine stacks (min 2 KB each, can grow to 1 GB), GC metadata (~5–10% of heap), and off-heap arena allocations (CGO, mmap). | Goroutine leaks are the #1 Go memory killer. 100,000 leaked goroutines at 2 KB minimum each = 200 MB, but the GC cannot reclaim them because they are still referenced. |
CPU Sizing Methodology
CPU limits in Kubernetes are measured in CPU shares (1 CPU = 1 vCPU / hyperthread). Unlike memory, exceeding a CPU limit does not kill the container — it throttles the process. The estimation engine uses Little's Law (Concurrent Requests = QPS × Avg Response Time) to derive the minimum compute headroom, then applies a runtime-specific efficiency coefficient:
| Runtime | CPU Efficiency Factor | Reason |
|---|---|---|
| Java (JVM) | 0.70–0.85 | JIT warmup overhead and GC pause CPU consumption (especially G1 and ZGC). Thread context switching overhead on high thread counts. |
| Node.js (V8) | 0.55–0.70 | Single-threaded event loop limits vertical scaling. CPU-bound work blocks the event loop. Cluster mode or worker_threads needed for multi-core utilization. |
| Go | 0.85–0.95 | Goroutines are multiplexed onto OS threads efficiently via the Go scheduler. Low context-switch overhead. GC is concurrent and typically < 1 ms pause. |
Why "Just Set 2 GB and Watch" Doesn't Work
Container orchestrators like Kubernetes enforce hard memory limits via cgroups. When a container exceeds its memory limit, the kernel OOM killer terminates the process — and the container restarts from scratch. Without runtime-aware sizing, teams end up in a costly cycle: set a limit → observe OOM kills under peak load → increase the limit → repeat. Meanwhile, over-provisioning wastes cluster capacity and drives up cloud costs. A typical 50-node Kubernetes cluster running at 35% allocatable capacity because of oversized requests is hemorrhaging infrastructure budget.