Re: Perf Benchmarking and regression.

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: Perf Benchmarking and regression.
Дата
Msg-id alpine.DEB.2.10.1605141822450.15904@sto
обсуждение исходный текст
Ответ на Re: Perf Benchmarking and regression.  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Ответы Re: Perf Benchmarking and regression.  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hello,

> Please find the results for the following 3 scenarios with unpatched master:
>
> 1. Default settings for *_flush_after : TPS = *10677.662356*
> 2. backend_flush_after=0, rest defaults : TPS = *18452.655936*
> 3. backend_flush_after=0, bgwriter_flush_after=0,
> wal_writer_flush_after=0, checkpoint_flush_after=0 : TPS = *18614.479962*

Thanks for these runs.

These raw tps suggest that {backend,bgwriter}_flush_after should better be 
zero for this kind of load.Whether it should be the default is unclear 
yet, because as Andres pointed out this is one kind of load.

Note: these options have been added to smooth ios over time and to help 
avoid "io panics" on sync, especially with HDDs without a large BBU cache 
in front. The real benefit is that the performance are much more constant 
over time, and pg is much more responsive.

If you do other runs, it would be nice to report some stats about tps 
variability (eg latency & latency stddev which should be in the report). 
For experiments I did I used to log "-P 1" output (tps every second) and 
to compute stats on these tps (avg, stddev, min, q1, median, q3, max, pc 
of time with tps below a low threshold...), which provides some indication 
of the overall tps distribution.

-- 
Fabien



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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Losing memory references - SRF + SPI
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Perf Benchmarking and regression.