RE: Improve logging when using Huge Pages
Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>
From: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>
To: "masao.fujii@oss.nttdata.com" <masao.fujii@oss.nttdata.com>,
"Kyotaro
Horiguchi" <horikyota.ntt@gmail.com>
Cc: "pryzby@telsasoft.com" <pryzby@telsasoft.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
"rjuju123@gmail.com" <rjuju123@gmail.com>,
"tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Date: 2021-09-20T08:55:13Z
Lists: pgsql-hackers
Attachments
- huge_pages_log_v5.diff (application/octet-stream) patch v5
Hi, Thank you for your comment. > I was afraid that logging the message like "could not ..." every time when the server starts up would surprise users unnecessarily. > Because the message sounds like it reports a server error. Fujii-san, I was worried about the same thing as you. So the attached patch gets the value of the kernel parameter vm.nr_hugepages, and if it is the default value of zero, the log level is the same as before. On the other hand, if any value is set, the level is set to LOG. I hope I can find a better message other than this kind of implementation. Regards, Noriyoshi Shinoda -----Original Message----- From: Kyotaro Horiguchi [mailto:horikyota.ntt@gmail.com] Sent: Friday, September 17, 2021 1:15 PM To: masao.fujii@oss.nttdata.com Cc: pryzby@telsasoft.com; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>; pgsql-hackers@postgresql.org; rjuju123@gmail.com; tgl@sss.pgh.pa.us Subject: Re: Improve logging when using Huge Pages At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in > > > On 2021/09/08 11:17, Kyotaro Horiguchi wrote: > > I don't dislike the message, but I'm not sure I like the message is > > too verbose, especially about it has DETAILS. It seems to me > > something like the following is sufficient, or I'd like see it even > > more concise. > > "fall back anonymous shared memory to non-huge pages: required %zu > > bytes for huge pages" > > If we emit an error message for other than mmap failure, it would be > > like the following. > > "fall back anonymous shared memory to non-huge pages: huge pages not > > available" > > How about simpler message like "disabling huge pages" or "disabling > huge pages due to lack of huge pages available"? Honestly, I cannot have conficence on my wording, but "disabling huge pages" souds like somthing that happens on the OS layer. "did not use/gave up using huge pages for anounymous shared memory" might work well, I'm not sure, though... 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