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 I think 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 Huge Pages fails. I have a completely different approach, setting GUC shared_memory_size_in_huge_pages to zero if the Huge Pages acquisition fails. This GUC is currently calculated independently of getting Huge Pages. The attached patch does not include this specification. Regards, Noriyoshi Shinoda -----Original Message----- From: Masahiko Sawada [mailto:sawada.m...@gmail.com] Sent: Thursday, November 11, 2021 2:45 PM To: Fujii Masao <masao.fu...@oss.nttdata.com> Cc: Justin Pryzby <pry...@telsasoft.com>; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shin...@hpe.com>; PostgreSQL-development <pgsql-hack...@postgresql.org>; Julien Rouhaud <rjuju...@gmail.com>; Tom Lane <t...@sss.pgh.pa.us>; Kyotaro Horiguchi <horikyota....@gmail.com> Subject: Re: Improve logging when using Huge Pages On Tue, Nov 2, 2021 at 1:24 AM Fujii Masao <masao.fu...@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 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/
huge_pages_log_v10.diff
Description: huge_pages_log_v10.diff
