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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
