Re: Estimating HugePages Requirements?
От | Bossart, Nathan |
---|---|
Тема | Re: Estimating HugePages Requirements? |
Дата | |
Msg-id | C7F4DD29-549E-4EA3-87DA-D08D48B57B03@amazon.com обсуждение исходный текст |
Ответ на | Re: Estimating HugePages Requirements? (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Estimating HugePages Requirements?
|
Список | pgsql-hackers |
On 9/2/21, 10:12 PM, "Kyotaro Horiguchi" <horikyota.ntt@gmail.com> wrote: > By the way I noticed that postgres -C huge_page_size shows 0, which I > think should have the number used for the calculation if we show > huge_page_required. I would agree with this if huge_page_size was a runtime-computed GUC, but since it's intended for users to explicitly request the huge page size, it might be slightly confusing. Perhaps another option would be to create a new GUC for this. Or maybe it's enough to note that the value will be changed from 0 at runtime if huge pages are supported. In any case, it might be best to handle this separately. > I noticed that postgres -C shared_memory_size showed 137 (= 144703488) > whereas the error message above showed 148897792 bytes (142MB). So it > seems that something is forgotten while calculating > shared_memory_size. As the consequence, launching postgres setting > huge_pages_required (69 pages) as vm.nr_hugepages ended up in the > "could not map anonymous shared memory" error. Hm. I'm not seeing this with the v5 patch set, so maybe I inadvertently fixed it already. Can you check this again with v5? Nathan
В списке pgsql-hackers по дате отправления: