Cached file read performance with 6.2-PRERELEASE
markir at paradise.net.nz
Tue Dec 19 17:34:36 PST 2006
In the process of investigating performance in another area I happened
to be measuring sequential cached reads (in a fairly basic manner):
$ dd if=/dev/zero of=/tmp/file bs=8k count=100000 # create file
819200000 bytes transferred in 4.849394 secs (168928321 bytes/sec)
$ dd of=/dev/null if=/tmp/file bs=8k # read it
819200000 bytes transferred in 2.177922 secs (376138354 bytes/sec)
$ dd of=/dev/null if=/tmp/file bs=8k # read again
819200000 bytes transferred in 2.178407 secs (376054620 bytes/sec)
$ dd of=/dev/null if=/tmp/file bs=32k # read it
819200000 bytes transferred in 1.801944 secs (454620117 bytes/sec)
I ran vmstat to check there really was no read access to the filesystem.
Now I had no idea whether this was the sort of performance to be
expected or not, so checked on an *identical* cpu, memory, mobo machine
running Gentoo - this gets 620MB/s for 8k blocks and 700MB/s for 32k ones.
I'm gonna quickly add - it's not my intention to start a Linux vs BSD
war here, the Gentoo data is mentioned to suggest that "Well - looks
like I should see if I can get the BSD box to do more than 433MB/s!".
The system is 2x1.26Ghz PIII, Supermicro P3TDER Serverworks HE-SL (dual
channel), 2x1G PC133 ECC DIMMS
FreeBSD setup is: FreeBSD 6.2-PRERELEASE #7: Mon Nov 27 19:32:33 NZDT
2006, with kernel based on GENERIC + SMP. I have /etc/malloc.conf -> >aj
Any suggestions/ideas about how to improve this?
P.s: Someone's gonna say this "why does this unrealistic test matter?".
Well, I work with databases a lot (usually postgres) and a great deal of
effort goes into caching table/relation data as much as possible - so
reading (and writing - but I'm not testing that here!) it as fast as
possible (sequentially or random) is clearly important!
More information about the freebsd-stable