[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2173.0. "Help on DECmcc configuration" by MLNCSC::MISLER () Thu Jan 23 1992 11:18

Hi,
I have a problem with our DECmcc system when using alarms and batch 
to start them.

1) HARDWARE CONFIGURATION
-------------------------

Vaxstation 3100

Memory 32 M 

2 RZ24 - 1 RZ55

+......


2) SOFTWARE CONFIGURATION
-------------------------

DECMCC V1.1

+........


3) DECMCC CONFIGURATION
-----------------------

1 map for world

1 map for Europe

1 map for Italy

1 or more maps for locations.

Total : 20 maps
        47 nodes of which 20 are Decnet routers and one is IP Gateway.


4) ALARMS
---------

We use these alarms :

- Alarms on unreachability/reachability of routers based on polling.
  When the routers becomes unreachable the alarm switch to poll the opposite.
  We use one batch for each router.Total : 20 batch
  (These are the only alarms rule defined by the DECmcc Configuration 
   Guidelines that we have slightly changed)

- Alarms on event circuit down.
  These alarms are grouped in a single batch at the region level.
  Total : 3 batch.

- Alarms on event circuit up (to change the color when the circuit comes up)
  As above we have 3 batch.

- Alarms on circuit substate change (based on polling)
  As above we have three batch.

As a total we have 118 alarms grouped in 29 batch processes.

We don't have alarms on bridges,terminal servers,Vitalink...
We don't have yet batch processes for performance analysis and reporting

When we activate all this alarming system the DECmcc station crashes.

Our system manager tried to optimize the performances assigning a page and swap
file to each disk :
- system disk (RZ24) pagefile 12400 blocks swapfile 4600 blocks
- user disk 1 (RZ24) page file 20000 blocks swapfile 5000 blocks
- user disk 2 (RZ55) page file 100000 blocks swapfile 2300 blocks

My question is NOT how to solve this problem (I can modify the procedures and
reduce the number of batch if necessary),but some guidelines to understand why
this happens and how to avoid that this happens again.

Is the number of batches the problem?
How can I calculate what can I do with a given hardware?
Or conversely,how can I calculate the needs for the DECmcc system,given the 
number of nodes,alarms,batches,...in term of CPU,memory,disk,....

I am also curious to know what's happening to the other Easynet areas.
How many alarms,batches,reports and so on are they able to manage with a 
Vaxstation 3100 ?

Thanks for the help

Donatella

(This message has been cross posted in NMT conference and MCC conference)
T.RTitleUserPersonal
Name
DateLines
2173.1Check sysgen params and process quotas.TOOK::MCPHERSONScientific progress goes 'Boink!'Thu Jan 23 1992 12:048
What does DECmcc say when it "crashes" ?

Please verify the SYSGEN params and process quotas are sufficient.  The
quickest way to check this is to snag Rob's AUDIT_MCC.COM and use it to peruse
your system setup.   There's a pointer to it somewhere in this conf.  Try
dir/title=audit and see what that gets you....

/doug
2173.2each batch=memoryICS::WOODCOCKThu Jan 23 1992 14:5510
Hi there,

When I initially implemented MCC it was with a 3520 w/32M. It is has more CPU
but the memory is the same as yours. I had started all our alarms via 12
batch processes and free memory was at the verge of death. Combining down to
one or two batches helped a great deal but utilimately I ended up going to
more hardware to get the rest of the implementation running.

hope this helps,
brad...
2173.3also up gblsectionsTOOK::CALLANDERMCC = My Constant CompanionFri Jan 24 1992 13:0610
    also audit is a bit low on the gblsections sysgen param, up it
    to around 600 if you want more reliable events with the 1.2 kit.
    Also make use of NOTIFY instead of rules if all you are trying to
    do is to turn an icon a color. Alarms is for added value work like
    using events to trigger off command procedures/actions. A note
    explaining how to use retargetting and notify using events from a
    router to monitor adjacencies was entered earlier this week.
    
    jill
    
2173.4Thanks - What's about HW config. Guidelines???MLNCSC::MISLERMon Jan 27 1992 06:5129
Thanks for all the answers.

1) The system parameters are all OK.
   We verified them with the AUDIT.COM procedure.

2) I made some telephone calls around and I found that other people 
   discovered the same problem that I found when the alarms were growing up.
   It seems that each alarm takes a lot of memory (from 2000 to 5000 pages
   of memory),so the only solution is or to buy new memory or to reduce the 
   number of alarms (maybe someone who implemented the product can explain
   why is it necessary so much memory?)
   It seems also that with version 1.2 you can use the *,so the number of 
   alarms can be greatly reduced.Is it correct?

3) Jill,I agree that for having a color turned on the map only notification is
   sufficient,but I would like to have also mail,to automatically inform for 
   example Call Handling,so the alarm is needed.

4) I think it will be usefull (not only for me) if someone would be able
   to give us some general guidelines for configuring a DECmcc system.
   I understand that this is a not easy topic because you may do very different
   things with such a system,but for example on Easynet we must do some
   basic and well indentified acitivities as monitoring routers and reporting
   about bugs and traffic.
   We have no hardware guidelines about it (the old are not sufficient) and
   for the budget it will be very helpful.

Ciao
Donatella
2173.5Alarms use of memoryNANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamMon Jan 27 1992 11:0127
RE: .4
> 2) I made some telephone calls around and I found that other people 
>    discovered the same problem that I found when the alarms were growing up.
>    It seems that each alarm takes a lot of memory (from 2000 to 5000 pages
>    of memory),so the only solution is or to buy new memory or to reduce the 
>    number of alarms (maybe someone who implemented the product can explain
>    why is it necessary so much memory?)
>    It seems also that with version 1.2 you can use the *,so the number of 
>    alarms can be greatly reduced.Is it correct?

Each Alarm Rule executes in its own thread.  A thread requires its own stack
space, currently this values is 30 pages (15k bytes).  In Addition, there
are data structures dynamically allocated for each Rule: for the Binary Tree,
the Call Arguments used to retrieve the data for the Rule, the Counter and
Status information (for Show mcc 0 alarms rule <x> all counter, all status).
This all adds up.

For v1.2 some Alarms clean up work is being done and should help in the memory
consumption area.  Also some problems with the RPC mechanism on ULTRIX
(which will be fixed for SSB) have been identified, which has accounted
for a low number of rules enabled.

Global Wildcards are uncommitted for v1.2 -- but something that is obviously
needed.  Some advanced work is currently underway, and could possible make
it for v1.2

/keith
2173.6Not enough memoryTOOK::R_SPENCENets don't fail me now...Mon Feb 03 1992 12:379
    The obvious problem is that 27 instances of DECmcc were trying to run
    in 32mb of memory and only 100000 blocks of pagefile. I max out 24mb
    with 4 instances and 150000 blocks of pagefile.
    
    In this case, small memory leaks are multiplied by the number of
    processes trying to run. I suspect the memory manager got overworked
    trying to handle all the paging.
    
    s/rob