Re: postgresql latency & bgwriter not doing its job - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: postgresql latency & bgwriter not doing its job
Date
Msg-id CAGTBQpYuT7QrLNRZy4VF1HKW=nW+50c3POC8OxHMPFMt6FYUnA@mail.gmail.com
Whole thread Raw
In response to Re: postgresql latency & bgwriter not doing its job  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: postgresql latency & bgwriter not doing its job
List pgsql-hackers
On Thu, Aug 28, 2014 at 3:27 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> Hello Aidan,
>
>
>> If all you want is to avoid the write storms when fsyncs start happening
>> on
>> slow storage, can you not just adjust the kernel vm.dirty* tunables to
>> start making the kernel write out dirty buffers much sooner instead of
>> letting them accumulate until fsyncs force them out all at once?
>
>
> I tried that by setting:
>   vm.dirty_expire_centisecs = 100
>   vm.dirty_writeback_centisecs = 100
>
> So it should start writing returned buffers at most 2s after they are
> returned, if I understood the doc correctly, instead of at most 35s.
>
> The result is that with a 5000s 25tps pretty small load (the system can do
> 300tps with the default configuration), I lost 2091 (1.7%) of transactions,
> that is they were beyond the 200ms schedule limit. Another change is that
> overall the lost transactions are more spread than without this setting,
> although there still is stretches of unresponsiveness.
>
> So although the situation is significantly better, it is still far from good
> with the much reduced value I tried.


What do the checkpoint logs look like now? (especially interested in sync times)



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Next
From: Alvaro Herrera
Date:
Subject: Re: Need Multixact Freezing Docs