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

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

I don't follow the analysis above. If you have a server that is running heavy I/O, light CPU work, then it certainly could handle additional CPU heavy work, be it in a "virtualized" configuration, or under one instance of the OS. Doing it under seperate instances of the O/S is a symptom of an O/S that is not well suited to the traditional server role (Windows is not so good, VMS and, I am told UNIX, are better for example), But I don't understand the I/O analysis.

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.

The performance analysis here is no different in the multiple apps under one O/S instance and the multiple virtualized O/Ss case (other than that extra overhead that is added at the virtualization level in that case). The fundamental limitations remain the total available I/O bandwidth the machine can provide and/or the total CPU if you do get a case with CPU intensive apps.

Besides issues with the O/S, perhaps that is a reason for all those single app servers. For the workloads in question perhaps the typical PC server hardware may not have an adequate balance between CPU and I/O capacities. Wasn't that the fundamental distinction between minicomputers and mainframes? Relatively speaking, didn't mainframes have a lot more invested in the I/O capabilities?

Bob Hassinger
.