<div dir="ltr">Hi everyone,<div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">That's my first mail on gdal-dev list, thanks in advance for your feedback/replies.</div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">I have been using the GDAL's ubuntu images, which sets <font face="monospace" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">LD_PRELOAD=libtcmalloc_minimal.so.4</font> using tcmalloc as per docs hint <a href="https://gdal.org/en/latest/user/multithreading.html#ram-fragmentation-and-multi-threading" target="_blank" style="color:rgb(86,163,241);background-color:transparent">Multi-threading — GDAL documentation</a></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">Now, when I deploy an intensive IO (/vsis3) workflow in a Kubernetes+Spark Cluster,</div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">I have observed memory accumulation behavior, which apparently leads to OOM breakdowns. The workaround I've found is using a clean spark python process with:<br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><font face="monospace" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">spark.python.worker.reuse=false</font>, though I was curious to dive a bit further and find the root-cause of the memory stacking.</div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">After letting Opus 5.5 work in a long session, it came back with the suggestion of opting for <font face="monospace" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">TCMALLOC_AGGRESSIVE_DECOMMIT=true </font><font face="arial, sans-serif" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">which is expected to address the memory issue.<br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">Now my humble question, is that something that could be set as a default env inside GDAL images? Could we add a note in the docs for awareness that the current default behavior</font></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><font face="arial, sans-serif" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">together with Spark may raise this phenomenon?</font></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><font face="arial, sans-serif" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><br style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"></font></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><font face="arial, sans-serif" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">Thank you,</font></div><div style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);"><font face="arial, sans-serif" style="scrollbar-color: rgb(69, 74, 77) rgb(32, 35, 36);">Stelios</font></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Oct 31, 2026 at 4:45 PM Stelios Lagaras <<a href="mailto:stelios.lagaras@gmail.com">stelios.lagaras@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>That's my first mail on gdal-dev list, thanks in advance for your feedback/replies.</div><div><br></div><div>I have been using the GDAL's ubuntu images, which sets <font face="monospace">LD_PRELOAD=libtcmalloc_minimal.so.4</font> using tcmalloc as per docs hint <a href="https://gdal.org/en/latest/user/multithreading.html#ram-fragmentation-and-multi-threading" style="background-color:transparent" target="_blank">Multi-threading — GDAL documentation</a></div><div><br></div><div>Now, when I deploy an intensive IO (/vsis3) workflow in a Kubernetes+Spark Cluster,</div><div>I have observed memory accumulation behavior, which apparently leads to OOM breakdowns. The workaround I've found is using a clean spark python process with:<br><font face="monospace">spark.python.worker.reuse=false</font>, though I was curious to dive a bit further and find the root-cause of the memory stacking.</div><div><br></div><div>After letting Opus 5.5 work in a long session, it came back with the suggestion of opting for <font face="monospace">TCMALLOC_AGGRESSIVE_DECOMMIT=true </font><font face="arial, sans-serif">which is expected to address the memory issue.<br>Now my humble question, is that something that could be set as a default env inside GDAL images? Could we add a note in the docs for awareness that the current default behavior</font></div><div><font face="arial, sans-serif">together with Spark may raise this phenomenon?</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Thank you,</font></div><div><font face="arial, sans-serif">Stelios</font></div></div>
</blockquote></div>