Re: Beginning tuning

Поиск
Список
Период
Сортировка
От Phillip Mills
Тема Re: Beginning tuning
Дата
Msg-id dd0408e50711060651l612c941fr626777f905fed46a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Beginning tuning  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: Beginning tuning  (Dave Cramer <pg@fastcrypt.com>)
Список pgsql-jdbc
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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Beginning tuning
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Beginning tuning