On Mon, Nov 19, 2012 at 12:02 PM, Vlad <marche...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
