Hi, On 2026-02-09 14:41:12 +0100, Jakub Wartak wrote: > I've thought that the potential main reason of the hit would be slow fork(), > so I had an idea why we fork() with majority of memory being shared_buffers > (BufferBlocks) that is not really used inside postmaster itself > (I mean it does not use it, only backends do use it). I've thought it could > be cool if we could just init the memory, leave just the fd from memfd_create > for s_b around (that is unmap() BufferBlocks from the postmaster thus lowering > its RSS/smaps footprint) and then on fork() the fork() would NOT have to copy > that big kernel VMA for shared_buffers. Instead (in theory - only the fd that > is the reference - thereby we could increase the scalability of the > postmaster > (kernel would need to perform less work during fork()). Later on, the classic > backends on their side would mmap() the region back from the fd created > earlier > (in postmaster) using memfd_create(2), but that would happen as part of many > backends (so workload would be spread across many CPUs).
FWIW, when looking at this in the past there were two noteworthy things: 1) The main driver of slowness was *NOT* shared buffers, but all the libraries we link to. Particularly openssl makes things a *lot* slower, due to all the small mappings it creates. If you compare the fork speed of a postgres with minimal dependencies and one with all the dependencies, you'll see a huge difference. The reason that openssl is so bad is that it modifies data in all the copy-on-write mappings during process exit processing. See [1]. 2) A lot of the slowness isn't actually from the fork overhead itself, but from fork competing with the processing during process exit, as both taking conflicting locks. I seriously doubt it's a good idea to delay the mmapping until after the fork, that'll just lead to more different mappings to exist that then all need to be tracked separately by the kernel. Greetings, Andres Freund [1] https://postgr.es/m/hgs2vs74tzxigf2xqosez7rpf3ia5e7izalg5gz3lv3nqfptxx%40thanmprbpl4e
