Re: Estimating HugePages Requirements?
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Don Seiler <don@seiler.us>, pgsql-admin <pgsql-admin@postgresql.org>
Date: 2021-06-09T19:23:50Z
Lists: pgsql-hackers
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 segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 83720568832 bytes), reduce PostgreSQL'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/
Commits
-
Silence extra logging when using "postgres -C" on runtime-computed GUCs
- 8bbf8461a3a2 15.0 landed
-
doc: Improve postgres command for shared_memory_size_in_huge_pages
- bbd4951b73ec 15.0 landed
-
Introduce GUC shared_memory_size_in_huge_pages
- 43c1c4f65eab 15.0 landed
-
Support "postgres -C" with runtime-computed GUCs
- 0c39c292077e 15.0 landed
-
Make shared_memory_size a preset option
- 3b231596ccfc 15.0 landed
-
Introduce GUC shared_memory_size
- bd1788051b02 15.0 landed
-
Move the shared memory size calculation to its own function
- 0bd305ee1d42 15.0 landed
-
Add new GUC, max_worker_processes, limiting number of bgworkers.
- 6bc8ef0b7f1f 9.4.0 cited