On Mon, Nov 19, 2012 at 12:02 PM, Vlad <marchenko@gmail.com> wrote:
>
> Some additional observation and food for thoughts. Our app uses connection
> caching (Apache::DBI). By disabling Apache::DBI and forcing client
> re-connection for every (http) request processed I eliminated the stall. The
> user cpu usage jumped (mostly cause prepared sql queries are no longer
> available, and some additional overhead on re-connection), but no single
> case of high-sys-cpu stall.
>
> I can not completely rule out the possibility of some left-overs (unfinished
> transaction?) remain after serving http request, which, in the absence of
> connection caching, are discarded for sure....
well, that is good. note for pgbouncer transaction mode you would
have had to quit using prepared statements anyways (see list of
features here: http://wiki.postgresql.org/wiki/PgBouncer). you can
use session mode though, and that would be a good test. faster speed
could be because of application issues or maybe just spreading out the
queries reduced contention. hard to say.
well, what happens next is up to you -- we can spend more time chasing
this down if you want, or you can hold back and see how things run for
a while. what is your user load up to in the worst case?
merlin
