From owner-freebsd-fs Sun Mar 26 15:16: 9 2000 Delivered-To: freebsd-fs@freebsd.org Received: from starburst.demon.co.uk (starburst.demon.co.uk [194.222.114.233]) by hub.freebsd.org (Postfix) with ESMTP id 1B33537BAA4; Sun, 26 Mar 2000 15:16:02 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id WAA01211; Sun, 26 Mar 2000 22:25:22 +0100 From: Richard Wendland Message-Id: <200003262125.WAA01211@starburst.demon.co.uk> Subject: Re: FreeBSD random I/O performance issues To: julian@elischer.org (Julian Elischer) Date: Sun, 26 Mar 2000 22:25:21 +0100 (BST) Cc: dillon@apollo.backplane.com (Matthew Dillon), current@freebsd.org, fs@freebsd.org Reply-To: richard@netcraft.com In-Reply-To: <38D9B306.2781E494@elischer.org> from "Julian Elischer" at Mar 22, 2000 11:34:11 PM Reply-To: richard@wendland.org.uk X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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