| 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: | Whole Thread | Raw Message | 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 |