Re: Beginning tuning

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.

-O