From: | Roberto Mello <roberto(dot)mello(at)gmail(dot)com> |
---|---|
To: | Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [DOC] Add detail regarding resource consumption wrt max_connections |
Date: | 2024-01-13 17:31:42 |
Message-ID: | CAKz==bLJAwDGMMRqJSwA0Y+h10OYff73cd1pNCyzGnwYLq74BA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 12, 2024 at 3:15 PM Cary Huang <cary(dot)huang(at)highgo(dot)ca> wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting it to
> a huge number without knowing the consequences.
>
> It is true that max_connections can increase the size of proc array and
> other resources, which are allocated in the shared buffer, which also means
> less shared buffer to perform regular data operations. I am sure this is
> not the only parameter that affects the memory allocation.
> "max_prepared_xacts" can also affect the shared memory allocation too so
> the same warning message applies here as well. Maybe there are other
> parameters with similar effects.
>
> Instead of stating that higher max_connections results in higher
> allocation, It may be better to tell the user that if the value needs to be
> set much higher, consider increasing the "shared_buffers" setting as well.
>
Appreciate the review, Cary.
My goal was to inform the reader that there are implications to setting
max_connections higher. I've personally seen a user mindlessly set this to
50k connections, unaware it would cause unintended consequences.
I can add a suggestion for the user to consider increasing shared_buffers
in accordance with higher max_connections, but it would be better if there
was a "rule of thumb" guideline to go along. I'm open to suggestions.
I can revise with a similar warning in max_prepared_xacts as well.
Sincerely,
Roberto
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Koval | 2024-01-13 17:33:10 | Re: collect_corrupt_items_vacuum.patch |
Previous Message | Tom Lane | 2024-01-13 17:18:32 | Re: Recovering from detoast-related catcache invalidations |