Re: [DOC] Add detail regarding resource consumption wrt max_connections

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: [DOC] Add detail regarding resource consumption wrt max_connections
Дата
Msg-id CABV9wwPtyKu4z=i7bTA1OCHEQmQ1+=s_St1HCU3c9-d5pdsc2g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [DOC] Add detail regarding resource consumption wrt max_connections  (Michael Banck <mbanck@gmx.net>)
Ответы Re: [DOC] Add detail regarding resource consumption wrt max_connections  (Michael Banck <mbanck@gmx.net>)
Список pgsql-hackers
On Fri, Mar 8, 2024 at 10:47 AM Michael Banck <mbanck@gmx.net> wrote:
>
> Hi,
>
> On Fri, Jan 12, 2024 at 10:14:38PM +0000, Cary Huang 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.
>
> Right, and I think it might be useful to log (i.e. at LOG not DEBUG3
> level, with a nicer message) the amount of memory we allocate on
> startup, that is just one additional line per instance lifetime but
> might be quite useful to admins. Or maybe two lines if we log whether we
> could allocate it as huge pages or not as well:
>
> |2024-03-08 16:46:13.117 CET [237899] DEBUG:  invoking IpcMemoryCreate(size=145145856)
> |2024-03-08 16:46:13.117 CET [237899] DEBUG:  mmap(146800640) with MAP_HUGETLB failed, huge pages disabled: Cannot
allocatememory 
>

If we were going to add these details (and I very much like the idea),
I would advocate that we put it somewhere more permanent than a single
log entry at start-up. Given that database up-times easily run months
and sometimes years, it is hard to imagine we'd always have access to
the log files to figure this out on any actively running systems.

Robert Treat
https://xzilla.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Andrey M. Borodin"
Дата:
Сообщение: Re: UUID v7
Следующее
От: Magnus Hagander
Дата:
Сообщение: pg_dump include/exclude fails to error