Date: Sun, 26 Mar 2000 22:25:21 +0100 (BST) From: Richard Wendland <richard@starburst.demon.co.uk> To: julian@elischer.org (Julian Elischer) Cc: dillon@apollo.backplane.com (Matthew Dillon), current@freebsd.org, fs@freebsd.org Subject: Re: FreeBSD random I/O performance issues Message-ID: <200003262125.WAA01211@starburst.demon.co.uk> In-Reply-To: <38D9B306.2781E494@elischer.org> from "Julian Elischer" at Mar 22, 2000 11:34:11 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> This is one of the things that made us do so badly
> in the benchmarks against NT/Linux last year.
If the benchmarks included random I/O I would think so.
By creating a small synthetic program exhibiting the problem, I may have
obscured the scale of the real-world consequences of this problem.
Here are some test results from a slightly simplified program and data
that Netcraft regularly runs. This is a simple perl DB_File program
that reads 10 million input records, creating and updating a Berkeley
DB file from that input. At finish the DBM is 78MB logical size, 67MB
physical size (it's sparse), with 2176918 keys.
These benchmark results aren't perfect, since some of the machines
weren't completely idle, but they aren't far off.
Elapse time OS Disc
4 hrs, 2 mins 2.2.8-STABLE Atlas II, 7200RPM, 512KB buff
3 hr, 17 mins 3.3-RELEASE ATA IBM Deskstar 34GXP, 7200RPM, 2MB
3 hr, 2 mins 3.3-STABLE IBM Ultrastar 18ES, 7200RPM, 2MB buff
1 hr, 43 mins 2.2.7-RELEASE Cheetah 9, 10000RPM, 1MB buff
51 mins 2.2.7-RELEASE Cheetah 9, 10000RPM, 1MB buff, 5 way
ccd striped, interleave=64
31 mins Linux 2.2.13 IBM Ultrastar 18ES, 7200RPM, 2MB buff
The run on Linux seemed CPU bound at times, with 87% CPU utilisation
overall. The Linux system and the 3.3-STABLE/Ultrastar 18ES machine
are both similar Dell 1300s.
Netcraft runs quite a few DBM programs. You can probably see why I've
gone to a fair amount of effort benchmarking to pin this performance
problem down, and hopefully encourage the development of a fix. Netcraft
uses heavily striped fast discs, in part to make these DBM programs run
at a reasonable speed, as it turns out to overcome a software deficiency.
Actually DBM performance on FreeBSD can be significantly improved by:
$DB_HASH->{cachesize} = 64 * 1024 * 1024;
which I commented out for this test; I doubt most DBM users set this.
So our programs don't now run quite as slow as the results above suggest,
by in effect creating a very large in-process write buffer.
On FreeBSD this test program does about 28+2191019io according to csh
'time', I assume that's in 8KB blocks, in which case it's 16.7GB of I/O.
In 51 mins that's 5.6MB/sec, on top of the seeks.
Richard
--
Richard Wendland richard@netcraft.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003262125.WAA01211>