Conference azur::mcc

4661.0. "SYSTEM-F-BYTLM with DECmcc v1.2.3 and Alarms" by BACHUS::FOLENS () Wed Mar 10 1993 09:03

    I have a site that's using DECmcc BMS v1.2.3 on a VS4060 with 32Mb of
    memory and 2 * 425Mb disks. The pagefile and the mcc_common directory
    are placed on the 2nd disk (not the system disk).
    There are several maps created and we are using a local namespace with
    aprox. 100 entities.
    Alarms have been created to test out the reachability of stations which
    includes pc's and plc's. There are also alarms on bridges that are testing 
    the port status.
    All system and user quota's have been checked with mcc_audit and some
    parameters even have been increased to overcome problems with TSAM access.
    All alarm rules are enabled from the map window.
    When there's something happening on the network, such as a bridge going
    down, several alarms are triggering which causes the system to slow
    down dramatically. When you do a 'show process/quota' of the
    decw$session process which is the parent process of the mcc-session you
    see the 'buffered I/O byte count quota' decreasing with about
    100kbytes. These 100kbytes never come back again (except if you restart
    DECmcc). After this happens you see the 'buffered I/O byte count quota' 
    decreasing by about 1kb each time a alarms goes off. After a while
    the 'buffered I/O byte count quota' reaches a value of aprox. 3000
    bytes and the contents of the alarms info field is one of these:
    
    	     1. The requested operation cannot be completed
    		<EOS>%system-F-bytlm exceeded byte count quota
               
    	     2. The requested operation cannot be completed
    		<EOS>mcc-E-getchanerror error assigning a channel to device
    		<EOS>%system-F-bytlm exceeded byte count quota
               
    	     3. The requested operation cannot be completed
    
    The bytlm count of the account running DECmcc has been increased to
    400000 without a result. It only delays the problems.
    When you try to disable an alarm, a s'show status' returns a
    state=enabled and substate=shutdown in progress. But the alarm never
    get's disabled.
    I have tried to reproduce the problem on my vs4060 with 48Mb of physical 
    memory but the 'buffered I/O byte count quota' drops from 64k to 26k
    and then increases and decreases dynamically when an alarm goes off.
    
    Can I do something on this behaviour? Will v1.3 solve this problem?
    Do I need to increase physical memory from 32Mb to 48Mb (although
    memory utilisation shows only 2/3 of the memory is used)?
    I have the impression that the alarm FM is causing the 'buffered I/O
    byte count quota' consumption.
    
    Any hints where to look at?
    
    -Geert-
    

    
    After a lot of testing with my own VS4060 (48Mb), I couldn't get the
    BYTLM problem. I monitored the quota's of my process and saw the
    'buffered I/O byt count quota' decreased from 64k to 1k at some
    moments when a lot of alarms fired at about the same time. At those
    moments you are not able to do anything with the window interface.
    It doesn't respond anymore. So you loose control to your network.
    I can imagine that customers will not like this at all. What
    possible actions can you take to avoid this situation when a kind
    of storm of events and alarms occur during a failure of a part of
    your network? 
    Maybe it would be a good idea to put a sort of flag on a alarm rule.
    An alarm goes off when the expression is true. Alarm rules that are
    testing the reachability will give an exception when an entity can't
    be reached. With this kind of alarm rules you should be able to 
    specify a flag to disable the notification until a clear of the rule
    occurs. This would also prevent an overload of the notification window.
    
    -Geert-
    

    I've now upgraded the system mentioned in .0 to v1.3. The performance
    is much better but the problem of the exhausted bytlm still exists when
    a lot of alarms are going off at the same time. Should I increase the
    physical memory from 32Mb to 48Mb which is the minimum required
    following the SPD?
    
    	-Geert-
    

How many alarms are firing at once (total) when you have the problem?
What objects are the alarms created for? 
Can you use wildcarded alarms anywhere?

/doug

    
    Alarm rule's are defined to check the reachability of every bridge and
    every station (PLC's in this case). The reachability test is done every
    30 sec's and we are testing about 4 bridges and 5 stations.
    Will the use of wildcards in the alarms reduce the overhead?
    
    -Geert-

re: .4

>>  Will the use of wildcards in the alarms reduce the overhead?

  Yes .. 100 rules written to process 100 entities consumes 100 threads
  (provided they are all enabled, that is).

  1 rule with a global wildcard processes all the specified entities in
  a Domain, and consumes only 1 thread .. the difference is the entities
  will be processed 1 at a time rather than in parallel.  What this means
  to you is it will take longer to process all entities .. but by using
  less resources (less threads and memory).

  Also - if you add or remove an entity from the domain, the global
  wildcarded rule will automatically add or remove the entity from its
  list of entities to process .. you don't have to stop and restart the
  rule.

  Global Wildcarded Rules is a real winner here !!

  /keith 8)