Re: pgbench could not send data to client: Broken pipe
От | David Kerr |
---|---|
Тема | Re: pgbench could not send data to client: Broken pipe |
Дата | |
Msg-id | 20100908220011.GA59539@mr-paradox.net обсуждение исходный текст |
Ответ на | Re: pgbench could not send data to client: Broken pipe ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: pgbench could not send data to client: Broken
pipe
|
Список | pgsql-performance |
On Wed, Sep 08, 2010 at 04:51:17PM -0500, Kevin Grittner wrote: - David Kerr <dmk@mr-paradox.net> wrote: - - > Hmm, i'm not following you. I've got 48 cores. that means my - > sweet-spot active connections would be 96. - - Plus your effective spindle count. That can be hard to calculate, - but you could start by just counting spindles on your drive array. We've got this weird LPAR thing at our hosting center. it's tough for me to do. - > Now if i were to connection pool that out to 15 people per - > connection, - - Where did you get that number? We routinely route hundreds of - requests per second (many of them with 10 or 20 joins) from five or - ten thousand connected users through a pool of 30 connections. It - started out bigger, we kept shrinking it until we hit our sweet - spot. The reason we started bigger is we've got 40 spindles to go - with the 16 cores, but the active portion of the database is cached, - which reduces our effective spindle count to zero. That's encouraging. I don't remember where I got the number from, but my pooler will be Geronimo, so i think it came in that context. - > that's 1440 users "total" able to use my app at one time. (with - > only 96 actually doing anything). not really great for a web-based - > app that will have millions of users accessing it when we're fully - > ramped up. - - Once you have enough active connections to saturate the resources, - adding more connections just adds contention for resources and - context switching cost -- it does nothing to help you service more - concurrent users. The key is, as I mentioned before, to have the - pooler queue requests above the limit and promptly get them running - as slots are freed. Right, I understand that. My assertian/hope is that the saturation point on this machine should be higher than most. Dave
В списке pgsql-performance по дате отправления: