Re: Question reminder

Hi All,

I did not see any answer to the following question:
http://archives.postgresql.org/pgsql-jdbc/2004-12/msg00001.php

Could anyone give me hints or pointer ?

Thanks in advance,

Nicolas Modrzyk

On Mon, 6 Dec 2004, Nicolas Modrzyk wrote:

> Hi All,
>
> I did not see any answer to the following question:
> http://archives.postgresql.org/pgsql-jdbc/2004-12/msg00001.php
>

You've shown a java client thread waiting for a response from the
database. You've haven't shown that this is actually a problem. You
mention it is part of a stress test, so maybe it's just taking its sweet
time. Maybe it's blocked by another operation. I don't think this is a
problem with the JDBC driver and I'm skeptical that it's a problem with
the backend. Why do you think this is a real problem and not just
waiting?

Kris Jurka

Hi Kris,

This is an overnight test, and this has been reported by one of our
users as well. (on the same test, multiple times ...)
Basically, this thread has been like this for at least 4-5 hours, so I
don't think anything is going to unblock this anymore.
All the other thread of the test are in a normal wait position, and the
system is not using any resource anymore, so it should not be blocked by
other operation.
Most of the other requests are actually taking less than 10ms to execute.

The stress test is sending 2,000,000 transactions with each 3 write
requests in it.
The backend is still acessible using the psql command line tool ... I am
just wondering what is happening.

If you have any idea, indication please let me know.

Nicolas,

Kris Jurka wrote:

>On Mon, 6 Dec 2004, Nicolas Modrzyk wrote:
>
>
>
>>Hi All,
>>
>>I did not see any answer to the following question:
>>http://archives.postgresql.org/pgsql-jdbc/2004-12/msg00001.php
>>
>>
>>
>
>You've shown a java client thread waiting for a response from the
>database. You've haven't shown that this is actually a problem. You
>mention it is part of a stress test, so maybe it's just taking its sweet
>time. Maybe it's blocked by another operation. I don't think this is a
>problem with the JDBC driver and I'm skeptical that it's a problem with
>the backend. Why do you think this is a real problem and not just
>waiting?
>
>Kris Jurka
>
>
>
>
>

On Mon, 6 Dec 2004, Nicolas Modrzyk wrote:

> This is an overnight test, and this has been reported by one of our
> users as well. (on the same test, multiple times ...)
> Basically, this thread has been like this for at least 4-5 hours, so I
> don't think anything is going to unblock this anymore.
> All the other thread of the test are in a normal wait position, and the
> system is not using any resource anymore, so it should not be blocked by
> other operation.
> Most of the other requests are actually taking less than 10ms to execute.
>

You'll need to investigate what's going on in the server. So at the test
end all the other threads are done and idle. Do they disconnect? What do
you see regarding active backends from ps or pg_stat_activity? What locks
does this process have or wait on in pg_locks.

Kris Jurka

I am running the same test again to access the information you've
pointed me to.
I will let you know if I found anything relevant in the next hours.

Thanks,

Nicolas Modrzyk,

Kris Jurka wrote:

>On Mon, 6 Dec 2004, Nicolas Modrzyk wrote:
>
>
>
>>This is an overnight test, and this has been reported by one of our
>>users as well. (on the same test, multiple times ...)
>>Basically, this thread has been like this for at least 4-5 hours, so I
>>don't think anything is going to unblock this anymore.
>>All the other thread of the test are in a normal wait position, and the
>>system is not using any resource anymore, so it should not be blocked by
>>other operation.
>>Most of the other requests are actually taking less than 10ms to execute.
>>
>>
>>
>
>You'll need to investigate what's going on in the server. So at the test
>end all the other threads are done and idle. Do they disconnect? What do
>you see regarding active backends from ps or pg_stat_activity? What locks
>does this process have or wait on in pg_locks.
>
>Kris Jurka
>
>
>
>