Yes, this would be a good idea. Whenever I do memory profiling those accumulators and 
connectionbuffers come out as the top consumers. This situation quite effectively 
prevents further memory optimizations right now.

A little note of warning though. In the past (a couple of months back) I saw an 
increased frequency of the 'Selector WindowsBug' when my WindowsXP node reached above 
900ish connections. The large amount of occurances of the bug-situation caused my node 
to stall.

But, even if this potential isssue exists, I'd say go for it.

/N

---------- Original Message ----------------------------------
From: Zlatin Balevsky <[EMAIL PROTECTED]>
Reply-To: Discussion of development issues <[EMAIL PROTECTED]>
Date:  Sat, 06 Sep 2003 21:54:26 -0400

>Seems like the high cpu usage is due mainly to heavy churn of new 
>connections being opened on popular nodes.  Eventually a feedback loop 
>occurs: new connections are being opened to reject queries due to bw 
>limits, and those negotiations in turn take up the bandwith causing more 
>QRs.
>
>My node receives around 60000 qph.  With the default limit of 512 
>connections between 200 and 300 new connections are opened every minute 
>(half of them through the ConnectionOpener).  I increased my limit to 
>1024 connections and for an hour and a half uptime only 800 were used up 
>(rtSize=64).  The ratio of new connections had dropped to ~70 per 
>minute, and cpu usage had therefore gone down significantly.
>
>So... it may be time to do the buffer pooling.  It will solve two 
>problems with one bullet - the high memory requirements and the high cpu 
>usage (as it will allow nodes to have higher number of connections).  
>The default of 512 should stay on *nix systems where root privileges are 
>required to have more than 1k descriptors.  On windoze systems there is 
>no limit on the number of sockets, so a more liberal limit can be set.
>
>_______________________________________________
>Devl mailing list
>[EMAIL PROTECTED]
>http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to