nv-l

Re: [NV-L] Trapd takes too much memory

2007-10-17 19:44:58
Subject: Re: [NV-L] Trapd takes too much memory
From: ss cc <steph_cornish AT yahoo DOT com>
To: Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
Date: Wed, 17 Oct 2007 09:33:54 -0700 (PDT)
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
' src="http://us.f527.mail.yahoo.com/ym/Upload?Data=upl1015189765"; width=16 
border=0>"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>





          
  To
  
"Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT com>    
  cc
  
    
  Subject
  
[NV-L] Trapd takes too much memory          
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 

GIF image

_______________________________________________
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)