PerfectScalePerfectScale

PerfectScale

Init Spike Handling: Right-Size JVM Pods for Boot and Run

Init Spike Handling gives JVM pods startup resources at boot, then resizes them in place for steady state. Cut boot-time waste with no restarts.

This page is also available in Deutsch, Español, Français, Italiano, 日本語, and Português.

Ira Chernous
By Ira Chernous
Oct 21, 20266 min read

Banner reading PerfectScale Right-Sizes Java and Spiky Pods, with a CPU over time chart that drops after startup.

Most JVM pods are sized for the first two minutes of their life and then run oversized for the next two months. If you run Java on Kubernetes, you know the trade-off. Class loading, JIT compilation and cache warming need a lot of CPU and memory at boot. Once the service is up, demand drops and stays low. That means you pay for startup-level resources on every replica, all the time. Size for steady-state demand instead, and you risk CPU throttling, OOM kills, and the issues that come with them.

PerfectScale now does it differently. See how!

One recommendation, two resource profiles

A recommendation based on long-term usage averages the startup spike with everything that comes after. The result? Resource requests that are too high for steady state but still don't fully cover startup needs.

Teams usually end up choosing one of three options:

  • Overprovision for startup: The most common approach. It avoids startup issues, but you pay for that extra capacity on every replica, all the time.
  • Tune resources manually: Adjust startup and runtime resources separately, then repeat the process every time a release changes the workload profile. Available with in-place resize, GA in Kubernetes v1.35+.
  • Size for steady state and hope for the best: Until CPU throttling, OOM kills, or startup failures prove otherwise. Hope it is a minority.

The problem isn't the sizing itself. The workload has two distinct resource profiles, while the recommendation accounts for only one.

Right-size startup and runtime resources autonomously

PerfectScale continuously identifies workloads with different startup and runtime needs and provides separate resource recommendations for each phase:

  • Startup (init) phase. Applied when the pod is created, through the mutation hook PerfectScale already uses to inject recommended resources. The startup recommendation is sized to the higher of the two phases, so the pod isn't scheduled onto a node that can't cover its boot.
  • Steady-state (runtime) phase. Once the startup phase is complete, PerfectScale applies the runtime recommendation using in-place resize. Resources are adjusted on the running Pod without a restart or any manual manifest changes.

PerfectScale builds on native Kubernetes capabilities, using the In-Place Pod Resize API (GA in v1.35) to apply runtime resource recommendations without restarting Pods. PerfectScale adds the intelligence and automation to make startup and runtime optimization work seamlessly. It tracks each Pod’s lifecycle and automatically switches from startup to runtime resources when the startup phase is complete. If a Pod can’t be resized safely, PerfectScale falls back to a single resource recommendation to avoid disrupting the workload.

What this means for you

Before
Peak startup resources paid for across the whole runtime
After
Startup gets the peak, then the pod is resized down to what steady state needs
Before
Steady-state sizing risks throttling, OOM kills or failed startups
After
The startup phase is sized to the higher of the two phases
Before
Manual tuning of startup vs. runtime resources, redone as workloads change
After
Automatic transition from init to runtime, with no restart and no manual step
Before
Risk that an automated change breaks a JVM
After
Safety guardrails based on your framework
Before
Automated changes that are hard to trust
After
Every change is tracked per workload revision, with its impact on usage, waste and savings

Impact:

  • Your workloads get the resources they need at each stage, so you stop paying for startup-level capacity long after startup is over.
  • Automation you can’t inspect is hard to trust. PerfectScale tracks resource changes across workload revisions and shows startup and steady-state resources separately in Podfit and Zoom-in.
  • Cost, waste, and savings calculations reflect resource needs in each phase, not a single average.

Not Java only

Any workload with different startup and runtime resource needs can benefit from this approach. Common examples include:

  • JavaScript and TypeScript: during V8 JIT warmup.
  • Ruby on Rails and Django: while loading frameworks and application state.
  • Init tasks: database migrations, cache warming, and other startup operations.
  • Stress tests and load tests: when workloads temporarily need more resources during test initialization or ramp-up.

PerfectScale detects these patterns and adjusts resources between phases, with additional safeguards for frameworks like Java.

Want to learn how to handle Java and other spiky workloads more effectively? Join our webinar to explore the challenges and see how PerfectScale approaches them. See the details and register for the webinar here.