Allow the WAL writer to flush WAL at a reduced rate.
authorAndres Freund <andres@anarazel.de>
Mon, 15 Feb 2016 22:52:38 +0000 (23:52 +0100)
committerAndres Freund <andres@anarazel.de>
Mon, 15 Feb 2016 23:56:34 +0000 (00:56 +0100)
commit7975c5e0a992ae9a45e03d145e0d37e2b5a707f5
treefa09f94f77fd54482b7fbd3ae411534ac1d7a85d
parent5df44d14ba9fd3f6149c3fa0919745c9e24bcffe
Allow the WAL writer to flush WAL at a reduced rate.

Commit 4de82f7d7 increased the WAL flush rate, mainly to increase the
likelihood that hint bits can be set quickly. More quickly set hint bits
can reduce contention around the clog et al.  But unfortunately the
increased flush rate can have a significant negative performance impact,
I have measured up to a factor of ~4.  The reason for this slowdown is
that if there are independent writes to the underlying devices, for
example because shared buffers is a lot smaller than the hot data set,
or because a checkpoint is ongoing, the fdatasync() calls force cache
flushes to be emitted to the storage.

This is achieved by flushing WAL only if the last flush was longer than
wal_writer_delay ago, or if more than wal_writer_flush_after (new GUC)
unflushed blocks are pending. Based on some tests the default for
wal_writer_delay is 1MB, which seems to work well both on SSD and
rotational media.

To avoid negative performance impact due to 4de82f7d7 an earlier
commit (db76b1e) made SetHintBits() more likely to succeed; preventing
performance regressions in the pgbench tests I performed.

Discussion: 20160118163908.GW10941@awork2.anarazel.de
doc/src/sgml/config.sgml
src/backend/access/transam/README
src/backend/access/transam/xlog.c
src/backend/postmaster/walwriter.c
src/backend/utils/misc/guc.c
src/backend/utils/misc/postgresql.conf.sample
src/include/postmaster/walwriter.h