[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Thank you for the very thoughtful reply Les. It gives me food for thought.

John

On 5/31/07, Les Mikesell <les futuresource com> wrote:
john wrote:

> 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."

I don't think the current Linux implementations do a very good job of
re-ordering seeks if it even tries at all.  However, it does buffer to
whatever extent that it can.  Writes are always buffered unless there is
no RAM left (and the flush to disk might be done in sector order so you
would get some re-ordering there).  Reads are held in the disk buffer
until the space is needed for something else, so additional RAM can make
a huge difference when multiple users frequently access the same things.

The difference with SCSI is that the controller can re-order queued
commands after the CPU sends them so a read request for something
between two pending requests might be serviced as the head goes past its
location.  My recommendation is to max out the RAM you can put in the
box first, then if you have money left go for the faster drive set.

> 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.

Iostat will show i/o per-device but neither will give a good measure of
    the time that seeks are wasting which is the real problem.  If you
had a
matching load on a SCSI and IDE machine you might be also able to see a
difference in the system interrupts and context switch columns of vmstat
as the CPU has to do a lot more to drive an IDE controller (like issue a
seek and wait for completion before starting the data transfer) and each
of those operations involves an interrupt and context switch.

--
   Les Mikesell
    lesmikesell gmail com

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]