Analyzing Cold‑Start Failures and Sentinel Protection in Serverless Scaling Scenarios

After a serverless instance auto‑scaled, the newly added machines were instantly overwhelmed, leading to high CPU usage, frequent Full GC, and eventual JVM crash.

Monitoring data (see

) shows a spike between 2:40‑3:15 am with CPU at 100 % and Full GC that does not reclaim memory, indicating the JVM is near collapse.

The problem is reproduced by replaying 400 QPS traffic without pre‑warming; the same high‑CPU, Full GC pattern appears and the JVM crashes.

To prevent such overload, a Sentinel system rule limiting CPU usage to 80 % is introduced. The rule automatically trips a circuit‑breaker when the CPU threshold is exceeded.

Without the rule, cold‑start recovery takes 5‑7 minutes, during which CPU remains high and QPS stays low (50‑100). With the rule enabled, the system avoids the “near‑crash” state; recovery is immediate and QPS quickly returns to normal after about one minute.

Performance analysis identifies three main causes of the cold‑start slowdown: (1) HotSpot JIT optimization not yet applied, (2) delayed resource initialization (thread pools, Sentinel, external connections), and (3) a crash‑loop where high load triggers more GC, which further raises CPU and slows response, creating a feedback loop until JIT optimizations or resource readiness restore stability.

Finally, the article notes that similar overload scenarios can occur in any service when sudden traffic spikes trigger immediate scaling without proper protection, emphasizing the importance of proactive circuit‑breaking and resource‑ready strategies.