Thread: AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
From
Zeugswetter Andreas SB
Date:
> 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...).