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

Main, Kerry wrote:
-----Original Message-----
From: Bill Todd [mailto:billtodd@xxxxxxxxxxxxx] Sent: June 5, 2006 8:09 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)

Main, Kerry wrote:
-----Original Message-----
From: Bill Todd [mailto:billtodd@xxxxxxxxxxxxx] Sent: June 4, 2006 5:42 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)

Main, Kerry wrote:

...

Point is that when both UNIX and VMS are setup and tuned
appropriately
on the same HW, there is not much difference in performance.
The point, of course, is that while virtually *any* half-competently-implemented OS will be performance-competitive with any other *when set up and tuned*, *most* use of OSs is in
installations
which are *not* 'set up and tuned appropriately', but rather either just booted up and run or, at most, given some very general
tweaking that
won't compromise any of the many applications they're
likely to run.
And under those circumstances, VMS comes out rather poorly performance-wise when compared to Unix, while providing rather limited increased reliability of a statistical sort - e.g., that
it's *less
likely* by X% that the data you naively thought you wrote
won't be on
the disk after, say, a power failure, rather than of the far more significant variety that if the data you naively thought you wrote isn't on the disk after a power failure, you should file a bug report.

'A bit better reliability with a lot slower performance' really isn't a *default* trade-off one can legitimately boast about, I'm afraid: one should instead pick something closer to one extreme or the other as the default so that not *all* customers need tweak the system significantly to get something reasonable - especially since applications with special needs have the ability to attain them *regardless* of how
the system
defaults are set up, so really don't derive much aid from half-way default measures anyway.

The bottom line is that Unix provides significantly better file-system performance out of the box than VMS does, and this is an entirely legitimate knock on VMS - not so much on VMS's capabilities per se as in its choices of defaults, but the effect on real-world perceptions is not markedly different.

- bill

Well, my experience is that, regardless of what platform is
used, most
production shops in med-large shops will always tune their
environment
to some basic level.
1) It's not clear exactly how that statement differs from what I said just above ("some very general tweaking that won't compromise any of the many applications they're likely to run"). Tuning an entire server for one specific application may occur more frequently in Windows environments (where admins are frequently scared to run more than a single application on the server), but far less so in the Unix and VMS environments under discussion here.

2) One might also ask just how much of that experience was focused solely on VMS, which *definitely* requires performance tuning when performance is required to a significantly greater degree than Unix (or even Windows, God forbid).

Even UNIX and Windows servers performance can be
significantly enhanced
with some basic tuning as compared to "out-of-the-box" parameters.
I'll ask you to provide specific examples, especially in the case of Unix: my impression is that their defaults are rather performance-oriented (to the degree that 'significant' enhancement might be somewhat difficult to attain with only 'basic tweaking').

I am sure most UNIX admins would not simply install their
UNIX OS and
then start loading app's for testing without adjusting OS
and/or kernel
parameters to make the target apps work better.
I'm not so sure (especially by comparison with what may typically be required on VMS, given that some of its defaults - e.g., RMS buffer sizes - aren't particular desirable for *any* situations, having been established back when RAM was added in units of KB rather than MB or GB), but let's let people with more experience in that area than either of us has chime in here.

Having stated this, the performance numbers for the
majority (70-80%) of
Windows servers today are 10% to 15% busy in peak time and
majority of
UNIX servers are only slightly better at 20-30% busy in peak times.
Well, duh: what part of the fact that even with well-optimized file access waiting for disks *still* dominates a lot of workloads has managed to escape you? For quite a few years now it has become difficult to purchase a processor *weak* enough to be challenged by such workloads (save in situations where they scale up sufficiently to allow that single processor or small MP system to service many, many actively-working disks at once).

Note that in such environments having an efficient file system *still* makes a significant difference to system throughput, though - even if the processor is still loafing a lot of the time. And that advantage remains even under the virtual consolidation scenarios which you're touting (though diverging from the topic under discussion by doing so).

- bill


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
.