Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect if postgres was started without huge pages when huge_page = try #296

Open
blogh opened this issue Aug 27, 2021 · 11 comments
Open

Detect if postgres was started without huge pages when huge_page = try #296

blogh opened this issue Aug 27, 2021 · 11 comments

Comments

@blogh
Copy link
Collaborator

blogh commented Aug 27, 2021

Sometimes we cannot afford to not start if we don't have huge pages.
It would be neat to have a service to detect when we couldn't start with the huge pages when huge_page = try.

@rjuju
Copy link
Member

rjuju commented Aug 27, 2021

I'm a bit dubious about this one. Is there a way to know if postgres could map its shmem with huge pages at the sql level? If not, it means that it's a check that would only be possible is check_pgactivity is run locally which greatly limits the usefulness.

@Krysztophe
Copy link
Collaborator

I suppose this is not something visible from pg_shmem_allocations ?

Anyway: if we have to dig into /proc, that would not be the 1st service that needs to run on the DB server.

@blogh
Copy link
Collaborator Author

blogh commented Sep 3, 2021

I found this : https://access.redhat.com/solutions/320303?sc_cid=cp
It's not usable everywhere for instance RH 5 has no KernelPageSize.

It whould be neat to be able to fetch this info directly from postgres.

@rjuju
Copy link
Member

rjuju commented Sep 3, 2021

I'm afraid that it's not that reliable. It's probably ok for a postgres dedicated server, but as soon as you have other services (including other postgres instances), you can't use those numbers anymore.

I agree that having a way to have an SQL API for that in postgres would be nice. There was a thread about raising the log level for the messages about failed attempt to use huge pages a few days ago and I already tried to add this point to the discussion.

@blogh
Copy link
Collaborator Author

blogh commented Sep 3, 2021

great ! thanks

@Krysztophe
Copy link
Collaborator

In PG15, we now have shared_memory_size and shared_memory_size_in_huge_pages.

Assuming a single instance on a dedicated server, the service could check that most SB are huge pages.
(ie checking that shared_memory_size_in_huge_pages * huge_page_size = shared_buffers,
with a 10% tolerance just in case?)

With Huge pages, I always fear that PG does not find the HP for whatever reason, and use only 4k pages, wasting memory.
Having such an alert would be less radical than huge_pages = on and a failure to start.

Problem: PG does not return the HP size value, huge_page_size is 0 by default.
It could be a parameter of the service, it could be autodetected in /proc/meminfo, or the service could simply fail if huge_page_size is not defined.

@frost242
Copy link
Member

frost242 commented Jun 15, 2023

I'm not confident that shared_memory_size_in_huge_pages could be used to determine if PostgreSQL was started with all shared memory in huge pages. This GUC is just here to tell how much huge pages a PostgreSQL instance will need to allocate, it's just a helper to tune the system.

@Krysztophe
Copy link
Collaborator

You-re right, shared_memory_size_in_huge_pages is the desired size, not what is in HP.

@rjuju
Copy link
Member

rjuju commented Jul 6, 2023

FTR upstream finally decided to properly report whether huge pages are used or not, see postgres/postgres@a14354c.

We will be able to write a proper check for that starting with pg 17.

@Krysztophe
Copy link
Collaborator

That service should be possible with PG17 : https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a14354cac

@rjuju
Copy link
Member

rjuju commented Sep 27, 2024

Isn't that the exact same commit I mentioned a year ago?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants