Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?

Holger Kipp hk at alogis.com
Mon Nov 30 14:13:59 UTC 2009


On Mon, Nov 30, 2009 at 02:49:17PM +0100, Ivan Voras wrote:
> Bill Moran wrote:
> >In response to Ivan Voras <ivoras at freebsd.org>:
> >
> >>Thomas Backman wrote:
> >>>On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote:
> >>>
> >>>>I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the 
> >>>>Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O 
> >>>>shows in contrast to all claims that have been to be improoved the 
> >>>>opposite.
> >>>Corrected link: 
> >>>http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1
> >>>
> >>>And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... 
> >>>The only reason I'm not switching from Linux. :(
> >
> >"All operating systems were left with their default options during the
> >installation process..."
> >
> >It's common knowledge that the default value for vfs.read_max is non-
> >optimal for most hardware and that significant performance improvements
> >can be made in most cases by raising it.
> 
> On the other hand, random IO is negatively influenced by readahead :)

Parallel Random I/O gives better results on Raid 5 than a single sequential
read :-) I also found FreeBSD UFS with Softupdates handling directories with
many small files much better than Linux and ReiserFS (same hardware) - at least
a simple ls returned much quicker on FreeBSD (factor 5 to 10).

So it is always a matter of what you intend to do with the filesystem - is it
for logging, for mailserver-storage, for database usage, for fileserver, webserver
etc. (with or without changing atime), with redundancy (raid 1, 5, 10) or using
zfs, etc.

With FreeBSD we have a system that works ok out of the box, but for real-world 
usage needs some tuning to be optimised for the specific task.

Regards,
Holger


More information about the freebsd-stable mailing list