Date: Tue, 24 Jan 2023 19:37:29 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com,
	tgl@sss.pgh.pa.us, john.naylor@enterprisedb.com,
	noriyoshi.shinoda@hpe.com, jchampion@timescale.com,
	sawada.mshk@gmail.com, masao.fujii@oss.nttdata.com,
	pgsql-hackers@postgresql.org, rjuju123@gmail.com
Subject: Re: Improve logging when using Huge Pages
Message-ID: <20230125013728.GK13860@telsasoft.com>
References: <20221107151458.6puzamerxti2y5in@awork3.anarazel.de>
 <3239882.1667836576@sss.pgh.pa.us>
 <CA+hUKGKRfzOH9gji-W7j=iKDQ50AjtGSsUfybNxeNVk+uy2gcg@mail.gmail.com>
 <20221109.114757.661491395677294771.horikyota.ntt@gmail.com>
 <Y2s0wCFgDv4LXzIW@paquier.xyz>
 <20230124012100.GB13860@telsasoft.com>
 <20230124013335.7u75j75ze5o7uh2l@awork3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230124013335.7u75j75ze5o7uh2l@awork3.anarazel.de>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20230125013728.GK13860%40telsasoft.com>
Precedence: bulk

On Mon, Jan 23, 2023 at 05:33:35PM -0800, Andres Freund wrote:
> Hi,
> 
> On 2023-01-23 19:21:00 -0600, Justin Pryzby wrote:
> > Michael seemed to support this idea and nobody verbalized hatred of it,
> > so I implemented it.  In v15, we have shared_memory_size_in_huge_pages,
> > so this adds effective_huge_pages.
> > 
> > Feel free to suggest a better name.
> 
> Hm. Should this be a GUC? There's a reason shared_memory_size_in_huge_pages is
> one - it's so it's accessible via -C. But here we could make it a function or
> whatnot as well.

I have no strong opinion, but a few minor arguments in favour of a GUC:

  - the implementation parallels huge_pages, huge_page_size, and
    shared_memory_size_in_huge_pages;
  - it's short;
  - it's glob()able with the others:

postgres=# \dconfig *huge*
     List of configuration parameters
            Parameter             | Value 
----------------------------------+-------
 effective_huge_pages             | off
 huge_pages                       | try
 huge_page_size                   | 0
 shared_memory_size_in_huge_pages | 12

> I'm ok with this being a GUC, it doesn't feel elegant, but I suspect there's
> no realistic elegant answer.

BTW, I didn't realize it when I made the suggestion, nor when I wrote
the patch, but a GUC was implemented in the v2 patch.
https://www.postgresql.org/message-id/TU4PR8401MB1152CB4FEB99658BC6B35543EECF9%40TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM

The original proposal was to change the elog(DEBUG1, "mmap..") to LOG,
and the thread seems to have derailed out of concern for a hypothetical
user who was adverse to an additional line of log messages during server
start.

I don't share that concern, but GUC or function seems better anyway,
since the log message is not easily available (except maybe, sometimes,
shortly after the server restart).  I'm currently checking for huge
pages in a nagios script by grepping /proc/pid/smaps (I *could* make use
of a logfile if that was available, but it's better if it's a persistent
state/variable).

Whether it's a GUC or a function, I propose to name it hugepages_active.
If there's no objections, I'll add to the CF.

-- 
Justin