Re: checkpointer continuous flushing - V18

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: checkpointer continuous flushing - V18
Date: 2016-03-08 07:33:09
Message-ID: alpine.DEB.2.10.1603080826300.16765@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Andres,

>> Now I cannot see how having one context per table space would have a
>> significant negative performance impact.
> The 'dirty data' etc. limits are global, not per block device. By having
> several contexts with unflushed dirty data the total amount of dirty
> data in the kernel increases.

Possibly, but how much? Do you have experimental data to back up that
this is really an issue?

We are talking about 32 (context size) * #table spaces * 8KB buffers = 4MB
of dirty buffers to manage for 16 table spaces, I do not see that as a
major issue for the kernel.

> Thus you're more likely to see stalls by the kernel moving pages into
> writeback.

I do not see the above data having a 30% negative impact on tps, given the
quite small amount of data under discussion, and switching to random IOs
cost so much that it must really be avoided.

Without further experimental data, I still think that the one context per
table space is the reasonnable choice.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2016-03-08 08:02:24 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message Andres Freund 2016-03-08 07:24:54 Re: silent data loss with ext4 / all current versions