[K12OSN] Re: Server Tuning

[linuxk12 at mountainlake.k12.mn.us]

On Tue, Apr 19, 2005 at 03:07:25PM -0500, Owen O Donovan wrote:
> Have you tried using iostat? You can find it in the  sysstat rpm.
> 
> iostat <interval in sec> 
> gives you really great, humanly understandable, data on your disk subsys.

iostat is new to me.  I've been running it the last couole fo days
with the "-x" paramenter to see all of the details.  It looks like
the useful stats for me are "avgqu-sz" which I interpret to be the
number of requests waiting in the queue to be served and "await"
which is the number of milliseconds an average request has to wait
to be served.

It looks like "await" is typically in the 50-100 range, but occasionally
I see it at 30k (30 seconds assume, I since this is a measure of milli-
seconds).  Sometimes this number is much much higher, but perhaps it
is a problem with the software dealing with a counter turnover or something
like that.

I have not had enough time to observe the iostat output to draw any
conclusions or even to correlate them to the periods of time when the
server is having diffuculty keeping up with things.

> My reading from your description  is that a single drive  isn't adequate to
> keep up with the demands.  iostat should show that.

What would you look for in iostat?  Am I on the right track, being
interested in avgqu-sz and await?

> We run up to 60 (usu.30) concurrent smb sessions, about 10 - 20 afpd and
> between 100 and 200 nfs sessions concurrently on 866MHz PIII machines w 512MB
> RAM.  The big difference is that we run software raid 5 for home across 4 or 5> disks. The sw RAID adds some CPU load peaking to 10-15% --easily managed by
> the generally low CPU demands on a file server.

I don't have much experience with RAID.  I assume "sw RAID" means software
RAID as opposed to "hw RAID" which would be hardware RAID.  If I purchase
a new server, wouldn't hw RAID be preferable over sw RAID?  My current server
doesn't have room for many more drives.  Any pointers to further reading
would be helpful.

You also seem to imply that memory probably isn't a problem in this
situation.


On Tue, Apr 19, 2005 at 04:04:37PM -0500, Les Mikesell wrote:
> The IMAP server may be part of the problem.  If you have users with
> lots of messages stored on the server you might want to switch to Cyrus
> or at least make sure you have the current Dovecot server. 

I was not familiar with either of these IMAP/POP servers, so did some
checking.  Cyrus appears to really shine if you have many more than
100 simultaneous users.  It uses its own database to manage email and
can access it very efficiently.  Dovecot focuses on security and
performance.

Dovecot looks easy to compile and install, so I have been playing with
it a bit.  The security features are making it a pain to set up.  I've
been running it in a debugger just to see what exactly is tripping it up.
It's not quite a drop-in replacement for my current setup, so I'll have
to set it aside for now.

One consideration is that the mailbox file space is on a different drive
than the user file space, so imap was never in contention for disk
access, only CPU cycles.

Thanks for your responses!

--
Jon Harder
Technology Coordinator
Mountain Lake Public School
Mountain Lake, Minnesota