[Info-vax] Performance benchmarks, was: Re: VMS Software Inc. OpenVMS 8.4-1H1 Boots on i4 System

[Jan-Erik Soderholm]

David Froble skrev den 2015-03-19 15:44:
> 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.
>

What I seems to have seen over the years is that if you have a
single CPU system where your I/O is fast enough to make just
about any (batch or other) job hit 100% CPU, you get a more
"nervous" system where the users sees larger differences in
respons times, even if they might be shorter as a whole. A lot
of the activities that earlier had been spread over time, now
instead hogs the CPU and stalls other users. If these are
short activies, a second CPU will smooth out these "edges"
quite a deal.

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

Same here. Approx 99.7% of all database page reades are from memory
in our system.