> sudog@sudog.com writes:
> > Some guidelines I've been forced into finding out for myself:
> >
> > 1. RAIDFrame is a no-no on the heavily accessed drives.
>
> You mean mixing both a RAID component and a non-RAID partition on the same
> drive?  (i.e. where accesses to the RAID set might 'interfere' with accesses
> to the non-RAIDed part of the disk?)   Also: what do you classify as
> "heavily accessed"?

I apologize for not taking actual measurements. It's hard to do on a
live system where millions of requests are coming in and making life
difficult. :)

But heavily accessed means, in my case, an Ultimate Bulletin Board
with 50,000 members and one or two million http file requests coming
in daily, grouping 80% of themselves from 6 a.m. to 3 p.m. Lemme see
about how many are perl cgi.. Hard to tell. Have to run a regexp on
the apache logs and exclude the referrers.

Each UBB process was running god knows how many file, directory,
lstat, membership retrievals, etc etc etc but usually only lasted for
a maximum of 1-2 seconds. Sometimes searches, thread reorganization,
etc took place and the perl processes took up to a minute and 20 MB of
ram. Generally a top is populated purely by perl no matter how much I
stretch the windows.

The forums contain upwards of a few hundred thousand threads and
messages.

> If the file mix is such that there are lots of very small files, then even
> RAID 1 should provide performance benefits on heavily accessed filesystems.
> Depending on the mix, RAID 5 should provide performance benefits for reading
> even small files... (if lots of small files are being written, then the
> RAID 5 set might require more careful tuning...)

I found that the RAID I was using was inadequate and as the system was
live I was loathe to monkey with settings, esp. when the site was so
large. Moving it off the RAID while it was still running was
definitely something I was proud of. =] In any case, as soon as I
pulled it off RAIDFrame performance improved, response was
instantaneous, and no more complaints were rolling in from the users.

The hardware: P3-600, 256 MB ram, two IDE drives, 20 GB, Quantum
fireballP. 7500 rpm if I recall correctly.

This may simply mean that a single-cpu machine is inadequate to the
task and that the RAIDFrame overhead is interfering with the perl cgi
execution. iostat is pretty much blank right now, for instance.

> > Therefore in order to ensure minimal
> > data loss, regular backups must be made.
>
> This is irrelevant to whether or not you use RAID :)

Well..  generally if I use raid and a component fails, it should still
be functional.. else everything is lost and I get whaled on. But of
course, decent backups are important. :)

> > 3. SCSI, SCSI, SCSI. Anything less and you're spinning your wheels.
> > Preferrably Seagate's new 15k Cheetah drives.
>
> 1) How many drives?
> 2) how many controllers?
> 3) how many drives per controller?
> 4) given 1), 2), and 3), how long before you either a) saturate a controller,
>     or b) saturate a PCI (or other) bus  ;)
> 5) how close are you to saturating the network connection? :)

1. 4-5 minimum. We're building servers out of 29160 and 39160 adaptec
now, with Quantum Atlas V 10k or Seagate Cheetah. The speed difference
is palpable, it's almost scary how fast the U160 drives run. Brings a
tear to my eye.
2. One. No need for two yet, nothing that big has come through the
doors.
3. Split evenly on 39160s, on the same chain on 29160s.
4. Nothing has ever been saturated yet. If the drives are only capable
of 30 MB or even 40, then the U160 can handle four drives before
getting nailed, at least in 64 bit motherboards.
5. Not even. Our new globbed pipes total 140 Mbps. =] Or close to it
anyway. That's bursted. Normal maximums sit at about 120 or so.

Hrm looks like there's some other discussion on this topic, I'll
answer some of those now.

ttyl,
Marc Tooley