> I am having a problem with Postgres with its > Write-Ahead-Log writing performance. So I ran > bonnie++ and it points out an obvious disparity where > most operations are comparably fast but one > particular type of operation, namely rewriting blocks > sequentially into an existing file, is *20 times* > slower than Linux. Also 20 times slower than writing > out the file in the first place including extending > it as it goes. > > The Bonnie++ results for two similarly configured > machines with identical hardware are: > > <pre> > Version 1.03 ------Sequential Output------ > --Sequential Input- --Random- > -Per Chr- --Block-- -Rewrite- > -Per Chr- --Block-- --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP > K/sec %CP K/sec %CP /sec %CP > silverstone 8G 103126 76 101880 28 2501 0 > 128890 83 152053 29 781.4 3 > imola 8G 76677 85 99334 18 54076 9 > 81671 86 199145 15 489.8 0 > /pre> > > Note the 2.5MB/s throughput when rewriting blocks > even though it gets over 100MB/s when writing out > blocks in the first place. "Silverstone" is oviously > the Solaris box I'm complaining about. > > I'm pretty new to Solaris so I'm not even sure where > to look to be sure it's a UFS filesystem. "mount" > doesn't seem to indicate what filesystem it is: > > /mnt/wal on /dev/dsk/c3t1d0s2 > read/write/setuid/devices/intr/largefiles/logging/xatt > r/onerror=panic/dev=8800c2
AFAIK, the onerror=panic is peculiar to UFS; but you could always try grep /mnt/wal /etc/mnttab which should spit out a line where the 3rd field is the filesystem type. > This is the mfi driver which was posted earlier on > the drivers forum. Is it possible it's a driver bug? > How could a driver affect only rewriting but not > reading or writing? I think I can imagine the possibility (driver trying to do some reordering that gets along very badly with the filesystem perhaps), but I think that's reaching a bit. Having the blocks being written be the same size as the filesystem blocksize would help a _lot_, I would think, since that would not imply reading a (typically 8KB, although that's not the only possible value) filesystem block (or two, if it crossed a boundary), merging the changes, and writing the changed blocks out again. If the writes are already filesystem block sized (or an integer multiple thereof) and aligned, then yes, that sounds quite disappointing (although differences in the handling of mtime, ctime, and perhaps atime updates might also be a factor). This message posted from opensolaris.org _______________________________________________ ufs-discuss mailing list [email protected]
