On Wed, Jun 9, 2021 at 9:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Magnus Hagander <magnus@hagander.net> writes:
> > I wonder how hard it would be to for example expose that through a
> > commandline switch or tool.
>
> Just try to start the server and see if it complains.
> For instance, with shared_buffers=10000000 I get
>
> 2021-06-09 15:08:56.821 EDT [1428121] FATAL: could not map anonymous shared memory: Cannot allocate memory
> 2021-06-09 15:08:56.821 EDT [1428121] HINT: This error usually means that PostgreSQL's request for a shared memory
segmentexceeded available memory, swap space, or huge pages. To reduce the request size (currently 83720568832 bytes),
reducePostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
>
> Of course, if it *does* start, you can do the other thing.
Well, I have to *stop* the existing one first, most likely, otherwise
there won't be enough huge pages (or indeed memory) available. And if
then doesn't start, you're looking at extended downtime.
You can automate this to minimize it (set the value in the conf, stop
old, start new, if new doesn't start then stop new, reconfigure, start
old again), but it's *far* from friendly.
This process works when you're setting up a brand new server with
nobody using it. It doesn't work well, or at all, when you actually
have active users on it..
> Admittedly, we could make that easier somehow; but if it took
> 25 years for somebody to ask for this, I'm not sure it's
> worth creating a feature to make it a shade easier.
We haven't had huge page support for 25 years, "only" since 9.4 so
about 7 years.
And for every year that passes, huge pages become more interesting in
that in general memory sizes increase so the payoff of using them is
increased.
Using huge pages *should* be a trivial improvement to set up. But it's
in my experience complicated enough that many just skip it simply for
that reason.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/