Re: Perf Benchmarking and regression. - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Perf Benchmarking and regression.
Date
Msg-id alpine.DEB.2.10.1605141822450.15904@sto
Whole thread Raw
In response to Re: Perf Benchmarking and regression.  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: Perf Benchmarking and regression.  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: Losing memory references - SRF + SPI
Next
From: Andres Freund
Date:
Subject: Re: Perf Benchmarking and regression.