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

Re: Beginning tuning

From: Oliver Jowett <oliver(at)opencloud(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 21:13:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Phillip Mills wrote:

> 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.

My guesses would be:

(1) you've run out of disk bandwidth. Have you measured disk I/O rate on 
the server vs. query rate as a starting point?

(2) you're hitting your hardware's limit on the rate at which it can 
sync your disks (which in turn is related to physical disk access time). 
A simple test for that is to turn off fsync (danger, danger, testing 
purposes only) and see if that removes the performance cap. Or run off a 
purely in-memory filesystem if that's practical for your dataset.

(3) you don't have enough concurrency in your test setup to soak up 
query latency. Try more concurrent queries (= more threads in Java land)

All of the above would show up as "JDBC client blocking waiting for the 
server to respond".

You'll probably find a more suitable audience on the pgsql-performance 
list, though, unless you have something pointing the finger at the JDBC 
driver specifically.


In response to

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2007-11-07 21:24:44
Subject: Re: Beginning tuning
Previous:From: Dave CramerDate: 2007-11-07 14:30:25
Subject: Re: Beginning tuning

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