On Fri, Jul 6, 2018 at 3:37 AM, Jerry Jelinek <jerry.jeli...@joyent.com> wrote: >> If the problem is specifically the file system caching behavior, then we >> could also consider using the dreaded posix_fadvise(). > > I'm not sure that solves the problem for non-cached files, which is where > we've observed the performance impact of recycling, where what should be a > write intensive workload turns into a read-modify-write workload because > we're now reading an old WAL file that is many hours, or even days, old and > has thus fallen out of the memory-cached data for the filesystem. The disk > reads still have to happen.
What ZFS record size are you using? PostgreSQL's XLOG_BLCKSZ is usually 8192 bytes. When XLogWrite() calls write(some multiple of XLOG_BLCKSZ), on a traditional filesystem the kernel will say 'oh, that's overwriting whole pages exactly, so I have no need to read it from disk' (for example in FreeBSD ffs_vnops.c ffs_write() see the comment "We must peform a read-before-write if the transfer size does not cover the entire buffer"). I assume ZFS has a similar optimisation, but it uses much larger records than the traditional 4096 byte pages, defaulting to 128KB. Is that the reason for this? -- Thomas Munro http://www.enterprisedb.com
