Re: [HACKERS] kqueue
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] kqueue |
Дата | |
Msg-id | 20181001172803.6r4nqkuzbop4tnrh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] kqueue (Matteo Beccati <php@beccati.com>) |
Ответы |
Re: [HACKERS] kqueue
|
Список | pgsql-hackers |
On 2018-10-01 19:25:45 +0200, Matteo Beccati wrote: > On 01/10/2018 01:09, Thomas Munro wrote: > > I don't know why the existence of the kqueue should make recvfrom() > > slower on the pgbench side. That's probably something to look into > > off-line with some FreeBSD guru help. Degraded performance for > > clients on the same machine does seem to be a show stopper for this > > patch for now. Thanks for testing! > > Glad to be helpful! > > I've tried running pgbench from a separate VM and in fact kqueue > consistently takes the lead with 5-10% more tps on select/prepared pgbench > on NetBSD too. > > What I have observed is that sys cpu usage is ~65% (35% idle) with kqueue, > while unpatched master averages at 55% (45% idle): relatively speaking > that's almost 25% less idle cpu available for a local pgbench to do its own > stuff. This suggest that either the the wakeup logic between kqueue and poll, or the internal locking could be at issue. Is it possible that poll triggers a directed wakeup path, but kqueue doesn't? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: