Conference azur::mcc

6439.0. "Alarms enable batch job eats memory." by COPCLU::EBC () Fri Apr 12 1996 13:52

VMS 6.1, DECmcc V1.4-1.

One of our customers has about 100 alarms enabled by a batch job. The job start
alright, but dies after 30-180 minutes with a quota exceeded error.
After the job has started it has an allocated pgflquota of appr. 65000 at which
it remains constantly until after the 30-180 minutes it starts paging like mad
and allocates pgflquota until it reaches one of the limits implied by pgflquo or
virtualpagecount.
These values have been increased repeatedly and are now both above 200000.

The behaviour makes me think there is a memory leak somewhere in MCC. Are we
aware of any such problems ?
The alarms are on bridge, dna IV and SNMP entities.

Erik 

End of log file:
!
SHOW DOMAIN BACKBONE RULE HISTORIAN_HAS_STOPPED ALL CHARACTERISTICS,-
        AT START (+999-00:00:00)
%DEBUGBOOT-W-VASFULL, virtual address space is full
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-INSFMEM, insufficient dynamic memory
%DEBUGBOOT-W-VASFULL, virtual address space is full
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-INSFMEM, insufficient dynamic memory
$ EXIT
  SYSTEM       job terminated at 12-APR-1996 12:41:15.64

  Accounting information:
  Buffered I/O count:          128536         Peak working set size:   24600
  Direct I/O count:             13493         Peak page file size:    230000
  Page faults:                 172583         Mounted volumes:             0
  Charged CPU time:           0 00:33:02.23   Elapsed time:     0 03:02:18.63

Process quota shortly before failing:
Process Name: BATCH_164   State: HIB   Start-time: 12-APR-1996 12:39:33.53
Image Name: MCC_MAIN   PID: 22DB   CPUTIME: 1949.96  seconds

Process Quota Information:
             Quota     Used    (pct.)  MAX_Used since 12-APR-1996 12:39:23.04
ASTLM          600       6       1%       6
FILLM          300      18       6%      18
DIOLM          100       0       0%       0
BIOLM          100       3       3%       3
BYTLM        71040       0       0%       0
ENQLM         2000      47       2%      48
TQLM           200       3       1%       3
PGFLQUOTA   250000  211200      84%  211200

Working Set Information:
                     Max_size
WSEXTENT     24600
WSQUOTA       4096
WSDEFAULT     2048
WSSIZE       24600   24600
PAGES        24600
FAULTS      160172

    	Try DETmcc...
    
    I believe what you're seeing has been documented in the "known bugs"
    archives... unfortunately, as you may or may not know, most if not all
    of DECmcc development has ceased to exist...
    
    We have a large telecom that possibly has as many as 2-300 alarms that
    run in batch queue(s).  They use a product called DETmcc to ensure that
    the alarms are setup properly and stay in queue...
    
    Although DETmcc is not an official product anymore it works!  Try
    calling the CSC and asking for Scott Keane... I know Scott will kill
    me.... 8^).
    
    One thing you didn't say, but I thought I'd recommend... are you using
    polling alarms?  If so, you might consider event alarms... although
    they are more complex to setup, they pay significant dividend in
    overall performance... less costly!
    
    You don't describe youre environment, but I'd recommend that you be
    extremely *generous* in your pgflquota... like 100k.  Also, what do you
    have for memory, CPU, etc.  If you're not using 128k on a VAX4090A or
    greater have your client call our Sales Rep... 8^)
    
    I've got a VAX4705A with 448mg memory and lots of blown out quotas that
    display to an Alpha running digital-Unix and I wouldn't try anything
    much less...
    
    Also, there are patches out of the CSC and/or Valbonne that will ensure
    you can get to V6.2; then you can through 2 gigabytes of memory at the
    beast...
    
    /Mic
    

Mic,

Thank you for responding. What/where is the "known bugs" registry ?

I actually have two customers with this sort of problem now. Both run on systems
that are moderate in cpu/memory capacity, but I find it hard suggesting them to
invest in larger systems for running MCC in it's current state with no
development and little support. I would rather suggest spending the money on
migrating to Netview.
DetMCC might be an alternative solution in the short term.

Erik