[Info-vax] VSI and Process Software announcement

[David Froble]

Dirk Munk wrote:
> Stephen Hoffman wrote:
>> On 2016-09-25 11:43:29 +0000, Dirk Munk said:
>>
>>> Kerry Main wrote:
>>>> You seem to want to make it so easy that an end user could install an
>>>> OS into a prod environment.
>>
>> Everybody has to go through this, just because we had to walk to school
>> all winter long, in the snow, up hill, both ways?
>>
>>>> Imho, that is just crazy. Regardless of the method, I want
>>>> experienced SysAdmins to have their hands on new OS deployments. Yes,
>>>> I know there is work to be done to make it easier than it is today,
>>>> but the bottom line is there are just way to many variables and
>>>> landmines that could impact other OS's to let a rookie deploy a new
>>>> OS to a prod environment.
>>>
>>> You're absolutely right. I've worked in an environment where
>>> everything was set up with easy to deploy templates. etc. The result
>>> was that no one understood what they were doing, they didn't
>>> understand all these settings because they didn't have to think about
>>> them. If there were problems, they didn't know where to look, or how
>>> to fix the problems.
>>
>> I remember the uproar over the shift to depot repairs and board
>> swapping, too.   When the repair techs stopped using solder and a 'scope.
>>
>> Welcome to modern computing technology.   We each — we all — depend on
>> the knowledge of other folks.   Of the code and the tools of others.
>> None of us are experts in everything.   We are increasingly integrating
>> our servers and software with more packages and tools and platforms.
>> Trying to make our configurations and deployments easier, more
>> manageable, more repeatable, and requiring less human interaction is the
>> goal that most of us have.
>>
>> I'm glad that OpenVMS moved forward.   Part of moving forward is keeping
>> the best of the old ideas, and rethinking or replacing the areas that
>> are no longer advantageous.    That includes reworking or rethinking or
>> replacing the console serial line, and manually-configured, local
>> deployments booted from DVD, among other approaches that seem
>> increasingly antebellum.
> 
> 
> Let me give you a real world example of the results of this kind of 
> thinking.
> 
> An applications wasn't performing very well, it was a bit unclear why, 
> but there were more problems at that datacenter.
> 
> So we gave that application a brand new x86 server with 32GB of memory, 
> in another datacenter.
> 
> First it got a *standard* linux installation. Then the SAN luns were 
> added. I know how important disk alignment is, so I personally took care 
> of partitioning and formatting the luns, that was not a standard way of 
> setting up the luns.
> 
> Then the application was installed. I had told the database 
> administrator several times to make sure his databases got sufficient 
> cache.
> 
> A few months later my network colleague asked me if it was normal that a 
> database fetch took a certain amount of time. I told him that was far 
> too much, and asked him about the application.
> 
> And as you can guess it was this application. First I couldn't 
> understand why, but then I got a suspicion.
> 
> I went to the database group, and asked how much free memory that system 
> had, and yes, it was 29GB.
> 
> So I asked about the database settings. Well, they had done a *standard* 
> Oracle install, with 1GB of cache per database, leaving 29GB wasted.
> 
> I suppressed some curses, and kindly asked them to increase the caches, 
> and to use the memory in the system.
> 
> That solved the problem, as you can guess.
> 
> An exception? No a *standard* problem with all those *standard* 
> installations. So much so that the support people now have the 
> *standard* reply "check your database cache and your free memory" when 
> they are confronted with performance problems.
> 
> 
> 

It's sort of difficult for an application vendor to have one size fitting all.

Yes, they could have a tool that looks at system memory, then uses all of it, 
regardless of whether other applications also need a bit of memory.

For the most part, they ship a "standard" set-up, and some might even provide 
some tuning tips.

So, one size most likely won't fit all.  Is there answers?  Yes, to some extent. 
  We've had AUTOGEN since forever.  It can be helpful.  It can also hurt, in 
some cases.  Could it be improved?  I'd say that the environments AUTOGEN was 
developed for really don't exist anymore.  An enhanced / new version might 
handle GB of available memory in a different manner than there were no GB of 
memory.  But it still won't be "everything".

There will always be a need for more, even if the beancounters don't want to pay 
for what they might need.