Re: Improve logging when using Huge Pages

On Tue, Nov 2, 2021 at 1:24 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
>
>
> On 2021/10/29 7:05, Justin Pryzby wrote:
> > Hi,
> >
> > On Wed, Oct 27, 2021 at 06:39:46AM +0000, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> >> Thank you for your comment.
> >> The attached patch stops message splitting.
> >> This patch also limits the timing of message output when huge_pages = try and HugePages is not used.
>
> The log message should be reported even when huge_pages=off (and huge pages
> are not used)? Otherwise we cannot determine whether huge pages are actually
> used or not when no such log message is found in the server log.
>
> Or it's simpler and more intuitive to log the message "Anonymous shared
> memory was allocated with huge pages" only when huge pages are successfully
> requested? If that message is logged, we can determine that huge pages are
> used whatever the setting is. OTOH, if there is no such message, we can
> determine that huge pages are not used for some reasons, e.g., OS doesn't
> support huge pages, shared_memory_type is not set to mmap, etc.

If users want to know whether the shared memory is allocated with huge
pages, I think it’s more intuitive to emit the log only on success
when huge_pages = on/try. On the other hand, I guess that users might
want to use the message to adjust vm.nr_hugepages when it is not
allocated with huge pages. In this case, it’d be better to log the
message on failure with the request memory size (or whatever reason
for the failure). That is, we end up logging such a message on failure
when huge_pages = on/try.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/