From owner-freebsd-fs Thu Mar 23 1:51: 4 2000 Delivered-To: freebsd-fs@freebsd.org Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38]) by hub.freebsd.org (Postfix) with ESMTP id A8A2A37C3E6; Thu, 23 Mar 2000 01:50:59 -0800 (PST) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by trinity.skynet.be (Postfix) with ESMTP id 6DBEC1814B; Thu, 23 Mar 2000 10:50:34 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: References: Date: Thu, 23 Mar 2000 10:34:42 +0100 To: FreeBSD-abusers@netscum.dk, Matthew Dillon From: Brad Knowles Subject: Re: FreeBSD random I/O performance issues Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 1:17 AM +0100 2000/3/23, FREENIX IS OVERRATED wrote: > Without really tuning anything, after a bit of time, the time needed > to do history lookups drops to microseconds, and as long as a `sync' > isn't needed, innd doesn't get stuck. Theoretically, a sync, where > you are in fact seeking rather wildly over the disk to update these > files, happens once a day at expiry. Depending on the speed of the > drive (and I haven't optimized this at all, using a single drive for > OS, logs, history, and part of spool, with a second drive for the rest > of the spool, far from an ideal setup), this seems to mean only a > few minutes of downtime. Actually building the new .index and .hash > files goes quite a bit faster, like by a factor of 3 to 4, so clearly > the update of these files during the `sync' could stand improved sorting. There are those of us running Diablo that solve this sort of problem on our main news peering servers by having the entire history file stored on a memory-based filesystem, so that we can sustain 1000-2000 history lookups per second. Obviously, this solution is not scalable to news spool servers, because you can't afford to lose the history file for a months worth of news, but the current mmap() based solution for the indexes of the history database seems to cause much more disk accesses than I would like to see. Perhaps this would be a good application for md? -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message