RE: [nv-l] Stress Testing NV, looking for opinions

[Leslie Clark <lclark@us.ibm.com>]

You all know that I am a big fan of
Smartsets and all of the ways they can be used, but  we have been
cautioned many times about involving them in event processing.  Every
check involves a database scan. Every check puts a strain on ovwdb. When
it comes to triggering such a scan by something as uncontrollable as events,
design is everything. What works well when your database is small will
not work as well when your database gets big. Every one of of James' lectures
on ruleset design repeats this message. I've seen it to be true over and
over again.

As customers have come to rely more
heavily on Smartsets, some bugs have been flushed out. We saw a big improvement
last year with IY45164. Now I see there is one in the works,  IY56958,
that apparently addresses a new problem in 7.1.4. I applaud all improvements
in this area. The improvements come because people make heavy use of features
they like and report problems when they find them.  So stress away,
but when you hit the design limits, figure out how to use it differently.


We've been told about a million times
that the first check in any ruleset has to be one that eliminates the most
events with the least cost. That means a check that can be done by inspecting
the content of the event - either the Event Attributes or the Trap Settings.
Then, for events that I know will happen a lot, like interface up/down,
I would still think twice about a smarset query in a very large database,
even though that would be really simple. I would try to think of another
way to narrow it down. 

I also reassess my Smartset definitions
from time to time. If there are any that I can eliminate, I do. If I only
need them occasionally, I use nvUtil with the 'e' to check them when I
need them. 

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit