"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Probably we should update XLogWrite to write() more than 1 block,
> but Tom should apply his patches first (btw, did you implement
> "log file size" condition for checkpoints, Tom?).
Yes I did. There's a variable now to specify a checkpoint every N
> > FSYNC:257tps
> > O_DSYNC: 333tps
> >
> > Just(?) 30% faster, -:(
>
> First of all, if you ask me, that is one hell of an improvement :-)
Of course -:) But tfsync tests were more promising -:)
Probably we should update XLogWrite to write() more than 1 block,
but Tom should ap
> Ok, I've made changes in xlog.c and run tests: 50 clients inserted
> (int4, text[1-256]) into 50 tables,
> -B 16384, -wal_buffers 256, -wal_files 0.
>
> FSYNC:257tps
> O_DSYNC: 333tps
>
> Just(?) 30% faster, -:(
First of all, if you ask me, that is one hell of an improvement
> > Ok, I've made changes in xlog.c and run tests:
>
> Could you send me your diffs?
Sorry, Monday only.
Vadim
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Denis Perchine <[EMAIL PROTECTED]> writes:
> On Saturday 10 March 2001 08:41, Tom Lane wrote:
>> More numbers, these from a Powerbook G3 laptop running Linux 2.2:
> Eeegghhh. Sorry... But where did you get O_DSYNC on Linux?
> bits/fcntl.h: # define O_DSYNC O_SYNC
Hm, must be. Okay, so
On Saturday 10 March 2001 08:41, Tom Lane wrote:
> More numbers, these from a Powerbook G3 laptop running Linux 2.2:
Eeegghhh. Sorry... But where did you get O_DSYNC on Linux?
Maybe here?
bits/fcntl.h: # define O_DSYNC O_SYNC
There is no any O_DSYNC in the kernel... Even in the latest
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Ok, I've made changes in xlog.c and run tests:
Could you send me your diffs?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL P
> > So seems we can use O_DSYNC without losing log write performance
> > comparing with write() + fsync. Though, we didn't tested write() +
> > fdatasync() yet...
>
> Good point, we should check fdatasync() too --- although I have no
> machines where it's different from fsync().
I've tested it o
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> $ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
> ^^^
> You should use -DUSE_OSYNC to test O_SYNC.
Ooops ... let's hear it for cut-and-paste, and for sharp-eyed readers!
Just for completeness, here
> Starting to look like we should just use ODSYNC where available, and
> forget about dumping more per write ...
I'll run these tests on RedHat 7.0 tomorrow.
Vadim
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregist
More numbers, these from a Powerbook G3 laptop running Linux 2.2:
[tgl@g3 tmp]$ uname -a
Linux g3 2.2.18-4hpmac #1 Thu Dec 21 15:16:15 MST 2000 ppc unknown
[tgl@g3 tmp]$ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
[tgl@g3 tmp]$ time ./a.out
real0m32.418s
user0m0.020s
sys
> $ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
^^^
You should use -DUSE_OSYNC to test O_SYNC.
So you've tested N * write() + fsync(), exactly what I've asked -:)
> So I also see that there is no benefit to writing more than
> one block at a ti
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Tom, could you run this test for different block sizes?
> Up to 32*8k?
>>
>> You mean changing the amount written per write(), while holding the
>> total file size constant, right?
> Yes. Currently XLogWrite writes 8k blocks one by one. From what I'
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> I attach my modified version of Andreas' program. Note I do not
>> believe his assertion that close() implies fsync() --- on the
>> machines I've used, it demonstrably does not sync.
> Ok, I am not sure, but essentially do we need it to sync
14 matches
Mail list logo
