From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: CPU spikes and transactions |
Date: | 2013-10-15 13:00:44 |
Message-ID: | CAHyXU0xBPjFVAQE985PBgqpoidTKFNPwA5HoSWOPdApDq5udsQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Oct 14, 2013 at 6:45 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 15.10.2013 01:26, Tony Kay wrote:
>> Hi Calvin,
>>
>> Yes, I have sar data on all systems going back for years.
>>
>> Since others are going to probably want to be assured I am really
>> "reading the data" right:
>>
>> - This is 92% user CPU time, 5% sys, and 1% soft
>> - On some of the problems, I _do_ see a short spike of pgswpout's
>> (memory pressure), but again, not enough to end up using much system time
>> - The database disks are idle (all data being used is in RAM)..and are
>> SSDs....average service times are barely measurable in ms.
>
> OK. Can you share the data? Maybe we'll notice something suspicious.
>
>> If I had to guess, I'd say it was spinlock misbehavior....I cannot
>> understand why ekse a transaction blocking other things would drive
>> the CPUs so hard into the ground with user time.
>
> Have you tried running perf, to verify the time is actually spent on
> spinlocks?
+1 this. It is almost certainly spinlocks, but we need to know which
one and why. plz install debug symbols and run a perf during normal
and high load conditions.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tony Kay | 2013-10-15 15:59:08 | Re: CPU spikes and transactions |
Previous Message | Tomas Vondra | 2013-10-14 23:45:39 | Re: CPU spikes and transactions |