You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Keith Lee (Jira)" <ji...@apache.org> on 2026/06/12 17:47:00 UTC
[jira] [Created] (FLINK-39924) Memory fragmentation from jemalloc misconfiguration
Keith Lee created FLINK-39924:
---------------------------------
Summary: Memory fragmentation from jemalloc misconfiguration
Key: FLINK-39924
URL: https://issues.apache.org/jira/browse/FLINK-39924
Project: Flink
Issue Type: Bug
Components: Runtime / Configuration
Affects Versions: 2.1.3, 1.20.5, 2.2.1, 2.0.2
Reporter: Keith Lee
We observed excessive memory fragmentation in production, using malloc_stats we identified the most extreme case of fragmentation at 3.91 GB (10.01 GB Resident - 6.1 GB Active) which was significant as the pod has a limit of 16 GB.
This was caused by {*}jemalloc arena count misconfigured to higher than expected default of 4 x number_of_cpu_cores{*}.
h2. Why is high jemalloc arena count bad?
Higher number of arena reduces thread contention during malloc at the cost of higher memory fragmentation and overall memory usage as memory freed by the process to jemalloc is less likely to be re-used as they are spread across higher number of arenas and has to go through decay of 10 seconds before being freed back to operating system.
The fragmentation leaves less memory for page cache, impacting performance and cause higher likelihood to OOMKill.
h2. Root cause
Jemalloc by default configures narena using the 4 * number_of_cpu_core, however the value for number_of_cpu_core is obtained from the host machine and not from the CPU resource configured for the pod. The misconfiguration happens when host machine CPU core count and pod CPU resource configuration mismatches.
h2. Reproduction and confirmation
Steps to reproduce can be found here: [https://github.com/leekeiabstraction/flink-docker/tree/reproduce-jemalloc-fragmentation/reproduce-jemalloc-fragmentation]
The reproduction was ran on a 16 core Mac Studio. We find on a reduction of 10.7 % in resident set size and a slight performance improvement when narena is configured correctly
{{============================================================}}
{{[+] Per-image summary:}}
{{============================================================}}
{{ image highest anon avg anon lowest write-recs avg write-recs}}
{{ flink:2.2.1-scala_2.12-java17 1679.3 MiB 1522.6 MiB 186901 207614}}
{{ flink-2.2.1-narenas4 1499.7 MiB 1301.9 MiB 200945 213198}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)