[K12OSN] Are fast disks really that important and why?

[Paul VanGundy]

John,

There's definitely a better way to read disk I/O. Try using 'iostat -k
2' and watch as every two seconds you get a read of your disk I/O as
well as what your cpu utilization is. Pay attention to %iowait as you
look at it also.

/paul

-----Original Message-----
From: k12osn-bounces at redhat.com [mailto:k12osn-bounces at redhat.com] On
Behalf Of john 
Sent: Thursday, May 31, 2007 3:31 PM
To: k12osn at redhat.com
Subject: [K12OSN] Are fast disks really that important and why?

Hello all,

 I am trying to get THE definitive take on a question I have regarding
the necessity of using a fast disk array for LTSP. I touched on this
in a previous email and got some good advice. I want to probe a little
bit more if you don't mind. I hope I don't sound too dumb as I ask
these questions:

I have read Jim's piece on disk setup's here:
http://wiki.ltsp.org/twiki/bin/view/Ltsp/ServerSizing#Hard_disks

I brought this question up on the list in a slightly different form
and got responses that were helpful:

Les pointed out:

"The problem on a multi user machine is that every user wants the disk
head to be in a different place at the same time so seek time is often
more important than transfer rates. Consider what happens when everyone
is using a browser and every page and image each user loads is being
cached in their home directories.  Scsi disks/controllers can typically
take a bunch of commands at once and queue them up while IDE and most
SATA's can only do one comand at a time, waiting for CPU intervention at
each step."

And John said:

"The behavior ("Scsi disks/controllers can typically take a bunch of
commands at once and queue them up..."), is known as "elevator seeking"
and is a huge advantage of SCSI over SATA."

However a unix guru I work with responded to me:

"But--at least in all the UNIXen I ever worked on--you can and do
implement
this in software. And not in hardware."

 To prove his point we did the following:

We tested our installation in a lab with 30 thin clients attached to a
single commodity workstation running ubuntu/ltsp4.2 with 2G ram, 3Ghz
processor. We used  vmstat to monitor CPU,memory usage and disk i/o.
We found that disk I/O was relatively light after application startup
and that slow downs began to happen as processes queued up behind the
CPU waiting for their time slice to be handled. In short client speed
fell off as the CPU got busier, and not because of busy disks.

Were we looking at this in the wrong way? Was there a better way to
determine Disk IO?

I am leaning toward getting a fast array, but I would like to
understand this better before I do.

Thanks to those who made it to the end of this post! :-)

John

_______________________________________________
K12OSN mailing list
K12OSN at redhat.com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>