Re: Performance under contention
От | Jignesh Shah |
---|---|
Тема | Re: Performance under contention |
Дата | |
Msg-id | AANLkTinzSxBeV6DSg-5JgXd_t4RKyZ_mxw+_-_0BNreg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance under contention (Ivan Voras <ivoras@freebsd.org>) |
Ответы |
Re: Performance under contention
|
Список | pgsql-performance |
On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras <ivoras@freebsd.org> wrote: > 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. > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > Try it with systemtap or dtrace and see if you find the same bottlenecks as I do in http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html I will probably retry it with pgBench and see what I find .. Regards, Jignesh
В списке pgsql-performance по дате отправления: