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

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

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

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