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

Main, Kerry wrote:
-----Original Message-----
From: Bill Todd [mailto:billtodd@xxxxxxxxxxxxx] Sent: June 7, 2006 12:14 AM
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 6, 2006 1:36 AM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)

[snip..]

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.

Apologies, I did not make myself clear.
No: you either misspoke, or are now covering up an attempt to back-pedal - see below.

While there is typically a very small number of servers
that are fairly
heavy utilized, the majority of Wintel and UNIX servers today are
neither CPU *or* disk IO heavy.
That is *not* what you said above: you said "The environments I am talking about in the majority of Windows/UNIX servers today are not CPU lite, but disk IO heavy" (*not* "neither CPU *or* [sic] disk IO heavy", as you would now like us to think), and that's the statement to which I responded


Like my updated note stated, I did not make myself clear in the original
note.

Wrong again: you made yourself quite clear - if there was any problem (rather than a later attempt to change what you originally meant) it was (as I said) because you actively misspoke (which is decidedly not the same as merely 'not making yourself clear').

Clear now?


...


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.
Most admins on any platform I know would tune their OS's /
file systems
etc before releasing to production. The same is true for
OpenVMS. Very
few ever release the default config into production, so at
best, this is
a theoretical viewpoint.
I notice that you're continuing to skate around the question of exactly how much experience you have with the administration of other OSs (Unix in particular being central to the current context). Until such time as you're ready to claim significant experience with Unix administration, let's leave this open for more qualified people to comment upon.


Skate nothing. While I will certainly not claim to be a UNIX admin, I
have been around DC's enough to understand the provisioning process does
not simply involve install OS, add applications, test and move to prod.

Which is not at all the same as saying that the kind of significant file-access tuning that VMS so often *requires* to generate good performance is typically required to generate good performance in Unix environments, of course.

Since you've now actively acknowledged that you don't know what you're talking about in this area, as I've suggested already let's let people who *do* chime in, if any choose to.


Hey - there are lots of other folks here who have UNIX sys admin
experience - how many would move their newly installed UNIX OS to prod
with zero tuning to the application in question?

...

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

While it can be done, keep in mind the impact on total
bandwidth (need
to balance), CPU cache thrashing and virtual drivers overhead.
Waving your hands vigorously won't cut it, Kerry - you really ought to have learned that by now.

A heavy
IO application will likely depend on cpu caching, but if
the other OS
instances are constantly invalidating the CPU cache, then
most of the
heavy IO's will go directly to memory/disk.
Let's not confuse CPU cache with file-system cache, shall we? If the 'heavy I/O application' is not managing to tax the CPU(s) much, then it pretty much by definition is *not* depending much on CPU caching, nor with DMA mechanisms (which have been common for decades now) is most of the data necessarily even *passing through* the CPU caches on its journey from input to output.

And of course other OS instances 'constantly invalidating the CPU cache' will *never* affect disk accesses, only (at worst) send occasional references to RAM which might have otherwise hit in the CPU cache.

Your horseshit is rapidly turning into bullshit, I fear.


Bill - this looks like an area that you need to do some additional
research on.

Au contraire, mon ami: I clearly don't need to crack a book or tickle Google to leave you in the dust here, so I'll just continue kicking it into your face for a while yet.


Virtualization of a system (OS stacking, sub CPU virtualization) is all
about trade-off's in terms of reducing the overall HW, improving server
utilization and balancing the stacking of *low* resource demand
applications against the demands of the overall system.

As I know you know, all IO based applications have some level of CPU
loads and as you start to mix additional CPU loads that also have IO
loads (not many applications do CPU only with no IO), it will
potentially impact that heavy IO application.

In the real world, if you have a very IO intensive application that is
anywhere close to being important, most Cust's would leave it on a
dedicated server as they do not want to take any chances that additional
stacked applications would in any way impact that applications overall
performance.

Yup - well into bullshit territory now, Kerry: why am I not surprised that you just continue to bluster on in the hope that something might stick or more competent debaters might just get tired?

Gee: people with applications too important to tolerate *any* interference from other applications probably won't run other applications on the same hardware with them - tautologies are so illuminating, news at 11. Of course, people with such applications aren't candidates for the kind of consolidation you started touting anyway, so yet another attempt to deflect the conversation from areas that may be getting embarrassing for you.

People interested in getting more bang out of a given amount of hardware, by contrast, will indeed run applications that aren't quite so finicky (i.e., most applications, since the amount of interference you're talking about between I/O-intensive tasks that don't tax the CPU and other tasks that don't share any of the hardware that the first set of tasks is pushing hard is rather small) along with other similarly-unfinicky applications - whether on the same OS instance or in separate OS VMs, depending on the trustworthiness of the OS.

- bill
.

Relevant Pages

  • RE: Unix runs faster, maybe (was: Re: Educating potential VMS users)
    ... Subject: Unix runs faster, maybe (was: Re: Educating ... CPU, and hence CPU utilization *will* be low, even if the ... not simply involve install OS, add applications, test and move to prod. ... Let's not confuse CPU cache with file-system cache, ...
    (comp.os.vms)
  • Re: VMS (was: GUI v Script)
    ... DEC's lead architect on VMS to do things right with WinNT. ... respect DOS was much closer to UNIX than to VMS. ... services UNIX provides for running applications can usually be counted ... and it provided true networking support, ...
    (comp.object)
  • Re: How can I enter APL on an i386/ASCII laptop keyboard?
    ... with a number of very large applications ... running under AIX and Linux ... small Unix timesharing machines and higher-end Apollo and Sun ... a pretty good job in trying to keep the level of abstraction at least ...
    (comp.lang.apl)
  • Re: sched_yield() makes OpenLDAP slow
    ... >> applications that know exactly what they're doing. ... > yield the processor. ... > transaction, in order to allow other operations to proceed to ... > CPU long enough to clean itself up, and then it must yield the CPU in ...
    (Linux-Kernel)
  • Re: Would a 2nd processor really be a waste of time???? help
    ... >>We are looking at different aspects on what to do about our older unix ... > you are much more likely to be disk and i/o bound than cpu bound. ... >>A second processor does not speed up a server but shares load at current ... >>SCO Unix SMP License ...
    (comp.unix.sco.misc)