Re: Table and Index compression

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Table and Index compression
Дата
Msg-id 4A7BE8FB0200002500029648@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Table and Index compression  (Pierre Frédéric Caillaud<lists@peufeu.com>)
Ответы Re: Table and Index compression
Список pgsql-hackers
Pierre Frédéric Caillaud<lists@peufeu.com> wrote:
> tablespace is a RAID5 of 3 drives, xlog in on a RAID1 of 2 drives,
> but it does it too if I put the tablespace and data on the same
> volume.
> it starts out relatively fast :
> 
>   si   so    bi    bo   in   cs    us sy id wa
>      0    0     0 43680 2796 19162 42 18 37  3
>      0    0     0 45515 3165 20652 44 17 35  4
>      0    0     0 43130 3046 21991 43 17 38  2
> 
> then here it starts to slow down : check "bo" output
> 
>      0    0   181 24439  577 3541 31  6 40 23
>      0    0   176 17258  292 1324 31  4 43 22
>      0    0     0 18626  162  693 35  3 49 12
>      0    0     1 21554  235 1362 31  5 50 14
>      0    0     0 19177  324 2053 35  4 50 12
>      0    0     0 19208  206 1155 36  4 48 12
>      0    0     1 20740  215 1117 33  4 50 13
>      0    0     0 20154  258 1100 32  4 50 14
>      0    0     0 20355  316 2056 34  5 49 12
> 
> ... and it stays like this until the end of the INSERT...
I don't know if this is it, but we tend to see outrageously high
performance at the start of a benchmark because of the battery-backed
cache in the RAID controller.  Every write comes back immediately
after copying the data to RAM.  After a while the cache gets filled
and you settle down to a steady state.  If it's not BBU with
write-back enabled, perhaps you have drives that lie about write
completion?
-Kevin


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

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: compilation with libeditpreferred is broken
Следующее
От: Peter Eisentraut
Дата:
Сообщение: ALTER TABLE SET STATISTICS requires AccessExclusiveLock