| From | Sent On | Attachments |
|---|---|---|
| Richard Wendland | Mar 21, 2000 4:22 pm | |
| Matthew Dillon | Mar 21, 2000 4:59 pm | |
| Paul Richards | Mar 21, 2000 6:44 pm | |
| Matthew Dillon | Mar 21, 2000 10:17 pm | |
| Richard Wendland | Mar 22, 2000 7:43 am | |
| Mike Smith | Mar 22, 2000 12:39 pm | |
| Matthew Dillon | Mar 22, 2000 4:10 pm | |
| FREENIX IS OVERRATED | Mar 22, 2000 4:16 pm | |
| Matthew Dillon | Mar 22, 2000 4:48 pm | |
| Julian Elischer | Mar 22, 2000 11:33 pm | |
| Brad Knowles | Mar 23, 2000 1:34 am | |
| Richard Wendland | Mar 26, 2000 1:24 pm | |
| Matthew Dillon | Apr 1, 2000 5:03 pm | |
| tele danmarQ kvindeservice | Apr 4, 2000 3:02 pm | |
| Kun Limfjordsporter | Apr 4, 2000 6:28 pm | |
| Matthew Dillon | Apr 4, 2000 7:18 pm | |
| Kun Limfjordsporter | Apr 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?
-- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, <bl...@skynet.be> || 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 majo...@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message





