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.