Smooth GC capacity alarms with a severe-pressure fast path - #2910
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe GC scaling alarm now detects pauses above 10% in three of five minutes. A new severe-GC alarm detects pauses above 15% in two consecutive minutes. The high-GC alarm explicitly targets the scale-up policy. ChangesGC Alarm Controls
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Feature Merge Risk: ⚪ Minimal · up to The GC alarms match the intended thresholds and scaling configuration, with no unresolved merge-blocking concerns. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
dd11616
into
codex/permission-fetch-scaleout-config
Use three of five one-minute GC maxima above 10% to add capacity, with a separate alarm for two consecutive maxima above 15%. Both alarms use the existing scale-up policy. CPU, heap, metric dimensions, missing-data handling, and scale-in settings retain their current values.
This PR targets the current production configuration branch so its diff contains only the GC alarm change. Application code and the immutable application image are unchanged.
Validation: parsed the YAML and checked that all other options/resources are identical; exercised eight threshold and burst examples; replayed 40 complete saved minute bins as an offline predicate check. The replay does not simulate CloudWatch's missing-data lookback, publication delay, or policy execution, and does not establish that the prior scale-out was unnecessary. No production update was performed for this PR.