Re: Sorted writes in checkpoint

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas ADI SD
Тема Re: Sorted writes in checkpoint
Дата
Msg-id E1539E0ED7043848906A8FF995BDA579022414E0@m0143.s-mxs.net
обсуждение исходный текст
Ответ на Re: Sorted writes in checkpoint  ("Simon Riggs" <simon@2ndquadrant.com>)
Список pgsql-hackers
> >   tests                    | pgbench | DBT-2 response time
> (avg/90%/max)
> >
> ---------------------------+---------+--------------------------------
> > ---------------------------+---------+---
> >  LDC only                  | 181 tps | 1.12 / 4.38 / 12.13 s
> >  + BM_CHECKPOINT_NEEDED(*) | 187 tps | 0.83 / 2.68 /  9.26 s
> >  + Sorted writes           | 224 tps | 0.36 / 0.80 /  8.11 s
> >
> > (*) Don't write buffers that were dirtied after starting
> the checkpoint.
> >
> > machine : 2GB-ram, SCSI*4 RAID-5
> > pgbench : -s400 -t40000 -c10  (about 5GB of database)
> > DBT-2   : 60WH (about 6GB of database)
>
> I'm very surprised by the BM_CHECKPOINT_NEEDED results. What
> percentage of writes has been saved by doing that? We would
> expect a small percentage of blocks only and so that
> shouldn't make a significant difference. I thought we

Wouldn't pages that are dirtied during the checkpoint also usually be
rather hot ?
Thus if we lock one of those for writing, the chances are high that a
client needs to wait for the lock ?
A write os call should usually be very fast, but when the IO gets
bottlenecked it might easily become slower.

Probably the recent result, that it saves ~53% of the writes, is
sufficient explanation though.

Very nice results :-) Looks like we want all of it including the sort.

Andreas


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

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: tsearch_core patch: permissions and security issues
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: Sorted writes in checkpoint