From: Chuck Yerkes (chuck+obsd2003.snew.com)
Date: Wed Jul 02 2003 - 11:33:44 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Quoting Henning Brauer (lists-openbsdbsws.de):
> On Wed, Jul 02, 2003 at 08:02:13AM -0500, Marco Peereboom wrote:
> > IDE is CPU intensive, unlike SCSI which does pretty much everything on it's
> > own and just lets the OS know when it is done.
>
> this isn't true any more.
...
> for example, on a mailserver, and here especially the mail queue, lots
> of small files are written and read again, all the time. the data
> ytransfer rate here is pretty much irrelevant as the files are small,
> but the access time is important.

On a side note here, I've done large mail and there are a couple
tricks (where large > 150k/hr). Multiple queues on multiple spindles
is obvious, but mounting an MFS and having your startup populate
it with, say "/mqmfs/xf00" "/mqmfs/xf01" "/mqmfs/xf02" "/mqmfs/xf03"
and having links from the queue's xf/ to these, eg.
    /var/spool/mqueue/queue00/xf -> /mqmfs/xf00
Mean that xf files (locks) are on MFS (kinda fast :).

They die on reboot. As do locks.

The OTHER trick is NVRAM cards. qf files get read/rewritten, but
are of a fairly constant size (where df (data) is from 1k to 4000k).
I played with a Platypus Systems card (solaris and freebsd at that
point) that's basically got a powerplug for the NV part, and SIMMS
- up to 8GB. If you have 8GB of queue files, then you have issues.
You structure it the same way as the xf:
    /var/spool/mqueue/queue00/qf -> /mqmfs/qf00

This puts the qf files, being read and written over and over, onto
a RAM disk that survives reboots.

But first performance pass is multiple spindles (and caching DNS).

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]