From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgresql latency & bgwriter not doing its job |
Date: | 2014-09-02 15:36:19 |
Message-ID: | CAMkU=1xWqKbaE_kX0tAgOt5j-hZsOkqqdqya9m18r1Ft8G4SUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 2, 2014 at 8:14 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> There is scan_whole_pool_milliseconds, which currently forces bgwriter to
>>>> circle the buffer pool at least once every 2 minutes. It is currently
>>>> fixed, but it should be trivial to turn it into an experimental guc that
>>>> you could use to test your hypothesis.
>>>>
>>>
>>> I recompiled with the variable coldly set to 1000 instead of 120000. The
>>> situation is slightly degraded (15% of transactions were above 200 ms
>>> late). However it seems that bgwriter did not write much more pages:
>>>
>>
>>
>> You should probably try it set to 200 rather than 1000, to put it on an
>> equal footing with the checkpoint_timeout of 0.2 seconds you reported on.
>>
>
> As I understand it, the setting makes the bgwriter processe scan all
> shared_buffers every this amount of time... but ITSM that the key point is
> that bgwriter has no insentive to start writing out buffers anyway with its
> current decision rules, and that should not change with the frequency at
> which they are scanned (?)
Ah, I see now. The usage counts are not zero, so it visits the buffer and
then leaves it alone.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-09-02 15:41:22 | Re: COPY and heap_sync |
Previous Message | Marko Tiikkaja | 2014-09-02 15:33:08 | Re: PL/pgSQL 2 |