Re: Auto-tune shared_buffers to use available huge pages

On Thu, Jan 29, 2026 at 12:43 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> The user could achieve the same effect by setting shared_buffers to
> the same value as shared_buffers_autotune_target. What's the
> difference?
>
> Further they can use -C and -c options to postgres to decide which
> setting of shared_buffers will consume the desired amount of available
> memory. That is quite quick and easy.
>
> I may be missing some usecase where such runtime autotuning is useful.

To give a concrete example, I have a pod with 30GB of huge pages. If I
start postgres with "postgres -cshared_buffers=30GB -chuge_pages=on",
it fails with:

FATAL: could not map anonymous shared memory: Cannot allocate memory
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory, swap space, or huge pages.
To reduce the request size (currently 32988200960 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing "shared_buffers"
or "max_connections".

With all the additional memory requests, ~30.7GB is requested. I need
to lower the shared_buffers to 29.2GB to be able to start, but this is
imprecise and with this value, I'm off by ~60 huge pages in the final
allocation. The huge pages that were not part of the mmap are
completely wasted since it can't even be used by Linux for the page
cache.

So the idea behind the autotune logic is to be able to provide a
specific amount of shared memory to target and adjust shared_buffers
accordingly. The huge pages I have reserved for the pod are only
useful if they are used in the shared memory mmap, so the autotune
makes sure that nothing is wasted.

shared_buffers_autotune_target is probably confusing,
shared_memory_autotune_target might be a more fitting name.