It doesn't seem to be slow. It certainly isn't using a lot of CPU and our DBA hasn't identified any locking on that front that would explain anything.
As I said originally, my main interest at this point is getting some idea why most user threads in the application server are sampled in I/O processing, funneled through that ReceiveChar() call. It may be irrelevant, but it would be interesting to know that one way or the other.
On 11/6/07, Dave Cramer <pg@fastcrypt.com> wrote:Phillip,
Sorry there's no one manual that will give you all the answers.
have you tuned postgres ?
is it actually slow ?
Dave
On 6-Nov-07, at 9:51 AM, Phillip Mills wrote:
I was rather hoping for a "go here, read this" answer as a starting point instead of loading people down with a bunch of details. Also, I have no evidence that JDBC is doing anything wrong; it was just the next item on my path after determining that there wasn't any application lock silliness.
But as a software sanity check:
JBoss 4.2.1 with a JBossManagedConnectionPool of 20 (but testing with fewer client threads)
PostgreSQL 8.1.9-1.2
postgresql-8.1-407.jdbc3.jar
(Linux OpenSUsE 10.2)
On 11/6/07, Dave Cramer <pg@fastcrypt.com> wrote: Phillip,
You'd have to give us a lot more information than this to help you.
machine specs ?
Postgresql version and jdbc version
postgresql configuration
are you using a db pool ?
Dave
On 6-Nov-07, at 9:09 AM, Phillip Mills wrote:
> I'm just getting started on the process of analyzing performance for
> a Java Enterprise application. (The main negative symptom at the
> moment is that it doesn't use more than three processors on an eight-
> processor system, regardless of load.)
>
> One of the first things I've noticed out of a number of thread dumps
> is that there's about an 80% chance that the stack points to I/O
> requests from PGStream.ReceiveChar(). I'm wondering about any hints
> or pointers that would help me understand whether that's expected
> behavior, or something that needs fixing, or just generally how to
> evaluate/improve JDBC performance.
>
> (Regarding the main problem, none of my threads are reported in a
> blocked state, leading to my focus on I/O.)
