Re: Unnecessary connection overhead due copy-on-write (mainly openssl)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Unnecessary connection overhead due copy-on-write (mainly openssl)
Дата
Msg-id CA+TgmoZ=RAbiJ4NRB7NXLh7tY0fa2vSuP=Of1e4-q4a+oPk-CA@mail.gmail.com
обсуждение исходный текст
Ответ на Unnecessary connection overhead due copy-on-write (mainly openssl)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Jun 5, 2025 at 3:58 PM Andres Freund <andres@anarazel.de> wrote:
> There are a few related issues where we ourselves to blame. The most prominent
> one is that we go around and delete PostmasterContext in child processes. That
> however doesn't really save memory, as the memory is still needed in
> postmaster, we just end up causing page faults that trigger copy-on-write.

If we're not going to bother deleting PostmasterContext, we could also
skip creating it in the first place. After all, if the storage isn't
actually freed, then we won't know whether things are leaking into
that context that actually do get used in child processes, so there's
really no point.

The current structure amounts to a design decision that at some point
in time the postmaster might allocate an amount of memory that we need
to free in child processes, whether or not that's actually true
currently. Not deleting it any more -- or not having it any more -- is
deciding that it shouldn't ever allocate a significant amount of
memory.

I don't know whether that's a good bet, but I wouldn't be surprised. I
think we've talked about wanting to move some things that the
postmaster currently does to a separate process, whether for
multi-threading or other reasons. But, if we do take the position that
the postmaster shouldn't allocate a significant amount of stuff, we
might want to add some checks someplace to prove that it doesn't.
Otherwise, it might get broken by some future patch without anybody
noticing.

(For clarity, I'm not attempting to insist on anything here, just
sharing a few thoughts that come to mind.)

--
Robert Haas
EDB: http://www.enterprisedb.com



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