Fw: About NetBSD server tuning!

[Kulcsár Ferenc]

Sziasztok,

egy kis esettanulmany okulas vegett.

Udv:    Feri

UNIX *is* user friendly. It is just a bit selective about his friends.

----- Original Message -----
From: <sudog at sudog.com>
To: "Greg Oster" <oster at cs.usask.ca>
Cc: <port-i386 at netbsd.org>
Sent: Friday, February 23, 2001 1:50 AM
Subject: Re: About NetBSD server tuning!


> > sudog at 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