Skip site navigation (1) Skip section navigation (2)

Re: pl/pgsql function spikes CPU 100%

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Frost <jeff(at)frostconsultingllc(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: pl/pgsql function spikes CPU 100%
Date: 2007-03-16 14:49:25
Message-ID: 6522.1174056565@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-admin
Jeff Frost <jeff(at)frostconsultingllc(dot)com> writes:
> ... Interestingly, when you 
> strace the backend, it doesn't appear to be doing too much...here's some 
> sample output:

> select(0, NULL, NULL, NULL, {0, 1000})  = 0 (Timeout)
> semop(3932217, 0x7fbfffd150, 1)         = 0
> semop(3932217, 0x7fbfffd150, 1)         = 0
> semop(3932217, 0x7fbfffd150, 1)         = 0
> semop(3932217, 0x7fbfffd150, 1)         = 0
> semop(3932217, 0x7fbfffd150, 1)         = 0
> select(0, NULL, NULL, NULL, {0, 1000})  = 0 (Timeout)
> semop(3997755, 0x7fbfffd170, 1)         = 0
> semop(3932217, 0x7fbfffd150, 1)         = 0

This looks suspiciously like the sort of trace we saw in the various
"context swap storm" threads.  The test cases for those generally
involved really tight indexscan loops, ie, the backends were spending
all their time trying to access shared buffers.  If you haven't changed
the function or the data, then I concur with the nearby worry about
autovacuuming (large buildup of dead tuples could result in this symptom).
Or maybe you've got an old open transaction that is blocking cleanup?

			regards, tom lane

In response to

Responses

pgsql-admin by date

Next:From: Jeff FrostDate: 2007-03-16 15:24:08
Subject: Re: pl/pgsql function spikes CPU 100%
Previous:From: Jeff FrostDate: 2007-03-16 14:46:23
Subject: Re: pl/pgsql function spikes CPU 100%

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group