Sawada-san, Fujii-san,
Thank you for your reviews.
In a database with huge_pages = on / off explicitly set, if memory allocation fails, the instance cannot be started, so
Ithink that additional logs are unnecessary.
The attached patch outputs the log only when huge_pages = try, and outputs the requested size if the acquisition of
HugePages fails.
I have a completely different approach, setting GUC shared_memory_size_in_huge_pages to zero if the Huge Pages
acquisitionfails. This GUC is currently calculated independently of getting Huge Pages. The attached patch does not
includethis specification.
Regards,
Noriyoshi Shinoda
-----Original Message-----
From: Masahiko Sawada [mailto:sawada.mshk@gmail.com]
Sent: Thursday, November 11, 2021 2:45 PM
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.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>
Subject: Re: Improve logging when using Huge Pages
On Tue, Nov 2, 2021 at 1:24 AM Fujii Masao <masao.fujii@oss.nttdata.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
logonly on success when huge_pages = on/try. On the other hand, I guess that users might want to use the message to
adjustvm.nr_hugepages when it is not allocated with huge pages. In this case, it’d be better to log the message on
failurewith the request memory size (or whatever reason for the failure). That is, we end up logging such a message on
failurewhen huge_pages = on/try.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
