From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Phillip Mills <pmills(at)systemcore(dot)ca> |
Cc: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Beginning tuning |
Date: | 2007-11-07 14:30:25 |
Message-ID: | 9EBA6F47-5F7D-4A48-A31B-AB2B46256CB1@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 7-Nov-07, at 9:24 AM, Phillip Mills wrote:
> On 11/7/07, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> The problem statement is bad, because why is it a
> problem if the resources are not consumed?
>
> No, the statement is fine. It's a problem because it screws up
> capacity planning by introducing unpredictability regarding
> scaling. Since user transactions are mostly independent, our
> experience is that increasing CPUs from 1-through-4 gives
> approximately linear improvement. Adding more than 4 gives almost
> no improvement. It's not enough to say that today's performance
> requirements are met; it's also necessary to have some strategy for
> expansion.
>
> Since memory problems (other than outright failures) usually present
> as CPU and disk activity, we can eliminate that. It's not CPU,
> because that's where I'm trying to bottleneck and not getting
> there. So whether network or non-network, that leaves I/O. Which
> is why I started this conversation by asking about the I/O routines
> that I saw on the thread stacks.
>
> Kris gave me a useful answer to my actual question and I'll go on
> from there.
>
Well, if you haven't actually tuned/optimized your database/hardware
how can you make any of the above assumptions ? The number of CPU's on
a database machine does not usually correlate with database performance.
Dave
>
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2007-11-07 21:13:01 | Re: Beginning tuning |
Previous Message | Phillip Mills | 2007-11-07 14:24:57 | Re: Beginning tuning |