From: | Marco Pfatschbacher <Marco_Pfatschbacher(at)genua(dot)de> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: Keep one postmaster monitoring pipe per process |
Date: | 2016-09-16 07:55:48 |
Message-ID: | 20160916075547.GC15576@genua.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 15, 2016 at 12:26:16PM -0700, Andres Freund wrote:
> Hi,
>
> On 2016-09-15 15:57:55 +0200, Marco Pfatschbacher wrote:
> > the current implementation of PostmasterIsAlive() uses a pipe to
> > monitor the existence of the postmaster process.
> > One end of the pipe is held open in the postmaster, while the other end is
> > inherited to all the auxiliary and background processes when they fork.
> > This leads to multiple processes calling select(2), poll(2) and read(2)
> > on the same end of the pipe.
> > While this is technically perfectly ok, it has the unfortunate side
> > effect that it triggers an inefficient behaviour[0] in the select/poll
> > implementation on some operating systems[1]:
> > The kernel can only keep track of one pid per select address and
> > thus has no other choice than to wakeup(9) every process that
> > is waiting on select/poll.
>
> Yikes, that's a pretty absurd implementation.
Not when you take into account that it's been written over 20 years ago ;)
> Does openbsd's kqueue implementation have the same issue? There's
> http://archives.postgresql.org/message-id/CAEepm%3D37oF84-iXDTQ9MrGjENwVGds%2B5zTr38ca73kWR7ez_tA%40mail.gmail.com
Looks ok, but your milage may vary. I've seen strange subtle bugs
using kqeue..
struct kevent {
__uintptr_t ident; /* identifier for this event */
short filter; /* filter for event */
u_short flags;
u_int fflags;
quad_t data;
void *udata; /* opaque user data identifier */
};
> > Attached patch avoids the select contention by using a
> > separate pipe for each auxiliary and background process.
>
> I'm quite unenthusiastic about forcing that many additional file
> descriptors onto the postmaster...
In our use case it's about 30.
> I'm not quite sure I understand why this an issue here - there shouldn't
> ever be events on this fd, so why is the kernel waking up all processes?
> It'd kinda makes sense it'd wake up all processes if there's one
> waiting, but ... ?
Every read is an event, and that's what PostmasterIsAlive does.
Marco
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2016-09-16 08:31:30 | Re: IF (NOT) EXISTS in psql-completion |
Previous Message | Marco Pfatschbacher | 2016-09-16 07:46:43 | Re: PATCH: Keep one postmaster monitoring pipe per process |