Re: rapid degradation after postmaster restart

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: rapid degradation after postmaster restart
Дата
Msg-id 4058BBA5.4080002@zeut.net
обсуждение исходный текст
Ответ на Re: rapid degradation after postmaster restart  (Andrew Sullivan <ajs@crankycanuck.ca>)
Список pgsql-performance
Andrew Sullivan wrote:

>The vacuum delay stuff that you're working on may help, but I can't
>really believe it's your salvation if this is happening after only a
>few minutes.  No matter how much you're doing inside those functions,
>you surely can't be causing so many dead tuples that a vacuum is
>necessary that soon.  Did you try not vacuuming for a little while to
>see if it helps?
>
>

Some of this thread was taken off line so I'm not sure it was mentioned
on the list, but a big part of the problem was that Joe was running into
the same bug that Cott Lang ran into a while ago which caused the vacuum
threshold to get set far too low resulting in vacuums far too often..
This has been fixed and the patch has been committed unfortunately it
didn't make it into 7.4.2, but it will be in 7.4.3 / 7.5.

>I didn't see it anywhere in this thread, but are you quite sure that
>you're not swapping?  Note that vmstat on multiprocessor Solaris
>machines is not notoriously useful.  You may want to have a look at
>what the example stuff in the SE Toolkit tells you, or what you get
>from sar.  I believe you have to use a special kernel setting on
>Solaris to mark shared memory as being ineligible for swap.
>
>

I haven't heard from Joe how things are going with the fixed
pg_autovacuum but that in combination with the vacuum delay stuff should
work well.

Matthew




В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: atrocious update performance
Следующее
От: Seum-Lim Gan
Дата:
Сообщение: PostgreSQL Disk Usage and Page Size