Re: checkpointer continuous flushing

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
Date: 2015-06-23 07:00:03
Message-ID: alpine.DEB.2.10.1506230700260.31285@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> I'd also like to see concurrent workloads with synchronous_commit=off -
> I've seen absolutely horrible latency behaviour for that, and I'm hoping
> this will help. It's also a good way to simulate faster hardware than
> you have.

It helps. I've done a few runs, where the very-very-bad situation is
improved to... I would say very-bad:

medium3: scale=200 shared_buffers=4GB checkpoint_timeout=15min
max_wal_size=4GB warmup=1200 time=6000 clients=4

flush sort | tps | percent of seconds offline
off off | 296 | 83% offline
off on | 1496 | 33% offline
off on | 1641 | 59% offline
on on | 1515 | 31% offline

The offline figure is the percentage of seconds in the 6000 seconds run
where 0.0 tps are reported, or where nothing is reported because pgbench
is stuck.

It is somehow better... on an abysmal scale: sorting and flushing reduced
the offline time by a factor of 2.6. Too bad it is so high to begin with.
The tps is improved by a factor of 5 with either options.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-06-23 08:41:07 Re: upper planner path-ification
Previous Message Glen Knowles 2015-06-23 06:06:56 Re: NULL passed as an argument to memcmp() in parse_func.c