Re: Improve logging when using Huge Pages
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: noriyoshi.shinoda@hpe.com
Cc: masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org,
rjuju123@gmail.com, tgl@sss.pgh.pa.us, pryzby@telsasoft.com
Date: 2021-09-09T05:34:42Z
Lists: pgsql-hackers
Thanks! At Wed, 8 Sep 2021 07:52:35 +0000, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com> wrote in > Hello, > > Thank you everyone for comments. > I have attached a patch that simply changed the message like the advice from Horiguchi-san. > > > Even with the patch, there are still some cases where huge pages is disabled silently. We should report something even in these cases? > > For example, in the platform where huge pages is not supported, it's silently disabled when huge_pages=try. > > The area where this patch is written is inside the "#ifdef MAP_HUGETLB #endif" block. > For this reason, I think it is excluded from binaries created in an environment that does not have the MAP_HUGETLB macro. Ah, right. > > One big concern about the patch is that log message is always reported when shared memory fails to be allocated with huge pages enabled when huge_pages=try. Since > > huge_pages=try is the default setting, many users would see this new log message whenever they start the server. Those who don't need huge pages but just use the default > > setting might think that such log messages would be noisy. > > This patch is meant to let the admin know that HugePages isn't being used, so I'm sure you're right. I have no idea what to do so far. It seems *to me* sufficient. I'm not sure what cases CreateFileMapping return ERROR_NO_SYSTEM_RESOURCES when non-huge page can be allocated successfully, though, but that doesn't matter much, maybe. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GUC parameter "huge_pages_status"
- a14354cac0e3 17.0 landed
-
Add check on initial and boot values when loading GUCs
- a73952b79563 16.0 cited
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited
-
Clean up some GUC declarations and comments
- 7d25958453a6 16.0 cited