Conference azur::mcc

Entered as QAR # 1957 in mcc_internal

    RE: .1
    Thanks for putting it in the qar database.
    
    I am now trying it on an 8650 with 96 Mb of memory and the behvaiour is
    a bit different but still unpleasant.
    
    I got a couple of threads dying and it is using loads of memory and
    90% of the cpu!!
    
    MCC> notif domain caanet
    %MCC-S-NOTIFSTART, Notify request 2 started
    MCC> 
    %Thread 6 terminating with exception:
    %SYSTEM-F-INSFMEM, insufficient dynamic memory
    %Thread 523 terminating with exception:
    %SYSTEM-F-INSFMEM, insufficient dynamic memory
    MCC> disp not
    
    Notify requests currently in progress:
    
    Entry  Status   Command
    -----  ------   -------
        2  Starting notif domain caanet
    
    MCC> disp not
    
    Notify requests currently in progress:
    
    Entry  Status   Command
    -----  ------   -------
        2  Starting notif domain caanet
    
    **Note that it is still starting. I will leave it for a while, but it
    has been starting for about 10 minutes
    
                                 Process DRANSFIELD                
    09:38:17
    
    
    
        State               COM                 Working set           
    22532
    
        Cur/base priority   4/4                 Virtual pages        
    106545
    
        Current PC          0007DD6A            CPU time    
    000:00:22:45.33
    
        Current PSL         03C00001            Direct I/O             
    1891
    
        Current user SP     01C7B2B8            Buffered I/O            
    203
    
        PID                 20600E3F            Page faults           
    22065
    
        UIC                 [TSC,DRANSFIELD]    Event flags        
    E0000000
                                                                    4000000
    0
    
    
        $42$DUS8:[SYS1.SYSCOMMON.][SYSEXE]MCC_MAIN.EXE;2
    
    
    Note that it is using 106,000 pages   50 Mbyes of virtual memory!!
    
    This is with the local namespace. The other test was using DECdns.
    
    Thanks,
    Mike

    RE .0:
    
    Did you try using the MCC_EVT_POOL_SIZE_LOG logical mentioned in the
    release notes?  This controls the size of the event pool global section
    (shared memory on Ultrix).  The default size of the event pool memory
    is now 512K bytes.  If you were using the old V1.1 patch to get a 1Mbyte
    event pool memory, you may very well need to use a larger-than-default
    event pool for V1.2.  The size can be increased to almost 8Mbyte using
    the above logical.  
    
    For VMS, you must define this logical, for all processes running DECmcc
    (using the SYSTEM logical table is easiest), to be the number of bytes
    (use a multiple of 1024 bytes) to be used for the event pool memory. 
    All DECmcc processes must be restarted using the new logical to avoid
    event pool size skew errors.  Stop all DECmcc processes, then restart
    them.  There must be a point in time where there are no DECmcc
    processes running on the system.
    
    For Ultrix, the above holds, with the logical now being an environment
    variable.  Note that as environments hold only for processes and child
    processes, care must be taken that all environments contain the same
    value.  Also, the "ipcrm -m" command must be used to delete the
    leftover event pool memory (shared memory) that is too small. 
    Otherwise, event pool size skew errors will result.  Use the "ipcs"
    command to find the shared memory segment (owned by the user or
    root,daemon).  After the old event pool shared memory is deleted, start
    up the DECmcc processes in the new environment.
    
    Ted

Answer for QAR #01957:
------ --- ------- -------
There is work going on in the x1.2.21 baselevel which should help to address
this problem.

    I just saw this error again on a customer site, and thru much
    discussion locally, finally found a description of the logical
    MCC_EVT_POOL_SIZE_LOG in a pre-FCS seminar given by one of the MCC
    developers.  The previous note talks of this being documented in the 
    release notes, but we count not find it in any of our VMS
    documentation... were you referring to the Ultrix kit?
    
    When might this be documented in a VMS release?
    
    Thanks,
    Dave McAdoo
    Colorado CSC
    

    The maintainer of the Event Manager component of the MCC Kernel is
    out.  But in the interest of DEC customers, I grepped thru the code.
    
    The MCC_EVT_POOL_SIZE_LOG is old.  I think it is still supported but
    the real logical is MCC_EVENT_POOL_SIZE.  Searching the code, the
    default appears to be 524288.  The units are bytes.  If you want to
    test this out, then I would recommend
    
    $ DEFINE MCC_EVENT_POOL_SIZE 786432
    
    This should increase the Event Pool size by about 50%.
    
    But this may only be a band-aid fix.  The Event Pool should be adaquate
    for the needs of even our largest customers.  Remember that the Event
    Pool is only a temporary buffer for transferring events from the sender
    to receiver.  If the pool is getting full, then either some piece of
    code is not picking up the events, or the customers are STOP/ID= 'ing
    processes so they cannot remove their requests, or the senders are
    sending enormous events, or... some other bizzare thing.  So it would
    be helpful to find the cause of the problem.  If my assumptions are
    correct, then the problem will still show up, but it will just take
    longer.  Also remember that this uses up  the Global Section memory,
    so one of the SYSGEN parameters may need to be increased.   (This all
    only applies to VMS machines -- I don't know what happens on ultrix.)
    
    Good Luck,
    -Matt.