The SELECT FAILED message happens when you shut down Nways background
processes before the foreground processes are all the way up. It's kind
of like you cut the legs out from under the foreground processes. Your
"constant" and ssmingly endless synchronization is probably the result
of some sort of system restraints.
I've seen this when the seed file has devices that are either not
pingable or don't have SNMP available. If you have hostname in the
seedfile it adds some overhead doing DNS lookups on them, and if you
have hostnames in there and they're not resolvable, it gets very sloppy.
Check netmon.trace for messages about the seedfile.
Leslie's idea about letting the box go idle is good- If you do ovstop
cmld, then start the gui with ovw, cmld won't start up and the iubd and
ahmtopod won't be running, so you let netmon get finished, then do
ovstart cmld. Some of the foreground Nways things will behave oddly,
but you won't be chewing up CPU.
If you're tuned up (i.e., polling set up, ovwdb cache OK, DASD for
logging, plenty of memory and paging space) the synchronization
shouldn't be so bad. If these things are not correct, you are going to
start up very very slowly.
Leslie Clark wrote:
>
> I always use vmstat and monitor or top when I'm putting in an Nways. And
> tail the
> nettl log. I would do an ovstop cmld and let the machine idle out, with the
> map down.
> And then ovstart cmld and watch what goes on. Iubd and ahmtopod will do a
> lot
> of work at startup. They may take turns a bit, and will probably peg the
> box, but
> will eventuallly finish polling all of the devices they are responsible
> for. Then the
> box may well idle out again. (Check the polling parameters for Hub and ATM
> -
> if you are running very constrained, set them to demand vs regular.) After
> they
> idle out, then start the map and watch what happens. One thing that will
> still
> cause synchronizing at the opening of the map is the MAT. By default it
> does
> a lot of syncing at map open. You can defer this activitiy by editing the
> ed.conf
> file (/usr/lpp/mgtapptran/something..) and add this option on the Rnvgate
> entry: -NO_SYNC_AT_START
> They will then be created and sync'd up when you do a Tools..AppTrans....
> Refresh. I'm not sure they are still recommending this, but I've been doing
> it.
>
> The idea is to know just how constrained the envionment is, and to see what
> is normal. Try not to do too many things at once, as they will all slow
> down
> the synchronizing that is normally done by ipmap when you bring the map
> up. Also, watch the nettl log. You may find messages that indicate that it
> is having
> trouble with microcode levels on some of the devices. I had some 8260s
> recently
> that just could not be successfully polled by iubd until they reset the
> TMACs.
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> (248) 552-4968 Voicemail, Fax, Pager
>
> ---------------------- Forwarded by Leslie Clark/Southfield/IBM on 03-22-99
> 11:58 PM ---------------------------
>
> Jane Curry <jane.curry@SKILLS-1ST.CO.UK> on 03-18-99 05:27:29 AM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> NetView <NV-L@UCSBVM.UCSB.EDU>
>
> To: NV-L@UCSBVM.UCSB.EDU
> cc: (bcc: Leslie Clark/Southfield/IBM)
> Subject: Nways - constant Synchronize
>
> Still on AIX 4.3.2, F.w 3.6, NetView 5.1, Nways 1.2.2.....
> Sometimes we see the NetView map hang on Synchronizing (not always).
> ovstop nvsecd takes forever to run so, using Jim's hint, we kill
> ahmtopod and nvot_server. In the Synchronizing fault condition, this
> leads to constant screens-full of
> Warning: Select failed: error code 9
> Prior to doing the kill, neither of these processes (or any others) were
> taking significant CPU - afterwards cmld and iubd are grabbing lots of
> CPU - it looks like the nways processes get half started and hang around
> the startup of ahmtopod.
>
> Any other comments or experiences to share?
> Cheers, Jane
> --
> Tivoli Certified Consultant
> Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
> Tel: +44 (0)1628 782565
> Copyright (c) 1999 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
> reserved.
|