Re: Beginning tuning

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.

In response to

Responses

Browse pgsql-jdbc by date

  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