On Fri, Sep 16, 2016 at 1:57 AM, Marco Pfatschbacher <marco_pfatschbac...@genua.de> 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. > > [...] > > BUGS > [...] > "Internally to the kernel, select() and pselect() work poorly if multiple > processes wait on the same file descriptor. Given that, it is rather > surprising to see that many daemons are written that way." > > [1] > At least OpenBSD and NetBSD are affected, FreeBSD rewrote > their select implementation in 8.0.
Very interesting. Perhaps that is why NetBSD shows a speedup with the kqueue patch[1] but FreeBSD doesn't. I guess that if I could get the kqueue patch to perform better on large FreeBSD systems, it would also be a solution to this problem. [1] https://www.postgresql.org/message-id/flat/CAEepm%3D2i78TOJeV4O0-0meiihiRfVQ29ur7%3DMBHxsUKaPSWeAg%40mail.gmail.com -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
