Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: checkpointer continuous flushing
Date
Msg-id 20160115210213.GN10941@awork2.anarazel.de
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Andres Freund <andres@anarazel.de>)
Responses Re: checkpointer continuous flushing  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Hi Fabien,

On 2016-01-11 14:45:16 +0100, Andres Freund wrote:
> I measured it in a different number of cases, both on SSDs and spinning
> rust. I just reproduced it with:
> 
> postgres-ckpt14 \
>         -D /srv/temp/pgdev-dev-800/ \
>         -c maintenance_work_mem=2GB \
>         -c fsync=on \
>         -c synchronous_commit=off \
>         -c shared_buffers=2GB \
>         -c wal_level=hot_standby \
>         -c max_wal_senders=10 \
>         -c max_wal_size=100GB \
>         -c checkpoint_timeout=30s

What kernel, filesystem and filesystem option did you measure with?

I was/am using ext4, and it turns out that, when abling flushing, the
results are hugely dependant on barriers=on/off, with the latter making
flushing rather advantageous. Additionally data=ordered/writeback makes
measureable difference too.

Reading kernel sources trying to understand some more of the performance
impact.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: BUG #13854: SSPI authentication failure: wrong realm name used
Next
From: Jeff Janes
Date:
Subject: Re: Fuzzy substring searching with the pg_trgm extension