From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: High SYS CPU - need advise |
Date: | 2012-11-15 17:28:36 |
Message-ID: | CAHyXU0yPwv72j9pBxKjKccyTWA3wVzN-yM7cZ14pgFK7ARQXPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Nov 14, 2012 at 4:08 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 11/14/12 1:34 PM, Vlad wrote:
>>
>> thanks for your feedback. While implementing connection pooling would make
>> resources utilization more efficient, I don't think it's the root of my
>> problem. Most of the connected clients are at IDLE. When I do
>>
>> select * from pg_stat_activity where current_query not like '%IDLE%';
>>
>> I only see several active queries at any given time.
>
>
> what about during these spikes?
Yeah -- if you are seeing a lot of queries pile up during these times,
it's time to explore connection pooler because it will keep system
load manageable during these situations.
things to check:
*) blocked queries (pg_locks/pg_stat_activity)
*) i/o wait. in particular, is linux page cache flushing.
*) query stampede: we will want to measure TPS leading into the stall
and out of it.
*) anything else running on the box?
*) you have a large amount of table? maybe this statistics file related?
*) let's log checkpoints to see if there is correlation with stall
*) nice to have vmstat/iostat during/before/after stall. for example,
massive spike of context switches during stall could point to o/s
scheduler issue.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad | 2012-11-15 17:50:53 | Re: High SYS CPU - need advise |
Previous Message | Sébastien Lardière | 2012-11-15 17:27:15 | Plproxy with returns table() make PG segfault |