atom feed17 messages in org.freebsd.freebsd-fsRe: FreeBSD random I/O performance is...
FromSent OnAttachments
Richard WendlandMar 21, 2000 4:22 pm 
Matthew DillonMar 21, 2000 4:59 pm 
Paul RichardsMar 21, 2000 6:44 pm 
Matthew DillonMar 21, 2000 10:17 pm 
Richard WendlandMar 22, 2000 7:43 am 
Mike SmithMar 22, 2000 12:39 pm 
Matthew DillonMar 22, 2000 4:10 pm 
FREENIX IS OVERRATEDMar 22, 2000 4:16 pm 
Matthew DillonMar 22, 2000 4:48 pm 
Julian ElischerMar 22, 2000 11:33 pm 
Brad KnowlesMar 23, 2000 1:34 am 
Richard WendlandMar 26, 2000 1:24 pm 
Matthew DillonApr 1, 2000 5:03 pm 
tele danmarQ kvindeserviceApr 4, 2000 3:02 pm 
Kun LimfjordsporterApr 4, 2000 6:28 pm 
Matthew DillonApr 4, 2000 7:18 pm 
Kun LimfjordsporterApr 4, 2000 10:23 pm 
Subject:Re: FreeBSD random I/O performance issues
From:Brad Knowles (bl@skynet.be)
Date:Mar 23, 2000 1:34:20 am
List:org.freebsd.freebsd-fs

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?

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message