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

[john]

Thanks Paul!

John

On 5/31/07, Paul VanGundy <Paul.Vangundy at webex.com> wrote:
> 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>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>