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 по дате отправления:

Предыдущее
От: Matteo Beccati
Дата:
Сообщение: Re: [HACKERS] kqueue
Следующее
От: Tom Lane
Дата:
Сообщение: has_column_privilege behavior (was Re: Assert failed in snprintf.c)