[Info-vax] VSI and Process Software announcement

Dirk Munk munk at home.nl
Mon Sep 26 14:55:19 EDT 2016


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.






More information about the Info-vax mailing list