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