Re: High SYS CPU - need advise

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Vlad <marchenko(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: High SYS CPU - need advise
Date: 2012-11-19 20:04:32
Message-ID: CAHyXU0ysMqA9T6oprOcGOC-Ojaq78_A7Wec9KTTot=htQJ8V_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Nov 19, 2012 at 12:02 PM, Vlad <marchenko(at)gmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Johnston 2012-11-19 20:04:47 Re: Split_part on a CR
Previous Message Gary Chambers 2012-11-19 20:00:16 Re: Split_part on a CR