Re: Partitioned checkpointing

Hello,

These are interesting runs.

> In a situation in which small values are set in dirty_bytes and
> dirty_backgound_bytes, a buffer is likely stored in the HD immediately
> after the buffer is written in the kernel by the checkpointer. Thus, I
> tried a quick hack to make the checkpointer invoke write system call to
> write a dirty buffer immediately followed by invoking store operation
> for a buffer implemented with sync_file_range() system call. # For
> reference, I attach the patch. As shown in file_sync_range.JPG, this
> strategy considered to have been effective.

Indeed. This approach is part of this current patch:

https://commitfest.postgresql.org/6/260/

Basically, what you do is to call sync_file_range on each block, and you
tested on a high-end system probably with a lot of BBU disk cache, which I
guess allows the disk to reorder writes so as to benefit from sequential
write performance.

> In conclusion, as long as pgbench execution against linux concerns,
> using sync_file_range() is a promising solution.

I found that calling sync_file_range for every block could degrade
performance a bit under some conditions, at least onmy low-end systems
(just a [raid] disk, no significant disk cache in front of it), so the
above patch aggregates neighboring writes so as to issue less
sync_file_range calls.

> That is, the checkpointer invokes sync_file_range() to store a buffer
> immediately after it writes the buffer in the kernel.

Yep. It is interesting that sync_file_range alone improves stability a lot
on your high-end system, although sorting is mandatory for low-end
systems.

My interpretation, already stated above, is that the hardware does the
sorting on the cached data at the disk level in your system.

--
Fabien.