Re: postgresql latency & bgwriter not doing its job

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgresql latency & bgwriter not doing its job
Date: 2014-08-28 16:00:02
Message-ID: CAGTBQpYuT7QrLNRZy4VF1HKW=nW+50c3POC8OxHMPFMt6FYUnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 28, 2014 at 3:27 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-08-28 16:09:45 Re: Need Multixact Freezing Docs
Previous Message Andres Freund 2014-08-28 15:20:35 Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]