Conference azur::mcc

    
    I am curious to know how many domains you have and whether your
    map interface has notification enabled.  At one point with MCC,
    I had over 150 domains and this caused the maps to take up to 15 minutes
    to come up on a 3100 model 76/SPX.  With notification disabled the
    same map appears in less than a minute.
    
    Additionally, my nameserver is also slow, but I see this when doing
    things in line or forms modes such as dir domain *, or show node4
    * all references, in domain xyzzy.  Have you increased your RMS
    buffer size on the DNS server?  The default is 3, which I believe
    caches only three buckets worth of the dns clearinghouse file.

    Regards,
    
    Dave Comfort

    Dave,
    
    	I have roughly 100 domains, but only 7 are DYNAMIC.  Others are
    STATIC.  I have not had this problem before.  I could get my map up in
    a minute or so on a VAXstation 3100/76 32MB system.  Now it takes 5
    minutes or longer.  
    
    	My DNS BUFFER SIZE is 127 (the maximum).  I'm looking into a few
    other issues as well based on suggestions from the DNS notes file
    (note 657).  I'll keep you posted, but any other suggestions are
    welcome in the mean time.
    
    -Dan

    
    Just another piece of info.  Working the boyz at the CSC (Walt and
    Steve), we believe that static domains still will have notification
    enabled.  We were looking into that when I had experienced memory
    problems due to too many domains. 

    
    Dave

    Dave,
    
    Using $ SHOW PROC/CONT  on the DNS$TA process on the DNS server node I
    noticed that 37,000+ page faults.  
    
    I was able to increase DNS performance by increasing WSextent from 2000
    to 16384, WSquo from 600 to 4096, BIOLM from 100 to 4096, PGLFQUO from
    50000 to 75000.  This was done for the DNS$SERVER account via the
    AUTHORIZE utility.  I then did an @SYS$STARTUP:DNS$STOP.COM followed by
    an @SYS$STARTUP:DNS$STARTUP.COM to allow DNS$BACK and DNS$TA processes
    to grab the new resources.
    
    My DECmcc T1.2.7 IMPM startup improved; however,
    
    ------->>>> I am still unable to look into one of my domains.
    
    The IMPM process had a 200,000+ Buffered I/O count after 20+ minutes
    sitting at the LOOKING INTO window.  I finally killed it.  CPU time was
    being consumed like crazy.
    
    I did not have this problem with previous field test versions.
    I can't see how 100+ domains could cause a problem, even with
    notification enabled.  This should not happen.
    
    I also ran the new MCC_AUDIT.COM with  NO CHANGES  being recommended.
    
    Any ideas?
    -Dan

    Yesterday I installed T1.2.7.
    It took me 40 Minutes to get a Map on the screen. I saved the Map, the
    next time it came up after 1 Minute - strange ?
    
    Karl

    
    I have to apologize.  Any statements I made referred to MCC V1.1.
    My customer has not given the green light for V1.2 testing, even
    though I understand we qualify as an external field test site. 
    
    Dan, just out of curiosity, have you tried disabling notification?
    Also, what do your process resources look like... the account the
    I run the map interface from looks like this:
    
    Maxjobs:         0  Fillm:       100  Bytlm:        65536
    Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
    Maxdetach:       0  BIOlm:       100  JTquota:       1024
    Prclm:          20  DIOlm:       100  WSdef:          256
    Prio:            4  ASTlm:       100  WSquo:         8192
    Queprio:         0  TQElm:       128  WSextent:     20000
    CPU:        (none)  Enqlm:      2000  Pgflquo:      80000
    
    
    Dave
    
    

    Looks like Karl found the answer.  I double-clicked on the domain icon
    to "look into" it and just let it run for -->> 46 minutes <<--- before
    it finally succeeded.  I saved the map as Karl suggested, then got out
    of the IMPM and invoked DECmcc again to check it out.
    
    It worked.  I got into my domain in less than a minute.
    
    ???? What happened??
    
    To answer your question, Dave, I did not disable notification.  There
    were no alarm rules defined since I had not completed the installation
    verification of T1.2.7.  I'm assuming by your comments that
    notification being enabled will cause a problem performance-wise,
    especially if I have several domains.  If so, why didn't I have this
    problem before?
    
    As far as my account resources are concerned, my account parameters are
    much higher than yours (e.g., BYTLM=2000000, PGFLQUO=150000,
    BIOLM=4096, WSEXTENT=30000, DIOLM=4096, ...).  I'm running a VAXstation
    3100/76 with 32MB memory.  It is a cluster member (LAVc), but most
    files are on local disks.
    
    Turns out that the DNS problem and this DECmcc problem were not
    related.
    
    I'd still like to know why I had the look-into-domain problem.
    Thanks,
    Dan

There's been a change in V1.2 where the domain hierarchy is always walked
when opening a domain, even if the map window's notification setting is 
"disabled".  This is because the user can request notification via an 
alternative method, and without the domain hierarchy information the 
notifications wouldn't bubble up through the domains.

We're currently doing work to push the domain hiearchy traversal into a 
background thread, so the map window will come up in a reasonable amount of
time for large domain hierarchies.

>    it finally succeeded.  I saved the map as Karl suggested, then got out
>    of the IMPM and invoked DECmcc again to check it out.
>    
>    It worked.  I got into my domain in less than a minute.

This might point to a performance problem with the IMPM autoplacing members in a
domain?

If it varies open-to-open, with things slowing down significantly when a 
large amount of time elapses between opens, then perhaps DNS caching (only 
available with Phase V implementations) is the reason.

    RE:.9
    
    Pete,
    
    The worst offender was a domain which contained roughly 40 entities
    that had been autoplaced.  There were also about 15 STATIC domains in
    this domain along with the autoplaced entities.
    
    Once the map was saved, everything was fine.
    
    I didn't like what happened, though.  I wish you could come up with a 
    better (read this "faster") way to get the job done.
    
    During the process of gaining information, I once spent 63 minutes
    looking into a domain!  The DNS$TA process on one of our nameserver
    nodes (DNS V1.1 on VMS V5.5) was consuming 35% CPU time and clicking
    off 30 Buffered i/o's per second.  There were over 300 Converted locks
    per second.  
    
    My network management workstation (VAXstation 3100/76 32MB) was
    hammered by the IMPM process (40% avg CPU, 126 Buff I/O per sec).
    
    -Dan

    I reviewed the algoritm with William Kwak this morning and see
    the problem (actualy he found it and told me to fix it :-).
    
    The alternate id support with respect to entities in the domain 
    but not in the map file needs to be optimized.   This will
    be addressed for v1.2.
    
    /Jim  
    
    

    Nice job, gentlemen.  Anything else you can do to speed up DNS access
    would be most appreciated.
    
    MCC is looking much better with each iteration.
    
    Thanks,
    Dan

A number of items have been mentioned in this note.  It is time to 
sum things up. *ALL* of the definiciencies that you have noted and
some one from mcc has acknowledged (thanks Jim, Pete) have been
addressed and their fixes are now in the kit getting ready for
SSB.  Our internal test we are now using have a domain hierarchy that
includes over 800 domains within it. With the latest kit it
takes less than 1 minute (50-55 seconds to be exact) for the map
to become operational. Please noe though that notification still
takes a while before it becomes active. The way that now works is
that the events as soon as they are available will show up in the
notification window, but color changes will still have to wait 
until the map notification structures are setup, and in a large hierarchy that 
can be a substantial period of time (5-45 minutes depending upon 
how huge the structures are), unless you are dealing with a smaller
domain.