[Info-vax] primary and secondary page and swap files, AUTOGEN, SHOW MEMORY/FILES

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman
> Sent: 31-Dec-14 5:20 PM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] primary and secondary page and swap files,
> AUTOGEN, SHOW MEMORY/FILES
> 
> On 2014-12-31 18:45:18 +0000, Kerry Main said:
> 
> > Sign of the times .. Seagate now has an 8TB disk available for USD $260
> 
> It'll be interesting to see what VMS can make of modern x86-64
> hardware
> in terms of performance and scaling, and getting there will involve no
> small effort from the folks at VSI for the port and then for the
> associated new features and updates.
> 
> The HP Enterprise Server folks would certainly like to sell some of
> their gonzo-core[1] juggernaut-class servers, but something of the
> scale of a Mac Mini or Mac Pro could replace many of the existing VMS
> boxes I've been dealing with.  Yes, there are folks that need servers
> of the scale of that HP ES is offering.  But those HP ES boxes
> definitely aren't entry-level or even typical boxes.
> 
> ###########
> [1] Mr. Torvalds starts off a discussion on multi-core and scaling:
> <http://highscalability.com/blog/2014/12/31/linus-the-whole-parallel-
> computing-is-the-future-is-a-bunch.html>
> 

The HW vendors have progressed exponentially faster than the
computing needs of most customers - on all platforms.

I agree with Hoff that HP (and other vendors selling such big iron) 
is in for a very tough time selling monster boxes in the future. 

Key points:
- Solaris, AIX, HP-UX workloads are migrating to commodity OS's,
so there is a reluctance to spend big $'s (6,7 digits) on "non-strategic" 
platforms.
- Most X64 HW is now NUMA based which causes all sorts of OS
scaling challenges wrt to resource and process scheduling on local 
vs remote memory. Just because an OS states it "supports" large 
numbers of cores does not mean Applications will scale in a way
that meets expectations. An OS vendor can simply blame the 
poor  NUMA / large core scaling on Application design and walk 
away.
- Solutions focus requires DR review, hence if a company buys a 
monster core box, then they really need 2 monster boxes for even 
basic DR which then doubles the HW/SW costs.
- commodity OS's favour scale out strategies - not scale up. This
Is partially due to their culture of one Bus App per OS instance,
technical challenges associated with App stacking on the 
same OS instance and the simple fact that most ISV's have no idea
of how to structure their App to take advantage of large numbers
of cores based on NUMA designs.
- Licensing challenges with monster boxes associated with key 
vendors like Microsoft SQL and Oracle DB's make licensing costs 
ridiculous (all cores need to be licensed even if only a small subset 
used for DB)
- Likely 75% of most Cust's today upgrade not because of lack of
performance, but rather for improved HW/SW support and 
maint cost reductions. Of the remaining 25%, most requirements
would easily be met with less than 32 cores (possibly dual boxes
for high availability). A small subset of something like 5% need 
and/or can effectively scale to greater than 32 cores.

Summary - A small number of OpenVMS Custs might take advantage 
of greater than 64 cores because OpenVMS Custs has been App
stacking forever and have dealt with NUMA since early Alpha days. 

However, similar to big Alpha boxes, what will likely happen is that 
these monster core boxes will include HW partitioning (LPARS, NPAR) 
with very fast interconnects. This would provide capabilities to then
cluster these partitions together with added OpenVMS Galaxy type 
functionality e.g. shared memory between OS's and dynamic 
migration of CPU's between OS partitions based on business rules.

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com