Re: Beginning tuning - Mailing list pgsql-jdbc

From Phillip Mills
Subject Re: Beginning tuning
Date
Msg-id dd0408e50711060820u2da4e1aw91ff2b7ba83b2eb2@mail.gmail.com
Whole thread Raw
In response to Re: Beginning tuning  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-jdbc
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.)




pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Beginning tuning
Next
From: Kris Jurka
Date:
Subject: Re: Beginning tuning