Kubernetes CPU & Memory Performance Tuning (2026): CFS Quotas, NUMA, HugePages, and Real-World Pod Sizing

If you’ve ever seen low CPU usage but high latency, or pods getting throttled despite “having enough CPU”, you’ve hit the Kubernetes resource model. Production performance depends on CFS quotas, CPU pinning, NUMA alignment, memory QoS, and correct requests/limits — not just throwing more replicas at the problem.

This is a practical, kernel-aware playbook for platform and backend engineers who want predictable latency and higher node density without overprovisioning.

The mental model: how Kubernetes actually allocates CPU

Kubernetes doesn’t “give” CPU — it enforces:

• CPU requests → scheduling weight (shares)
• CPU limits → CFS quota (hard cap per period)
• No limit → best for latency-sensitive workloads (no throttling)

If you set a CPU limit lower than what your app bursts to, the CFS scheduler throttles the container, causing latency spikes even if the node is idle.

Example: hidden throttling

resources:
  requests:
    cpu: "500m"
  limits:
    cpu: "500m"

A Go API that occasionally needs 1 core for GC will get throttled every time it bursts.

Fix: remove limits for latency-sensitive services or set limits significantly higher than requests.

Detecting CPU throttling (production commands)

Check throttling ratio:

kubectl exec -it pod -- \
  cat /sys/fs/cgroup/cpu.stat

Look at:

• nr_throttled
• throttled_time

Or via metrics:

• container_cpu_cfs_throttled_seconds_total

If throttling > 5–10%, expect p95 latency impact.

CPU Manager policies — pin your critical workloads

Enable static CPU manager policy on nodes for guaranteed pods.

--cpu-manager-policy=static

Then use Guaranteed QoS:

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
  limits:
    cpu: "2"
    memory: "4Gi"

This pins the pod to dedicated cores → no context-switch noise → predictable latency.

Best for:

• High-QPS APIs
• JVM services
• Databases
• Low-latency trading / real-time systems

NUMA awareness — the silent performance killer

On multi-socket machines, memory access across NUMA nodes adds latency.

Enable:

• Topology Manager → single-numa-node policy
• CPU Manager static policy
• Guaranteed QoS pods

This ensures CPU and memory come from the same NUMA node.

Without it, you get:

• Higher memory latency
• Cache misses
• Unstable tail latency

Memory tuning — requests, limits, and OOM reality

Requests vs limits

• Memory limit = hard OOM kill
• Memory request = scheduling weight

Setting memory limit too close to peak usage → random OOM kills.

Best practice:

• Set memory request = steady-state usage
• Set memory limit = peak + safety margin (or omit for critical services)

HugePages — when they matter

Use HugePages for:

• Databases (Postgres, MySQL)
• High-throughput caches
• JVM large heaps

Benefits:

• Fewer TLB misses
• Better memory locality
• Lower page management overhead

Example:

resources:
  limits:
    hugepages-2Mi: 1Gi

Requires node-level HugePage preallocation.

Pod sizing — the production formula

Step 1: Measure real usage

Use:

• container_cpu_usage_seconds_total
• container_memory_working_set_bytes Look at p95, not average.

Step 2: Set requests to p95

This ensures good bin-packing without starving.

Step 3: Set limits (or remove for CPU)

• CPU: no limit for latency-sensitive workloads
• Memory: p99 + 20–30%

Overcommit strategy (node efficiency)

Typical production targets:

• CPU overcommit: 2–4× (burstable workloads)
• Memory overcommit: minimal for stateful services, moderate for stateless

Use separate node pools:

• Latency pool → Guaranteed pods, static CPU, no overcommit
• Batch pool → Burstable pods, high overcommit

Scheduler & eviction tuning

Tune kubelet:

--eviction-hard=memory.available<500Mi
--system-reserved=cpu=500m,memory=1Gi
--kube-reserved=cpu=500m,memory=1Gi

Prevents system daemons from competing with workloads and avoids surprise evictions.

Real-world performance gains (what teams see)

After removing CPU limits and enabling static CPU manager:

• p95 latency ↓ 30–60%
• CPU throttling → near zero
• GC pauses stabilized (JVM/Go)
• Node density ↑ because fewer overprovisioned replicas needed

Observability — dashboards you need

Track:

• CPU throttling ratio
• Run queue length
• Context switches per pod
• Memory working set vs RSS
• NUMA locality metrics (if available)
• OOM kill count

Without these, you’re tuning blind.

60-day rollout plan

Week 1–2 — Measure

• Identify top latency services
• Measure CPU throttling and memory headroom

Week 3–4 — Remove bad limits

• Remove CPU limits from APIs
• Increase memory limits where OOMs occur

Week 5–6 — Enable CPU Manager (pilot)

• Create a dedicated node pool
• Run one critical service with Guaranteed QoS

Week 7–8 — NUMA + HugePages

• Enable topology manager
• Move database/cache workloads to HugePages

Week 9–10 — Right-size requests

• Use p95 metrics for requests
• Reduce replica count if overprovisioned

Common mistakes

• Setting CPU limits equal to requests → guaranteed throttling
• Ignoring NUMA on large nodes
• Overcommitting memory on stateful workloads
• Using average metrics instead of p95/p99
• Not separating latency-sensitive and batch workloads

Final checklist — production-ready pods

• CPU limits removed for latency-sensitive services
• Static CPU manager enabled for critical workloads
• Guaranteed QoS for core services
• NUMA alignment via topology manager
• Memory requests/limits based on p95/p99
• Separate node pools for batch vs low-latency

Most Kubernetes latency issues aren’t application bugs — they’re scheduling, throttling, and memory locality problems. Once you understand how CFS, NUMA, and QoS interact, you can deliver lower latency with fewer nodes and more predictable behavior.

The future belongs to engineers who tune the scheduler, not just the deployment.