From: | "Phillip Mills" <pmills(at)systemcore(dot)ca> |
---|---|
To: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Beginning tuning |
Date: | 2007-11-07 14:24:57 |
Message-ID: | dd0408e50711070624o943b344hc212bbb0b3f49f80@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2007-11-07 14:30:25 | Re: Beginning tuning |
Previous Message | Albe Laurenz | 2007-11-07 13:56:48 | Re: Beginning tuning |