Thanks Leslie, now both you and James are taking pity on me <grin>

===> (Unless you make the default something that is never used! Now there's
an idea.)  To make this easier, skip the gui and use the export function of
the xnmsnmpconf command, edit the file, and import it.

That is exactly what I do. The default community name is one NEVER used in a
device.

===> As for snmpCollect, the answer from Support is news to me. One of the
options
for the snmpCollect daemon is -J. "-J minutes Specifies how often
snmpCollect polls the nvcold daemon for changes in SmartSets. The default is
60 minutes."

Hm, this is interesting. I am wondering how to really debug the snmpCollect
higher-than-expected CPU performance. What are potential contributing
factors maybe I have not taken into account? I will use the verbose tracing
on snmpCollect and see whats out there.


===> We have been told before that nvcold can be a bottleneck, especially
for event processing, and to be careful of having more Smartsets than your
hardware can handle. I would add that reducing the number of stub objects in
the database will help nvcold perform better. An object is an object, even
if it is small, and it looks to me as if several of the daemons are
adversely affected by excessive numbers of useless objects.

To eliminate as many stub objects as possible, I turn topology discovery off
until Monday morning and then run it all day monday and turn it off again.
Then I follow with ovtopofix and ovmapcount to clear the extra objects. I'm
not happy doing this, but I'm living with it. I also suppress more than 90%
of my devices from discovery.