Re: Improve logging when using Huge Pages

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)postgresql(dot)org, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: Improve logging when using Huge Pages
Date: 2022-11-06 13:04:26
Message-ID: 20221106130426.GG16921@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 06, 2022 at 02:04:29PM +0700, John Naylor wrote:
> On Thu, Nov 3, 2022 at 8:11 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> >
> > I wonder if the problem here is that people are reluctant to add noise
> > to every starting system. There are people who have not configured
> > their system and don't want to see that noise, and then some people
> > have configured their system and would like to know about it if it
> > doesn't work so they can be aware of that, but don't want to use "off"
> > because they don't want a hard failure. Would it be better if there
> > were a new level "try_log" (or something), which only logs a message
> > if it tries and fails?
>
> 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.

I'm glad to see there's still discussion on this topic :)

Another idea is to add a RUNTIME_COMPUTED GUC to *display* the state of
huge pages, so I can stop parsing /proc/maps to find it.

--
Justin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2022-11-06 13:51:52 Re: Small TAP improvements
Previous Message Ian Lawrence Barwick 2022-11-06 12:23:01 Re: [patch] Have psql's \d+ indicate foreign partitions