From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, nathandbossart(at)gmail(dot)com, jchampion(at)timescale(dot)com, john(dot)naylor(at)enterprisedb(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, noriyoshi(dot)shinoda(at)hpe(dot)com, pgsql-hackers(at)postgresql(dot)org, rjuju123(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com |
Subject: | Re: Improve logging when using Huge Pages |
Date: | 2023-03-28 00:35:30 |
Message-ID: | ZCI2UlFUxFz80otI@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 23, 2023 at 08:50:50PM -0500, Justin Pryzby wrote:
> I'm sure it's possible, but it's also not worth writing a special
> implementation just to handle huge_pages_active, which is better written
> in 30 lines than in 300 lines.
>
> If we needed to avoid using a GUC, maybe it'd work to add
> huge_pages_active to PGShmemHeader. But "avoid using gucs at all costs"
> isn't the goal, and using a GUC parallels all the similar, and related
> things without needing to allocate extra bits of shared_memory.
Yeah, I kind of agree that the complications are not appealing
compared to the use case. FWIW, I am fine with just using "unknown"
even under -C because we don't know the status without the mmpa()
call. And we don't want to assign what would be potentially a bunch
of memory when running that.
> This goes back to using a GUC, and:
>
> - removes GUC_RUNTIME_COMPUTED, since that causes a useless error when
> using -C if the server is running, rather than successfully printing
> "unknown".
> - I also renamed it from huge_pages_active = {true,false,unknown} to
> huge_pages_STATUS = {on,off,unknown}. This parallels huge_pages,
> which is documented to accept values on/off/try. Also, true/false
> isn't how bools are displayed.
> - I realized that the rename suggested implementing it as an enum GUC,
> and re-using the existing HUGE_PAGES_{ON,OFF} values (and adding an
> "UNKNOWN"). Maybe this also avoids Stephen's earlier objection to
> using a string ?
huge_pages_status is OK here, as is reusing the enum struct to avoid
an unnecessary duplication.
> I mis-used cirrusci to check that the GUC does work correctly under
> windows.
You mean that you abused of it in some custom branch running the CI on
github? If I may ask, what did you do to make sure that huge pages
are set when re-attaching a backend to a shmem area?
> If there's continuing aversions to using a GUC, please say so, and try
> to suggest an alternate implementation you think would be justified.
> It'd need to work under windows with EXEC_BACKEND.
Looking at the patch, it seems like that this should work even for
EXEC_BACKEND on *nix when a backend reattaches.. It may be better to
be sure of that, as well, if it has not been tested.
+++ b/src/backend/port/win32_shmem.c
@@ -327,6 +327,10 @@ retry:
Sleep(1000);
continue;
}
+
+ SetConfigOption("huge_pages_status", (flProtect & SEC_LARGE_PAGES) ?
+ "on" : "off", PGC_INTERNAL, PGC_S_DYNAMIC_DEFAULT)
Perhaps better to just move that at the end of PGSharedMemoryCreate()
for WIN32?
+ <varlistentry id="guc-huge-pages-status" xreflabel="huge_pages_status">
+ <term><varname>huge_pages_status</varname> (<type>enum</type>)
+ <indexterm>
+ <primary><varname>huge_pages_status</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Reports the state of huge pages in the current instance.
+ See <xref linkend="guc-huge-pages"/> for more information.
+ </para>
+ </listitem>
+ </varlistentry>
The patch needs to provide more details about the unknown state, IMO,
to make it crystal-clear to the users what are the limitations of this
GUC, especially regarding the fact that this is useful when "try"-ing
to allocate huge pages, and that the value can only be consulted after
the server has been started.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-03-28 01:07:09 | Re: Add pg_walinspect function with block info columns |
Previous Message | Michael Paquier | 2023-03-28 00:13:10 | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |