From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | 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-27 14:32:19 |
Message-ID: | CAC_2qU9ePZEh=T5Jm8HonrwT2BZ-j-7FQvXv6dV4Zm6yr1OqPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 27, 2014 at 3:32 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> Hello Andres,
>
> [...]
>>
>> I think you're misunderstanding how spread checkpoints work.
>>
>
> Yep, definitely:-) On the other hand I though I was seeking something
> "simple", namely correct latency under small load, that I would expect out
> of the box.
>
> What you describe is reasonable, and is more or less what I was hoping
> for, although I thought that bgwriter was involved from the start and
> checkpoint would only do what is needed in the end. My mistake.
>
>
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?
>
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a
slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-08-27 14:33:20 | Re: pgbench throttling latency limit |
Previous Message | Bruce Momjian | 2014-08-27 14:13:40 | Re: Hardening pg_upgrade |