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, rjuju123@gmail.com,
pgsql-hackers@postgresql.org
Date: 2021-09-03T07:49:34Z
Lists: pgsql-hackers
Hello.
At Fri, 3 Sep 2021 06:28:58 +0000, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com> wrote in
> Fujii-san, Julien-san
>
> Thank you very much for your comment.
> I followed your comment and changed the elog function to ereport function and also changed the log level. The output message is the same as in the case of non-HugePages memory acquisition failure.I did not simplify the error messages as it would have complicated the response to the preprocessor.
>
> > I agree that the message should be promoted to a higher level. But I
> > think we should also make that information available at the SQL level,
> > as the log files may be truncated / rotated before you need the info,
> > and it can be troublesome to find the information at the OS level, if
> > you're lucky enough to have OS access.
>
> In the attached patch, I have added an Internal GUC 'using_huge_pages' to know that it is using HugePages. This parameter will be True only if the instance is using HugePages.
IF you are thinking to show that in GUC, you might want to look into
the nearby thread [1], especially about the behavior when invoking
postgres -C using_huge_pages. (Even though the word "using" in the
name may suggest that the server is running, but I don't think it is
neat that the variable shows "no" by the command but shows "yes" while
the same server is running.)
I have some comment about the patch.
- if (huge_pages == HUGE_PAGES_TRY && ptr == MAP_FAILED)
- elog(DEBUG1, "mmap(%zu) with MAP_HUGETLB failed, huge pages disabled: %m",
- allocsize);
+ if (ptr != MAP_FAILED)
+ using_huge_pages = true;
+ else if (huge_pages == HUGE_PAGES_TRY)
+ ereport(LOG,
+ (errmsg("could not map anonymous shared memory: %m"),
+ (mmap_errno == ENOMEM) ?
+ errhint("This error usually means that PostgreSQL's request "
If we set huge_pages to try and postgres falled back to regular pages,
it emits a large message relative to its importance. The user specifed
that "I'd like to use huge pages, but it's ok if not available.", so I
think the message should be far smaller. Maybe just raising the
DEBUG1 message to LOG along with moving to ereport might be
sufficient.
- elog(DEBUG1, "CreateFileMapping(%zu) with SEC_LARGE_PAGES failed, "
- "huge pages disabled",
- size);
+ ereport(LOG,
+ (errmsg("could not create shared memory segment: error code %lu", GetLastError()),
+ errdetail("Failed system call was CreateFileMapping(size=%zu, name=%s).",
+ size, szShareMem)));
It doesn't seem to be a regular user-facing message. Isn't it
sufficient just to raise the log level to LOG?
[1] https://www.postgresql.org/message-id/20210903.141206.103927759882272221.horikyota.ntt%40gmail.com
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