Re: Attach to shared memory after fork()

On 4/26/21 11:56 PM, 邱宇航(烛远) wrote:
> Fork is an expensive operation[1]. The major cost is the mm(VMA
> PTE...) copy.
>
> ARM is especially weak on fork, which will invalid TLB entries one by
> one, and this is an expensive operation[2]. We could easily got 100%
> CPU on ARM machine. We also meet fork problem in x86, but not as
> serious as arm.
>
> We can avoid this by enable hugepage(and 2MB doesn’t help us under
> arm, we got a huge shared buffer), but we still think it is a problem.
>
> So I propose to remove shared buffers from postmaster and shmat them
> after fork. Not all of them, we still keep necessary shared memories
> in postmaster. Or maybe we just need to give up fork like under Windows?
>

Windows has CreateProcess, which isn't available elsewhere. If you build
with EXEC_BACKEND on *nix it will fork() followed by exec(), the classic
Unix pattern. You can benchmark that but I doubt you will like the results.

This is one of the reasons for using a connection pooler like pgbouncer,
which can vastly reduce the number of new process creations Postgres has
to do.

Better shared memory management might be more promising.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com