Re: [NV-L] Trapd takes too much memory
2007-10-18 16:31:54
SIGSEGV is a segmentation violation,
signal 11. It usually means that there is an internal fault in the
program which is trying to write to memory it does not own. Usually
the only thing you can do is open a problem to IBM NetView Support and
provide them with the FFDC data that was collected when this occurred,
You will probably also be asked to run a utility called readcoreg
which will produce an analysis of the core file you received in the hope
that someone in Support can pin down the nature of the problem. You
might also be asked to run a debug module so that the next core will contain
more information.
nvcorrd is the daemon who runs rulesets.
So there is probably some issue when it processes events for some
particular ruleset. The only thing you could do to avoid the core
would be to stop running that ruleset. How you could identify which
one on your own is probably only through trial and error. Otherwise,
someone will have to fix the code.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
ss cc <steph_cornish AT yahoo DOT com>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com
10/17/2007 12:33 PM
Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com> |
|
To
| Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
|
cc
|
|
Subject
| Re: [NV-L] Trapd takes too much memory |
|
James,
Have you seen processes die on a signal 11 (SIGSEGV)?
We've seen this quite a few times with nvcorrd. How can I tell
if it's dying because virtual memory is exhausted?
Stephanie
James Shanks <jshanks AT us.ibm DOT com> wrote:
Well, you are downlevel on maintenance, so you could apply
7.1.4 FP05 and see whether that helps, because you will have to be at that
level to pursue this problem with NetView Level 2, which is your next step.
While I have heard of many daemons being terminated because the virtual
memory is exhausted, and they all terminate on a signal 33 (SIGDANGER),
I've never heard of just nvserverd (or any other daemon) dying because
trapd or any other one is using too much memory. I don't know how you arrived
at that conclusion, but it is moot I suppose. If trapd has a memory leak,
you will need to open a problem with NetView Support and provide them with
your evidence. Trapd will have to be run with the hex dump all packets
option (-x) and you'll have to get a trapd.trace so that they can see what
kind of traffic it is handling. Support will have to recreate the leak
in the lab using a memory management tool to find where it is, and they
will need to see your trap traffic to do it.
If nvserverd is dying, then there should be FFDC data available for that
and you will need to provide that to Level 2 as well.
But trapd and nmdemandpoll are totally unrelated. nmdemandpoll is a netmon
operation and results in a trap being sent to trapd, but it does not depend
on trapd to complete. So perhaps there is more going on in your system
than you know. You will probably have to get a netmon trace to find out
why it is not responding to your demand poll request.
I don't see any way that you can resolve these issues on your own and you
should open a problem to NetView Support.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
"Liu, David" <david.liu AT eds DOT com>
"Liu, David" <david.liu AT eds DOT com>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com
10/17/2007 06:18 AM
Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com> |
|
|
Dear list,
Searched from the history but no success. I have a problem with trapd takes
too much memory. Every day or two, nvserverd is ending because of this.
When I issue command "prstat" I can see that trapd is "accumulating"
taken memory. And the demandpoll is taking too long time or die. (I don't
know if it is the consequence). Need your advice.
NV 7.1.4, FP3, Solaris.
Thanks & regards,
David Liu_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l
(Browser access limited to internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com _______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|
|
|