Re: Occasional giant spikes in CPU load

От: Tom Lane
Тема: Re: Occasional giant spikes in CPU load
Дата: ,
Msg-id: 2286.1277477230@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Occasional giant spikes in CPU load  (Craig James)
Ответы: Re: Occasional giant spikes in CPU load  (Craig James)
Список: pgsql-performance

Скрыть дерево обсуждения

indexes in partitioned tables - again  (Samuel Gendler, )
 Re: indexes in partitioned tables - again  (Robert Haas, )
  Occasional giant spikes in CPU load  (Craig James, )
   Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )
    Re: Occasional giant spikes in CPU load  (Craig James, )
     Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )
      Re: Occasional giant spikes in CPU load  (Craig James, )
       Re: Occasional giant spikes in CPU load  (David Rees, )
       Re: Occasional giant spikes in CPU load  (Tom Lane, )
       Re: Occasional giant spikes in CPU load  (Alan Hodgson, )
     Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )
   Re: Occasional giant spikes in CPU load  (Greg Smith, )
   Re: Occasional giant spikes in CPU load  (Tom Lane, )
    Re: Occasional giant spikes in CPU load  (Craig James, )
     Re: Occasional giant spikes in CPU load  (Steve Crawford, )
   Re: Occasional giant spikes in CPU load  (David Rees, )
    Re: Occasional giant spikes in CPU load  (Robert Haas, )
     Re: Occasional giant spikes in CPU load  (Craig James, )
      Re: Occasional giant spikes in CPU load  (David Rees, )
       Re: Occasional giant spikes in CPU load  (Robert Haas, )
        Re: Occasional giant spikes in CPU load  (Craig James, )
         Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )
         Re: Occasional giant spikes in CPU load  (Greg Smith, )
         Re: Occasional giant spikes in CPU load  (Tom Lane, )
          Re: Occasional giant spikes in CPU load  (Craig James, )
           Re: Occasional giant spikes in CPU load  (Tom Lane, )
            Re: Occasional giant spikes in CPU load  (Craig James, )
             Re: Occasional giant spikes in CPU load  ("Kevin Grittner", )
              Re: Occasional giant spikes in CPU load  (Craig James, )
             Re: Occasional giant spikes in CPU load  (Greg Smith, )
             Re: Occasional giant spikes in CPU load  (Tom Lane, )
              pgbench results on a new server  (Craig James, )
               Re: pgbench results on a new server  (Scott Marlowe, )
               Re: pgbench results on a new server  (Greg Smith, )
                Re: pgbench results on a new server  (Craig James, )
                 Re: pgbench results on a new server  (Merlin Moncure, )
                  Two fast searches turn slow when used with OR clause  (Craig James, )
                   Re: Two fast searches turn slow when used with OR clause  (Robert Haas, )
                 Re: pgbench results on a new server  (Greg Smith, )
           Re: Occasional giant spikes in CPU load  (Rajesh Kumar Mallah, )
         Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )
      Re: Occasional giant spikes in CPU load  (Bruce Momjian, )
    Re: Occasional giant spikes in CPU load  (Greg Smith, )
   Re: Occasional giant spikes in CPU load  ("Joshua D. Drake", )

Craig James <> writes:
> On 6/24/10 9:04 PM, Tom Lane wrote:
>> sinval queue overflow comes to mind ... although that really shouldn't
>> happen if there's "no real load" on the server.  What PG version is
>> this?

> 8.3.10.  Upgraded based on your advice when I first asked this question.

Any chance of going to 8.4?  If this is what I suspect, you really need
this 8.4 fix:
http://archives.postgresql.org/pgsql-committers/2008-06/msg00227.php
which eliminated the thundering-herd behavior that previous releases
exhibit when the sinval queue overflows.

If you're stuck on 8.3 then you are going to have to modify your
application's behavior to eliminate sinval overflows.  If the overall
system load isn't high then I would have to guess that the problem is
some individual sessions sitting "idle in transaction" for long periods,
long enough that a number of DDL operations happen elsewhere.

You could also consider throwing memory at the problem by raising the
sinval queue size.  That'd require a custom build since it's not exposed
as a configurable parameter, but it'd be a one-line patch I think.

Or you could look at using connection pooling so you don't have quite
so many backends ...

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: tony@exquisiteimages.com
Дата:
Сообщение: Architecting a database
От: Tom Molesworth
Дата:
Сообщение: Re: Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)