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: | 47322A5D.2080606@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2007-11-07 21:24:44 | Re: Beginning tuning |
Previous Message | Dave Cramer | 2007-11-07 14:30:25 | Re: Beginning tuning |