Re: commit so slow program looks frozen

От: Carlo Stonebanks
Тема: Re: commit so slow program looks frozen
Дата: ,
Msg-id: ehqhhk$1vhm$1@news.hub.org
(см: обсуждение, исходный текст)
Ответ на: commit so slow program looks frozen  ("Carlo Stonebanks")
Список: pgsql-performance

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

commit so slow program looks frozen  ("Carlo Stonebanks", )
 Re: commit so slow program looks frozen  (Alvaro Herrera, )
 Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
  Re: commit so slow program looks frozen  (Brian Hurt, )
  Re: commit so slow program looks frozen  (Scott Marlowe, )
   Re: commit so slow program looks frozen  ("Joshua D. Drake", )
   Re: commit so slow program looks frozen  ("Magnus Hagander", )
   Re: commit so slow program looks frozen  (Richard Troy, )
   Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
    Re: commit so slow program looks frozen  ("Bucky Jordan", )
 Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
  Re: commit so slow program looks frozen  ("Jim C. Nasby", )
 Re: commit so slow program looks frozen  ("Rocco Altier", )
  Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
   Re: commit so slow program looks frozen  ("Merlin Moncure", )
    Re: commit so slow program looks frozen  ("Simon Riggs", )
     Re: commit so slow program looks frozen  ("Merlin Moncure", )
      Re: commit so slow program looks frozen  (Rob Lemley, )
   Re: commit so slow program looks frozen  (Richard Troy, )
    OT: TCL vs Perl Re: commit so slow program looks frozen  (, )
     Re: OT: TCL vs Perl Re: commit so slow program looks frozen  ("Joshua D. Drake", )
  Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
  Re: commit so slow program looks frozen  ("Carlo Stonebanks", )
 Re: commit so slow program looks frozen  ("Carlo Stonebanks", )

> I can just see the postgresql group getting together at the next
> O'Reilley's conference and creating that band.  And it will all be your
> fault.

Finally, a chance for me to wear my black leather pants.

> A context switch storm is when your machine spends more time trying to
> figure out what to do than actually doing anything.  The CPU spends most
> it's time switching between programs than running them.

Is thatl likely on a new 4 CPU server that has no clients connected and that
is only running four (admittedly heavy) TCL data load scripts?

> Seeing as PostgreSQL runs one thread / process per connection, it's
> pretty unlikely that the problem here is one "hungry" thread.  Do all
> four CPUs show busy, or just one?  Do you have a way of measuring how
> much time is spent waiting on I/O on a windows machine like top / vmstat
> does in unix?

Before optimising the queries, all four CPU's were pinned to max performance
(that's why I only run four imports at a time). After opimisation, all four
CPU's are busy, but usage is spikey (which looks more normal), but all are
obviously busy. I have this feeling that when an import app freezes, one CPU
goes idle while the others stay busy - I will confirm that with the next
import operation.

I suspect that the server has the Xeon processors that were of a generation
which PostgreSQL had a problem with - should a postgresql process be able to
distrivute its processing load across CPU's? (i.e. When I see one CPU at
100% while all others are idle?)

> Note that if you have an import process that needs a big chunk of
> memory, you can set just that one connection to use a large setting and
> leave the default smaller.

Total memory usage is below the max available. Each postgresql process takes
up 500MB, there are four running and I have 4GB of RAM.

Carlo




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

От: "Jim C. Nasby"
Дата:
Сообщение: Re: Stored procedure slower than sql?
От: Gavin Hamill
Дата:
Сообщение: Re: VACUUMs take twice as long across all nodes