From: David Kerr <dmk@mr-paradox.net>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: pgbench could not send data to client: Broken pipe
Date: Wed, 8 Sep 2010 15:00:11 -0700
Message-ID: <20100908220011.GA59539@mr-paradox.net> (raw)
In-Reply-To: <4C87BF0502000025000353BE@gw.wicourts.gov>
References: <20100908174629.GD40339@mr-paradox.net>
<8037.1283973026@sss.pgh.pa.us>
<4C87E3A6.8060800@2ndquadrant.com>
<20100908195654.GB49941@mr-paradox.net>
<9771.1283978128@sss.pgh.pa.us>
<20100908204443.GG49941@mr-paradox.net>
<4C87B22802000025000353B7@gw.wicourts.gov>
<20100908212056.GI49941@mr-paradox.net>
<4C87BF0502000025000353BE@gw.wicourts.gov>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dmk@mr-paradox.net, Kevin.Grittner@wicourts.gov, greg@2ndquadrant.com, tgl@sss.pgh.pa.us
Subject: Re: pgbench could not send data to client: Broken pipe
In-Reply-To: <20100908220011.GA59539@mr-paradox.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox