> $ gcc -Wall -O -DINIT_WRITE tfsync.c
> $ time a.out
>
> real1m15.11s
> user0m0.04s
> sys 0m32.76s
>
> Note the large amount of system time here, and the fact that the extra
> time in INIT_WRITE is all system time. I have previously
> observed that fsync() on HPUX 10.20 appears to
> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC
> (defined to do the equivalent of fdatasync()), and got truly
> fascinating results. Apparently, on this platform these flags change
> the kernel's buffering behavior! Observe:
Solaris 2.6 fascinates even more!!!
> $ gcc
Tom Lane <[EMAIL PROTECTED]> writes:
> We just bought back almost all the system time. The only possible
> explanation is that this way either doesn't keep the buffers from prior
> blocks, or does not scan them for dirtybits. I note that the open(2)
> man page is phrased so that O_SYNC is actua
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Seems that my Solaris has fdatasync, so I'll test different approaches...
A Sun guy told me that Solaris does this just the same way that HPUX
does it: fsync() scans all kernel buffers for the file, but O_SYNC
doesn't, because it knows it only needs
> The reason I'm inclined to question this is that what we want
> is not an fsync per write but an fsync per transaction, and we can't
> easily buffer all of a transaction's XLOG writes...
WAL keeps records in WAL buffers (wal-buffers parameter may be used to
increase # of buffers), so we can m
> >> This seems odd. As near as I can tell, O_SYNC is simply a command to do
> >> fsync implicitly during each write call. It cannot save any I/O unless
> >> I'm missing something significant. Where is the performance difference
> >> coming from?
>
> > Yes, odd, but sure very reproducible her
> > > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > > to gain the full advantage.
> >
> > > prewrite 0 + write and fsync: 60.4 sec
> > > sparse file + write with O_SYNC: 37.5 sec
> > > no prewrite + write with O_SYNC: 36.8 sec
> > > p
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> This seems odd. As near as I can tell, O_SYNC is simply a command to do
>> fsync implicitly during each write call. It cannot save any I/O unless
>> I'm missing something significant. Where is the performance difference
>> coming from?
> Y
> > A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
> > would cut the effective time needed to sync write the xlog more than in half.
> > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > to gain the full advantage.
>
> > prewrite 0 + write
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
> would cut the effective time needed to sync write the xlog more than in half.
> Of course we would need to buffer >= 1 xlog page before write (or commit)
> to gain th
10 matches
Mail list logo
