nv-l

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

2007-10-17 09:00:47
Subject: RE: [NV-L] Trapd takes too much memory
From: "Liu, David" <david.liu AT eds DOT com>
To: "Tivoli NetView Discussions" <nv-l AT lists.ca.ibm DOT com>
Date: Wed, 17 Oct 2007 14:59:39 +0200
James,
 
Thanks for your quick advice. I have the direction now to go ahead.
 
Regards,
David


________________________________

        From: nv-l-bounces AT lists.ca.ibm DOT com
[mailto:nv-l-bounces AT lists.ca.ibm DOT com] On Behalf Of James Shanks
        Sent: Wednesday, October 17, 2007 2:50 PM
        To: Tivoli NetView Discussions
        Subject: Re: [NV-L] Trapd takes too much memory
        
        

        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>

 

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)
        
        

GIF image

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)