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 по дате отправления: