Re: [HACKERS] kqueue
От | Matteo Beccati |
---|---|
Тема | Re: [HACKERS] kqueue |
Дата | |
Msg-id | fa1efd20-60a3-90ef-7b75-1c7d5cd28d03@beccati.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] kqueue (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] kqueue
|
Список | pgsql-hackers |
Hi Thomas, 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. Running pgbench locally shows an average 47% usr / 53% sys cpu distribution w/ kqueue vs more like 50-50 w/ vanilla, so I'm inclined to think that's the reason why we see a performance drop instead. Thoguhts? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
В списке pgsql-hackers по дате отправления: