From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Vlad Marchenko <marchenko(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: High SYS CPU - need advise |
Date: | 2012-11-21 15:49:12 |
Message-ID: | CAHyXU0xxp_sKXOzVwWGiQYuatO0Dxp5PwE2ghVz6gLXLtf+g6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Nov 21, 2012 at 9:29 AM, Vlad Marchenko <marchenko(at)gmail(dot)com> wrote:
> update on my problem: despite pgbouncer, the problem still occures on my
> end.
>
> Also, interesting observation - I ran several tests with pgbench, using
> queries that I think are prone to trigger high-sys-cpu-stall. What I noticed
> is when pgbench is started with prepared mode, the system behaves fine
> during stress-test (high user cpu - 85-90%, low sys cpu - 5-7%), high TPS.
> Though when I used non-prepared modes, the sys cpu portion jumps to 40% (and
> tps drops dramatically as well, but this is understandable). The test
> queries are pretty long (10kb+), with couple of outer joins across
> 1000-record tables with indexes.
>
> Maybe, we are looking in a wrong place and the issue is somewhere within
> planer/parser? Is there some extensive locking used in there?
>
> Another observation - it's harder to trigger high-sys-cpu stall on a freshly
> restarted postgresql. Though if it was running for a while, then it's much
> easier to do.
what pgbouncer mode, and how large is your pool.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad | 2012-11-21 16:14:11 | Re: High SYS CPU - need advise |
Previous Message | Vlad Marchenko | 2012-11-21 15:29:01 | Re: High SYS CPU - need advise |