Re: 100% cpu usage on some postmaster processes kill the complete database - Mailing list pgsql-general

From Richard Huxton
Subject Re: 100% cpu usage on some postmaster processes kill the complete database
Date
Msg-id 4F4FD90C.4070601@archonet.com
Whole thread Raw
In response to Re: 100% cpu usage on some postmaster processes kill the complete database  (Paul Dunkler <paul.dunkler@xyrality.com>)
Responses Re: 100% cpu usage on some postmaster processes kill the complete database
List pgsql-general
On 01/03/12 19:41, Paul Dunkler wrote:
> I did that now - and analyzed the situation a bit. There are only queries
> running which will process very fast under high load (only index scans, very low
> rates of sequential scans). I found a remarkable number of Insert statements...
>
> And sometimes when that happens, the CPU Utilization is going up to nearby 100%
> too and 98% is system usage...

You're running on a box larger than I'm used to, so this is only
speculation. I'm wondering whether you're hitting problems with lock
contention or some such. It looks like you've got 48 cores there all at
about 100% possibly none of them getting much chance to do any work.

Oddly, the totals you posted in your top output show 6.3% user cpu
usage, which I can't make match with 50-odd processes all approaching
100% cpu.

Perhaps have a look at vmstat output too - see if context-switches spike
unusually high during these periods (sorry - no idea what an unusually
high number would be on a machine like yours).

Reducing the number of concurrent backends might help, but that rather
depends on whether my guess is right.

If no-one more experienced than me comes along shortly, try reposting to
the performance list. There are people there who are used to machines of
this size.

--
   Richard Huxton
   Archonet Ltd

pgsql-general by date:

Previous
From: Paul Dunkler
Date:
Subject: Re: 100% cpu usage on some postmaster processes kill the complete database
Next
From: Paul Dunkler
Date:
Subject: Re: 100% cpu usage on some postmaster processes kill the complete database