Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)

BobH wrote:
Bill Todd wrote:
Main, Kerry wrote:
...
The environments I am talking about in the majority of Windows/UNIX
servers today are not CPU lite, but disk IO heavy. They are just not
utilized that much at all in peak periods - period.


That's what I just suggested, Kerry: they're limited by disk I/O, not CPU, and hence CPU utilization *will* be low, even if the disks are working their little tails off.

And any file system optimizations that will reduce the load on the disks (as Unix's do far better by default than VMS does) *will* be useful.


Part of this might be attributed to the one-app, one server philosophy
as repeated refreshes makes for a much faster server at lower costs, but
if the workload does not increase that much, then the overall
utilization goes down. Multiply this by hundreds of x86 servers in many
environments and you have one of the basic reasons why CIO's are so
concerned about their Windows environments.


Yadda, yadda, yadda: so what? This has nothing to do with the subject at hand, as I already observed.

...

And btw, a server with low cpu utilization, but heavy IO makes for a
poor candidate for virtualization.


But since you seem to insist on this digression: horse***. A server with very low CPU utilization is a *good* candidate for virtualization, since it's got lots of horsepower left over for other tasks that (especially in Windows environments) admins might be reluctant to run on the same OS instance: just hook up some more disks to service the added application(s) and let 'er rip.

Remember that virtualization adds

another level of overhead for both IO and CPU loads.


As far as disk I/O goes, horse*** again: the CPU overhead, even with virtualization added, is a relatively small component of the latency in a disk access, and since you've already posited that the CPU has cycles to burn, the added CPU overhead of virtualization is not a problem.

- bill

Hi, Bob - long (LONG) time, no-see.

....

I think the question was stated in terms of adding more of that heavy I/O work to a server that already has heavy on I/O. Number of disks and latency are interesting parts of that analysis, but total I/O bandwidth seems to me to be the limiting issue. Any given computer has a limit on its available I/O bandwidth. Things like the bandwidth of the paths the I/O travels over, particularly on the backplane or on the motherboard and its chips, including memory. Only so many bits can be Ied and Oed in a given amount of time by a particular hardware design. If those limits did not exist then even a very modest computer could do a nearly unlimited amount of I/O by just hanging more and more disks off of it.

By definition the question was a server that was already heavily loaded on the I/O side. That says it is already pushing the I/O capabilities of the system. Adding more of that kind of work will result in performance problems since there will not be enough I/O to go around.

Not necessarily: there are plenty of situations in which a system can be I/O-bound but only stressing the capabilities of its disks, to wit, when doing lots of relatively small I/O operations (Web-serving being an excellent - and common - example, since Web pages tend to be composed of many, many itsy-bitsy files and if you're dishing out a large number of pages, each with its own large set of associated small files, then even a good-sized file cache won't be all that effective in reducing disk load; database access is also often characterized by many small disk requests, but in that case there's often more data-processing going on rather than the kind of simple data-shuffling that leaves the CPUs relatively idle).

In such a case, you can keep adding disks for a *long* time (whether to the same OS instance or an added one) before taxing the I/O capabilities of the box hardware. Just to get a rough idea, if your disks can each generate 80 - 160 4KB disk accesses per second (for ATA/SATA or SCSI/FC, respectively), that's only 320KB - 640KB/second (or twice that if it must travel over the same path both in-coming and out-going). Even the lowliest obsolete desktop-level PCI bus is capable of handling over 100 MB/second in such cases (and PC memory bandwidth these days is measured in GB/sec), so you could literally service 100 or more drives under these circumstances with a 1990s desktop PC without breaking a bandwidth sweat (though you might start running into other issues such as interrupt saturation).

Whereas for something like a streaming video server, I agree completely with your analysis above: current drives can stream sequential data at 40 - 80 MB/sec, so it doesn't take more than a couple to saturate an old-style PCI bus (though server 64/66 PCIs can handle more like 500 MB/sec, PCI-X 1 GB/sec, and I think PCI-Express a whole lot more) - even though the CPU may be pretty much idle.

I suspect that Web servers are a lot more common than video servers, and a decade ago file servers tended to see small (8 KB and under) files dominate access patterns (though that size may have increased with the increased popularity of images, audio, and video, plus the constant ballooning of Microsoft Word document sizes, so a typical file server today may see something intermediate in terms of bandwidth requirement). In any event, I was (tacitly) assuming this kind of workload when I commented.

- bill
.