[Info-vax] Performance benchmarks, was: Re: VMS Software Inc. OpenVMS 8.4-1H1 Boots on i4 System
David Froble
davef at tsoft-inc.com
Thu Mar 19 10:44:30 EDT 2015
IanD wrote:
> In our case, we ditched an 8400 and put in the equivalent emulated
> solution which simply flies (8 cpu's) running on a very high end
> proliant (the highest at the time before the current generation)
I'm going to guess that it's also much cheaper to run, less floor / rack
space, and such.
> Another system we did 'virtualise' was an AlphaServer DS10L 67/616.
> The biggest gain by far was in the I/O
That wasn't so hard. The DS10L was intended as a compute node in a rack
of multiple DS10Ls.
> For the 8400 it made a reasonable difference (I don't have the data
> and it would take too much effort to dig it out of the archives, from
> memory things sped up by around 20 - 40%, don't quote me on that
> though) but the the DS10, we actually created an issue! (or uncovered
> one)
>
> On the real DS10 we had 1 cpu and a bunch of slow disks. After the
> virtualisation was done, the system hit 100% cpu saturation on almost
> any job run! The I/O is so dam fast that unless you buy an excess of
> cpu's the quicker I/O will transfer over to a cpu very quickly. Due
> to licencing costs and the project closing, we are stuck with a cpu
> bottlenecked system now *sigh*
Well, I would not call it "bottlenecked". I'd say that be improving the
I/O bottleneck, you're now getting as much out of the system as it can
provide. Except for a more powerful system, can't ask for more.
> The new 8400 is in a cluster and even though we used flash memory for
> the disks on the 8400, the other member of the cluster is using SAN
> which now has become the I/O bottleneck where-as before it was the
> 8400 with it's slower SCSI local drives. I almost never see queued
> I/O's on the virtualised 8400 :-)
>
> Sorry I don't have any figures to show but if you are going the
> emulator route and your doing a 1:1 replacement of cpu numbers, then
> pay particular attention to how your system may behave when the I/O
> throughput is increased orders of magnitude. A cpu bottleneck can
> very quickly materialise
In our case, with the gobs of memory available on the itanics, and the
cacheing, most of our database is sitting in memory. Can't beat that.
Want to see the system crawl? Turn off cacheing ....
More information about the Info-vax
mailing list