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
