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

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