```weekly chart, sharp drops are a restart```
# questions-and-troubleshooting
a
Copy code
weekly chart, sharp drops are a restart
k
check jemalloc_allocated_bytes and jemalloc_resident_bytes, whethere these two numbers are close to the memory usage monitored from the pod.
starrocks_be_jemalloc_allocated_bytes
and
starrocks_be_jemalloc_resident_bytes
a
Copy code
So these metrics are not variables for configuration?
k
these are prometheus metrics which can be pulled from CN via
http://<CN>:8040/metrics
a
Copy code
starrocks_be_jemalloc_allocated_bytes 1541884120
starrocks_be_jemalloc_resident_bytes 1647411200
Copy code
I scaled the FE down to 3 pods and noticed that this only happens on the leader.
Copy code
Why CN? If the memory is leaking on FE.
k
OK. thought it were CN nodes.
if FE nodes, check the jvm related configuration and JVM stack metrics.
a
Does jvm also have an endpoint for metrics? They're just not activated in the chart, so I didn't check.
JAVA_OPT few moments
"-Dlog4j2.formatMsgNoLookups=true -Xmx14G -Xms2G -XX:+UseShenandoahGC -Xlog:gc*:${LOG_DIR}/fe.gc.log.$DATE:time" 16 GB ram он node,
GC changed in an attempt to solve the problem
k
xmx14G is too much for a 16G node.
usually xmx can be set to 70% ~ 80% of the node available Mem.
a
Copy code
Okay, then I experimented, scaled FE to 3 pods to get a quorum and reduced the memory to 4 GB per pod. I actually changed JAVA_OPT to "-Dlog4j2.formatMsgNoLookups=true -Xmx3G -Xms1G -XX:+UseShenandoahGC -Xlog:gc*:${LOG_DIR}/fe.gc.log.$DATE:time" The result is the same.
Copy code
There is even a file with profiling and a graph)
Copy code
t was solved in the following way: 2 Fepods and 4 CN. After that, the memory leak stopped. We need to somehow better understand how to build a quorum in Starrocks.
Снимок экрана 2025-11-23 в 16.20.37.png,Снимок экрана 2025-11-23 в 16.20.30.png