Re: [nv-l] Trap Tuning

You are a little confused about the way this all works. Let me try to explain.

trapd receives all traps, period. There is no way to stop him from doing that. During a storm, he buffers them in a queue and just keeps filling it rather than processing them, as long as there is data on his incoming socket. Tests have shown that trapd can get as many as a hundred traps per second and not fall over, so this has nothing to do with your problem. You do need to worry about what happens after the storm subsides and now all the daemons and processes down the line have to deal with the huge backlog of traps to process.

If you want to buffer what he gets, then you can install an MLM and used midmand as the primary receiver. He can then threshold incoming traps and send just what you want to trapd. See the MLM User's Guide for details.

I don't know what the problem is with actionsvr dying. Perhaps you should call Support about that, especially you are getting a core in /usr/OV/PD/cores/actionsvr.

But the parameter you found, in the Nvevents app-defaults file has nothing to do with actionsvr. That parameter is for nvevents, which is the process which displays current event windows. If you did not use a ruleset or ovxbeep, but configured your pop-ups right out of trapd.conf (using xnmtrap and the button which says "PopUp Notification"), then nvevents would issue the pop-ups and keep track of them. He would only issue the number equal to maxDisplyMsgs and if there were more to display, then he would issue one more which said he has more popups to show you but he cannot, until you acknowledge some of the others. As you "OK" the outstanding ones, he issues more. He acts as a throttle to the process.

If a throttle is what you need, and you want, or need, to do that from a ruleset, then you either have to write your own script which issues ovxbeeps in the same sort of way, or you need to re-design your ruleset so that it is more selective about when to issue a pop-up. I have seen people bring a system to its knees by doing something like issuing a popup for every new node added message, forget that it was in place, and then re-start discovery by clearing the databases. Of course, in that case thousands of popups might be issued. Actionsvr will cheerfully fork a new process and issue ovxbeep until you run of available processes or virtual memory, and then the system starts cancelling things with a signal 33. The bottom line is that ovxbeep and ovxecho are convenience routines, but like all conveniences they must be used wisely.

James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group

"Jeffrey LiVolsi" <JLiVolsi AT jsa-usa DOT com>

06/12/2003 08:51 AM

To: <nv-l AT lists.tivoli DOT com>
cc:
Subject: [nv-l] Trap Tuning

Hello,

Would like to know if there are tuning paramters that can be modified to
increase the amount of Traps that can be received by Netview. For example:
If a device experiences a problem, a flood of traps can be sent to Netview.
Netview may not be able to handle the bursts of traps. Is there a buffer/que
that can be increased so that none of the traps are lost? Is there a way to
see if the buffer/que gets overloaded?

We are experiencing a problem with actionsvr dying using rulesets. The
ruleset initiates OVXBEEP with pop-up windows. In looking at the
/usr/OV/app-defaults/NVevents file I see a parameter call maxDisplyMsgs =10.
I believe this controls the amount of popup windows that can be opened at
one time. If this gets exceeded, will this cause actionsvr to die?

Thanks,

Jeffrey LiVolsi

---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)