Hi StarRocks Community, We are running StarRocks 3.2.x in production and facing a critical stability issue — both our BE (beservice) and FE (feservice) are getting killed by SIGKILL unexpectedly and repeatedly, causing unplanned restarts multiple times a day. BE is the primary offende We are managing services via Supervisord. While the auto-restart recovers the process within ~5 seconds, this is not acceptable in a production environment — we need to eliminate the root cause entirely. --- Crash Timeline (from Supervisord logs) Jan 4 — FE crashes twice: •

12:39 UTC

→

feservice killed by SIGKILL → restarted → recovered in ~5s

•

20:08 UTC

→

feservice killed by SIGKILL again → restarted → recovered in ~5s

Jan 5 — BE crashes twice within 4 minutes: •

06:45 UTC

→

beservice killed by SIGKILL → restarted → recovered in ~3s

•

06:49 UTC

→

beservice killed by SIGKILL *again* (only 4 mins after restart) → recovered in ~5

The back-to-back BE crashes within 4 minutes strongly suggest the underlying pressure (OOM or CPU saturation) was not relieved after the first restart — the process was killed again as soon as it came back up. --- Suspected Root Causes Based on our analysis, we believe the crashes are caused by one or both of the following: 1. Linux OOM Killer — OS forcefully killing the process due to memory exhaustion. SIGKILL without any application-level error is a classic OOM killer signature. 2. CPU Saturation — Sustained high CPU causing the process to become unresponsive or get killed by an external watchdog. We have not yet confirmed via

dmesg

— we are actively checking and will update. --- What We Need Help With* We are looking for production-proven solutions, not just diagnostics. Specifically: 1. OOM Confirmation & Fix - Best way to confirm OOM killer involvement (

dmesg

patterns,

/var/log/syslog

?) - Recommended

mem_limit

and memory tuning parameters in

be.conf

for StarRocks 3.2.x to prevent OOM kills - Should we set

mem_limit

as a percentage or absolute value for BE in production? 2. CPU Pressure Handling - Are there known StarRocks 3.2.x configs to throttle query/load CPU usage and prevent saturation? - Any recommended cgroups or OS-level limits to protect the BE process? 3. BE → FE Crash Correlation - Can repeated BE crashes destabilize the FE as well, or are these independent failures? - Is there a known cascading failure pattern in 3.2.x we should be aware of? 4. Long-term Stability - What monitoring/alerting setup do you recommend to catch memory/CPU pressure before it leads to a SIGKILL? - Any known bugs or patches in 3.2.x related to this behavior? --- Happy to share: •

be.conf

/

fe.conf

(sanitized) •

dmesg

output • BE/FE logs around crash timestamps • System resource metrics (RAM, CPU) This is a production system and we need a reliable fix. Any guidance from the community or StarRocks team is greatly appreciated. 🙏