Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-jdbc by date

Next:From: Dave CramerDate: 2007-11-07 14:30:25
Subject: Re: Beginning tuning
Previous:From: Albe LaurenzDate: 2007-11-07 13:56:48
Subject: Re: Beginning tuning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group