<div dir="ltr"><div>I don't see the point of setting a default value to an option without knowing what is it doing, and if it is really solving a problem.</div><div>At least now people can find your comment and try it if they want to.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 4 Nov 2026 at 10:20, Stelios Lagaras via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</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="color:rgb(86,163,241);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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 31, 2026 at 4:45 PM Stelios Lagaras <<a href="mailto:stelios.lagaras@gmail.com" target="_blank">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>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>