AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
Date
Msg-id 11C1E6749A55D411A9670001FA687963368244@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-hackers
> 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 :-)
It shows, that WAL write was actually the bottleneck in this particular case.
The bottleneck may now have shifted to some other resource.

It would probably also be good, to actually write more than one 
page with one call instead of the current "for (;XLByteLT...)" loop
in XLogWrite. The reasoning is, 1. that for each call to write, the OS
takes your timeslice away, allowing other backends to work, 
and thus reposition the disk head (for selects). 
and second measurements with tfsync.c:

zeu@a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=1 -o tfsync
zeu@a82101002:~> time tfsync
real    0m26.174s
user    0m0.040s
sys     0m2.920s
zeu@a82101002:~> xlc -O2 tfsync.c -DINIT_WRITE -DUSE_ODSYNC -DBUFFERS=8 -o tfsync
zeu@a82101002:~> time tfsync
real    0m8.950s
user    0m0.010s
sys     0m2.020s

Andreas

PS: to Tom, on AIX O_SYNC and O_DSYNC does not make a difference with tfsync.c,
both are comparable to your O_DSYNC measurements, maybe this is because of the 
jfs journal, where only one write to journal is necessary for all fs work (inode...).


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc
Next
From: Peter Mount
Date:
Subject: Re: Banner links not working (fwd)