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:29:59 -0700
Message-ID: <20100908222959.GB59539@mr-paradox.net> (raw)
In-Reply-To: <4C87C77C02000025000353D2@gw.wicourts.gov>
References: <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>
<20100908220011.GA59539@mr-paradox.net>
<4C87C77C02000025000353D2@gw.wicourts.gov>
On Wed, Sep 08, 2010 at 05:27:24PM -0500, Kevin Grittner wrote:
- David Kerr <dmk@mr-paradox.net> wrote:
-
- > My assertian/hope is that the saturation point
- > on this machine should be higher than most.
-
- Here's another way to think about it -- how long do you expect your
- average database request to run? (Our top 20 transaction functions
- average about 3ms per execution.) What does that work out to in
- transactions per second? That's the TPS you can achieve *on each
- connection* if your pooler is efficient. If you've determined a
- connection pool size based on hardware resources, divide your
- anticipated requests per second by that pool size. If the result is
- less than the TPS each connection can handle, you're in good shape.
- If it's higher, you may need more hardware to satisfy the load.
-
- Of course, the only way to really know some of these numbers is to
- test your actual application on the real hardware under realistic
- load; but sometimes you can get a reasonable approximation from
- early tests or "gut feel" based on experience with similar
- applications. I strongly recommend trying incremental changes to
- various configuration parameters once you have real load, and
- monitor the impact. The optimal settings are often not what you
- expect.
-
- And if the pooling isn't producing the results you expect, you
- should look at its configuration, or (if you can) try other pooler
- products.
-
- -Kevin
-
Thanks for the insight. we're currently in performance testing of the
app. Currently, the JVM is the bottleneck, once we get past that
i'm sure it will be the database at which point I'll have the kind
of data you're talking about.
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: <20100908222959.GB59539@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