Setting these parameters should make little or no difference on whether you
core.

I would not mess with the -b parameter at all.  This is the size of the
buffer used to read traps off the socket and it is typically fine.  Only if
we had an indication that data was being lost would you bump this, and if
you do, it means that trapd would be using that much more storage per read.
Not a good idea to play with this unless you have a reason, since it could
lead to significant memory growth with no benefit.

The -B is the application queue limit and this is one you will want to play
with, but it will not keep trapd from coring either.  What it will do is
keep netmon and ovtopmd from being forced off if you are getting a lot of
traps at once.  The default size of 500 is fine for NetView itself but if
you get a large number of agent traps and you are not willing to cut back
on them (most routers send too many traps and too frequently) then you will
see netmon and ovtopmd being forced off of trapd.  The sky is the limit as
to how big you might make this value, but it does increase trapd storage.
The test group tested trapd at a rate of 100 traps/second and found they
had to increase the queue limit to 35000 to keep the other daemons up.
The only way this could have an impact on whether or not you core is if the
reason for the core were that trapd could not keep track of the storage
correctly when he went to free it, which is always possible.

So I would let the -b parm default, and raise the -B to say 5000 to 10000
and see what happens.   If you are getting a core, then you need to run
/usr/OV/service/readcore against it and call Support.  They'll want to look
at the core.report and the  trapd.log for starters.  And they may recommend
that you run the trapd trace (type trapd -T from the command line) while
you wait for it to happen again.  It will show whether events are being
queued or processed.

The trapd trace in 5.1.1 will start showing what the queue size is when an
event is queued so tuning will be easier in the future.

James Shanks
Tivoli (NetView for UNIX) L3 Support



"Prokott, Joe" <Joe.Prokott AT WESTGROUP DOT COM> on 01/06/99 03:43:57 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView <NV-L AT UCSBVM.UCSB DOT EDU>

To:   NV-L AT UCSBVM.UCSB DOT EDU
cc:    (bcc: James Shanks)
Subject:  trapd Performance Parameters





How does one determine what the values for the "-b" and "-B" for the trapd
daemon should be set to?  We are now having problems with the trapd core
dumping at certain times, with netmon and ovtopmd stopping at the same
time.
We have come to the conclusion that we are getting a lot of traps in a
short
amount of time when this occurs.  We are minimizing the traps so this does
not occur, but this still doesn't help me in trying to determine optimal
values for the "-b" and "-B" queing parameters set for the trapd daemon!
Is
there a way to find out what values we should set so trapd doesn't core
dump
and we don't set them so high and use extra system resources?

Joe Prokott - West Group
Network Architect
610 Opperman Drive
St. Paul, MN  55123
Phone: 651-687-4536
Fax: 651-687-6946
E-mail: joe.prokott AT westgroup DOT com