Cached file read performance with 6.2-PRERELEASE

Mark Kirkwood markir at
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 mailing list