Re: [gui-dev] Chasing possible memory leaks?

LimeWire is going to need NIO before increasing the number of connections... NIO 
rocks!

Susheel M. Daswani wrote:
> 
> Yes, message traffic has really gone up as the network has grown 
> (running a UP increasingly takes more bandwidth).  I really think it may 
> be time for a increase in outdegree and decrease in TTL, but only maybe 
> after that meeting with Sun results in less memory usage :).
> 
> Thanks!
> Susheel
> 
> Sam Berlin wrote:
> 
>> Nothing has changed related to flow control & QRP in well over a few 
>> months,
>> so the likely conclusion is that it really is a pickup in message traffic
>> combined with the older addition of high outdegree (which would have no
>> caused memory problems while there was little traffic).
>>
>> Getting even fancier with weak links might solve this. ;)
>>
>> Thanks,
>>  Sam
>>
>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:gui-dev-
>>> [email protected]] On Behalf Of Greg Bildson
>>> Sent: Thursday, August 19, 2004 10:42 AM
>>> To: [email protected]
>>> Subject: RE: [gui-dev] Chasing possible memory leaks?
>>>
>>> It's been a long while since flow control kicked in.  Those
>>> PriorityMessageQueues could be somewhat troublesome with the recent 
>>> pickup
>>> in message traffic.  However, it almost sounds like your connections 
>>> (and
>>> QRP tables) keep building up.  Perhaps some closes got lost or are we
>>> trying
>>> to do something too fancy with weak links now?
>>>
>>> Thanks
>>> -greg
>>>
>>> -----Original Message-----
>>> From: [email protected]
>>> [mailto:[email protected]]On Behalf Of Jens-Uwe Mager
>>> Sent: Thursday, August 19, 2004 7:00 AM
>>> To: [email protected]
>>> Subject: [gui-dev] Chasing possible memory leaks?
>>>
>>>
>>> While running as an ultrapeer my machines appear to go out of memory
>>> somehow. I did a few runs with -Xrunhprof:heap=sites and I have a few
>>> questions if that memory usage is about to be expected. The top entries
>>> in the list of hot sites are these:
>>>
>>> SITES BEGIN (ordered by live bytes) Wed Aug 18 13:22:34 2004
>>>          percent         live       alloc'ed  stack class
>>> rank   self  accum    bytes objs   bytes objs trace name
>>>    1 11.41% 11.41% 11428008 1214 22449936 11149 60808 [J
>>>    2  5.67% 17.08%  5676336 114744 6247840 125345 60656 [C
>>>    3  2.54% 19.63%  2545920 6120 2589184 6224 56176 java.lang.Object
>>>    4  2.54% 22.17%  2545920 6120 2589184 6224 56299 java.lang.Object
>>>    5  2.54% 24.71%  2545920 6120 2589184 6224 56171 java.lang.Object
>>>    6  2.54% 27.26%  2545920 6120 2589184 6224 56181 java.lang.Object
>>>    7  2.43% 29.69%  2435648 29614 2576640 31128 51089 [C
>>>    8  2.37% 32.06%  2374104 98921 2602368 108432 60620 java.lang.String
>>>    9  1.93% 33.99%  1930240 4640 1970176 4736 59661 java.lang.Object
>>>   10  1.93% 35.92%  1930240 4640 1970176 4736 59636 java.lang.Object
>>>   11  1.93% 37.85%  1930240 4640 1970176 4736 59646 java.lang.Object
>>>   12  1.93% 39.77%  1930240 4640 1970176 4736 59641 java.lang.Object
>>>
>>> The first entry appears to relate to this stack trace:
>>>
>>> TRACE 60808:
>>>        
>>> com.limegroup.gnutella.util.BitSet.ensureCapacity(BitSet.java:140)
>>>        com.limegroup.gnutella.util.BitSet.set(BitSet.java:265)
>>>
>>> com.limegroup.gnutella.routing.QueryRouteTable.handlePatch(QueryRouteTab
>>> le.java:462)
>>>
>>> com.limegroup.gnutella.routing.QueryRouteTable.patch(QueryRouteTable.jav
>>> a:405)
>>>
>>> com.limegroup.gnutella.ManagedConnection.patchQueryRouteTable(ManagedCon
>>> nection.java:395)
>>>
>>> com.limegroup.gnutella.MessageRouter.handlePatchTableMessage(MessageRout
>>> er.java:2345)
>>>
>>> com.limegroup.gnutella.MessageRouter.handleMessage(MessageRouter.java:34
>>> 8)
>>>
>>> com.limegroup.gnutella.ManagedConnection.loopForMessages(ManagedConnecti
>>> on.java:995)
>>>
>>> com.limegroup.gnutella.ConnectionManager.startConnection(ConnectionManag
>>> er.java:1943)
>>>
>>> Does that mean that my machine needs 22MB of routing tables?
>>>
>>> Ranks 2 to 6 appear all to be related, they all appear to revolve around
>>> this stack trace:
>>>
>>> TRACE 56176:
>>>        com.limegroup.gnutella.util.Buffer.<init>(Buffer.java:47)
>>>
>>> com.limegroup.gnutella.util.BucketQueue.<init>(BucketQueue.java:46)
>>>
>>> com.limegroup.gnutella.connection.PriorityMessageQueue.<init>(PriorityMe
>>> ssageQueue.java:50)
>>>
>>> com.limegroup.gnutella.ManagedConnection.buildAndStartQueues(ManagedConn
>>> ection.java:651)
>>>
>>> com.limegroup.gnutella.ConnectionManager.connectionInitialized(Connectio
>>> nManager.java:1216)
>>>
>>> com.limegroup.gnutella.ConnectionManager.completeConnectionInitializatio
>>> n(ConnectionManager.java:1834)
>>>
>>> com.limegroup.gnutella.ConnectionManager.initializeExternallyGeneratedCo
>>> nnection(ConnectionManager.java:1814)
>>>
>>> com.limegroup.gnutella.ConnectionManager.acceptConnection(ConnectionMana
>>> ger.java:333)
>>>
>>> com.limegroup.gnutella.Acceptor$ConnectionDispatchRunner.run(Acceptor.ja
>>> va:592)
>>>
>>> And the large number of strings in rank 8 appear to be from this trace:
>>>
>>> TRACE 60620:
>>>
>>> com.limegroup.gnutella.messages.QueryRequest.<init>(QueryRequest.java:12
>>> 49)
>>>
>>> com.limegroup.gnutella.messages.QueryRequest.createNetworkQuery(QueryReq
>>> uest.java:854)
>>>        com.limegroup.gnutella.messages.Message.read(Message.java:303)
>>>
>>> com.limegroup.gnutella.Connection.readAndUpdateStatistics(Connection.jav
>>> a:1084)
>>>        com.limegroup.gnutella.Connection.receive(Connection.java:1029)
>>>
>>> com.limegroup.gnutella.ManagedConnection.receive(ManagedConnection.java:
>>> 481)
>>>
>>> com.limegroup.gnutella.ManagedConnection.loopForMessages(ManagedConnecti
>>> on.java:970)
>>>
>>> com.limegroup.gnutella.ConnectionManager.startConnection(ConnectionManag
>>> er.java:1943)
>>>
>>> com.limegroup.gnutella.ConnectionManager.access$400(ConnectionManager.ja
>>> va:56)
>>>
>>> I am not entirely sure if I am not barking up the wrong tree, but I get
>>> the feeling that there are a few memory leaks that appear to be
>>> triggered if I am turning ultrapeer on. If there is interest, the full
>>> trace file is here:
>>>
>>> http://baghira.han.de/~jum/limewire.sites.gz
>>> -- 
>>> Jens-Uwe Mager    <pgp-mailto:F476EBC2>
>>> _______________________________________________
>>> gui-dev mailing list
>>> [email protected]
>>> http://www.limewire.org/mailman/listinfo/gui-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> gui-dev mailing list
>>> [email protected]
>>> http://www.limewire.org/mailman/listinfo/gui-dev
>>
>>
>>
>> _______________________________________________
>> gui-dev mailing list
>> [email protected]
>> http://www.limewire.org/mailman/listinfo/gui-dev
>>
>> .
>>
> _______________________________________________
> gui-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/gui-dev
> 
> 
_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev