Re: Improve logging when using Huge Pages
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>, Jacob Champion <jchampion@timescale.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-11-07T15:14:58Z
Lists: pgsql-hackers
Hi, On 2022-11-06 14:04:29 +0700, John Naylor wrote: > I think the best thing to do is change huge_pages='on' to log a WARNING and > fallback to regular pages if the mapping fails. That way, both dev and prod > can keep the same settings, since 'on' will have both visibility and > robustness. I don't see a good reason to refuse to start -- seems like an > anti-pattern. How would on still have robustness if it doesn't actually do anything other than cause a WARNING? The use of huge pages can have very substantial effects on memory usage an performance. And it's easy to just have huge_pages fail, another program that started could have used huge pages, or some config variables was changed to incerase shared memory usage... I am strongly opposed to making 'on' fall back to not using huge pages. That's what 'try' is for. I know of people that scripted cluster start so that they start with 'on' and change the system setting of the number of huge pages according to the error message. Greetings, Andres Freund
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GUC parameter "huge_pages_status"
- a14354cac0e3 17.0 landed
-
Add check on initial and boot values when loading GUCs
- a73952b79563 16.0 cited
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited
-
Clean up some GUC declarations and comments
- 7d25958453a6 16.0 cited