Re: Beginning tuning

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(at)fastcrypt(dot)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(at)fastcrypt(dot)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.)
> >
> >
>
>