Re: Performance under contention
От
Ivan Voras
Тема
Re: Performance under contention
Дата
Msg-id
iccjub$bn0$1@dough.gmane.org
Ответ на
Re: Performance under contention (Kevin Grittner)
Список
Дерево обсуждения
Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Greg Smith <greg@2ndquadrant.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Jignesh Shah <jkshah@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Dave Crooke <dcrooke@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Віталій Тимчишин <tivv00@gmail.com>
Re: Performance under contention Ivan Voras <ivoras@freebsd.org>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Tom Lane <tgl@sss.pgh.pa.us>
Re: Performance under contention Robert Haas <robertmhaas@gmail.com>
Re: Performance under contention Jignesh Shah <jkshah@gmail.com>
On 11/22/10 02:47, Kevin Grittner wrote: > Ivan Voras wrote: > >> After 16 clients (which is still good since there are only 12 >> "real" cores in the system), the performance drops sharply > > Yet another data point to confirm the importance of connection > pooling. :-) I agree, connection pooling will get rid of the symptom. But not the underlying problem. I'm not saying that having 1000s of connections to the database is a particularly good design, only that there shouldn't be a sharp decline in performance when it does happen. Ideally, the performance should remain the same as it was at its peek. I've been monitoring the server some more and it looks like there are periods where almost all servers are in the semwait state followed by periods of intensive work - approximately similar to the "thundering herd" problem, or maybe to what Josh Berkus has posted a few days ago.
В списке pgsql-performance по дате отправления