Conference azur::mcc

>> ..each alarm rule appears to take 256 bytes of memory and keeps this
>> memory even if the rule isn't enabled.

When do you see the memory being allocated?  When the rule is created, or
when it is enabled?

How are you determining that 256 bytes are allocated and not returned?



Per invokation of MCC - Alarms will not consume any memory until a Rule is
enabled.  If the enabled rule is disabled - memory continues to be used
for the In-memory Volatile Database (VRDB).  The VRDB maintains information
about Enabled and previously enabled rules.  This is where the Rule Status
and Counter information is maintained.

Once you exit MCC, the VRDB is deleted.

/keith

    Hi...
    
    Let me reply (as I raised this with Bipin)
    
    The memory is taken when rules are enabled (I seem to be able to get a
    number of rules for 256 bytes)
    
    I see that the memory is being taken and not returned by using SDA to
    look at amount of virtual memory in use by the process (ie by
    monitoring the value of JIB+JIB$L_PGFLCNT).
    
    While doing some testing which involved enabling and disabling a large
    number of rules the FCL  image exited due to a lack of virtual memory
    even though I started with a pasge file quota of 30000.
    
    As Bipin says, it is not a major operational problem, but a little
    worrying.
    
    Rgds,
    Graham
    

As far as I know, the virtual page count will never go down - it can only
grow (unless the image runs down of course).

When you free memory, it really goes back to a pool to be reused by your
process.

Each time a rule is enabled - you will see memory allocated (and actually
never freed) for the VRDB; the in-memory database which stores Rule counter
and status information.

The Alarms team have tested the system very thoroughly and feel very confident
that there are no memory leaks.  But as far as memory consumption, Alarms
calls other Management Modules - which could leak.  For example, the SNMP
AM had a problem with the VAX Runtime library whereby memory was not freed
when the 'socket' was closed.  I believe this lost 512 bytes per close 
operation (there is a patch - so this is fixed).

Also - each enabled Rule executes in its own thread.  A thread requires
Stack space.  I'm not sure how much memory is allocated to the thread
but imagine it is more than 32k bytes (!)

Of course, when the Rule is disabled, the stack space is returned - but
returned to a pool to be reused by the process -- and would not decrement
the Virtual Page Count for the process.

>> While doing some testing which involved enabling and disabling a large
>> number of rules the FCL  image exited due to a lack of virtual memory
>> even though I started with a pasge file quota of 30000.

A page file quota of 30,000 pages is too low - I'm not sure what the
release notes say, but I would recommend at least 50,000 pages -- and if
you want to enable a lot of rules, you should have about 100,000 blocks
for the page file.

Remember - never make the page-file-quota larger than the acutal page
file or VMS will hang up  8(

/keith

    It sounds as though this should be easy to test.  If you simply define
    a rule on a rule, and then enable,disable,enable,disable,etc. hundreds
    of times, either the memory usage will stabilize or it will grow.  If
    it grows, then there is a leak in alarms, if not, it is probably a leak
    in something alarms calls.
    
    -Matt.

    Forgive my ancient VMS knowledge but the computation you are describing
    I believe has a unit measure of pages.  You are using 256 pages per rule?
    Hence the ability to exhust memory so quickly.
    
    -kevin
    

The Alarms package collects the data for the Rule Expression by calling
another management module (via the Show directive).

What is the Rule Expression you are using which is allocating all this
memory?

/keith

    RE:.5
    
    I just set up an MCC .com file which enables and disables 1000 rules.
    I am *not* getting a memory leak of 256 pages per enable.  (That would
    require me to have a page file of well over 256,000 pages!)  But I am
    seeing a memory leak.  Without doing the arithmetic, 256 bytes per
    enable seems closer to what I saw.  The leak may not actually be in
    the Alarms code, but in the FCL code.  But to the customer, for all
    practical purposes it is a leak in Alarms (unfortunately for
    Engineers, they do not see the code boundary).
    
    -Matt.
    

    re .-1
    
>>>     The leak may not actually be in
>>>    the Alarms code, but in the FCL code
    
    I see exactly the same behaviour when I enable and disable alarms from
    the IMPM, so it does not seem to be an FCL specific problem.
    
    Rgds,
    Graham

The Alarms package requires the services of the Console Parse Routines - and
therefore needs to load the Parse-Table.  Both the Create and Enable
directive needs the parse-table (but only one copy is loaded for Alarms use).

The parse table requires a lot of memory - last time I checked I saw
over 700,000 bytes allocated for them!  Could this number be working its
way into your calculations ?

/keith

FCL and IM PM have alot of common code. This code includes the parser
routines for interpreting strings and converting them into internal
representations and back again, these are called the PML (presentation 
management library) routines and the PAR (parser routines). Potentially
a common leak could be located in these routines.

jill