[Info-vax] VSI and Process Software announcement

[Dirk Munk]

David Froble wrote:
> 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.

True, but this was a tailor made application, and the vendor was well 
aware of the type of system he would get for his application.

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

Not all of course, but when 29GB of the 32GB are not in use ..........

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

Like I mentioned before, this was a tailor made application.

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

Yes, we recently had that discussion in the group. Most likely many 
autogen parameters are more or less obsolete, meaning that you can give 
them such a high value that the OS never will need a higher value, so no 
need to set them any more with a utility like autogen.


Anyway, the idea that setting up a tuned system is difficult and takes a 
lot of time is ludicrous. An experienced system manager just knows what 
to do, he doesn't have to try to find a solution.

One person who knows what he's doing can accomplish something in 
minutes, that people without knowledge can't solve.

Managers don't like ICT, they don't understand it. They don't understand 
why things have to be replaced, or updated, and so on. So if some one 
comes along and tells them that they can have standard solutions for all 
of their problems, and that they don't need well educated staff for 
that, they just love it. Lower costs, that's what they like. That all 
kind of hidden costs will skyrocket, that they don't understand.