| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Auto-tune shared_buffers to use available huge pages |
| Date: | 2026-01-29 14:46:06 |
| Message-ID: | CAExHW5tqxiiC9px-MPmSVFrEPVgHVWWsd7FcROupMFO=H=FFcQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 29, 2026 at 7:41 PM Anthonin Bonnefoy
<anthonin(dot)bonnefoy(at)datadoghq(dot)com> wrote:
>
> 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.
With -C you can quickly find out how much shared memory and huge pages
are being used without starting the server. E.g.
$ postgres -D $DataDir -c shared_buffers="128kB" -C "shared_memory_size"
9
$ postgres -D $DataDir -c shared_buffers="150MB" -C "shared_memory_size"
173
$ postgres -D $DataDir -c shared_buffers="150MB" -C
"shared_memory_size_in_huge_pages"
87
You could write a script to find the optimal value of shared_buffers,
that will consume memory optimally; auto-tuning it without starting
the server.
Isn't that sufficient?
--
Best Wishes,
Ashutosh Bapat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aditya Kamath | 2026-01-29 14:52:54 | RE: AIX support |
| Previous Message | Andrew Dunstan | 2026-01-29 14:37:36 | Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote |