| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2173.1 | Check sysgen params and process quotas. | TOOK::MCPHERSON | Scientific progress goes 'Boink!' | Thu Jan 23 1992 09:04 | 8 |
| 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.2 | each batch=memory | ICS::WOODCOCK | | Thu Jan 23 1992 11:55 | 10 |
| 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.3 | also up gblsections | TOOK::CALLANDER | MCC = My Constant Companion | Fri Jan 24 1992 10:06 | 10 |
| 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.4 | Thanks - What's about HW config. Guidelines??? | MLNCSC::MISLER | | Mon Jan 27 1992 03:51 | 29 |
| 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.5 | Alarms use of memory | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Mon Jan 27 1992 08:01 | 27 |
| 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.6 | Not enough memory | TOOK::R_SPENCE | Nets don't fail me now... | Mon Feb 03 1992 09:37 | 9 |
| 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
|