here too. after loading the filesystem (or around that time) fred sucked up all the 384MB i spent the VM before doing anything useful, giving me a OOM. wow.... i mean.. WOW! i restarted the node and this time there were no OOM problems for a couple of hours, then again the nice familiar message
latest unstable snapshot from yesterday or the day before yesterday oh, btw, could someone please explain the nice gfx at the routing table page? should all those dots be above the line? below? clumped together? equally spread? spiked? i'm mising the successful/total trials value, as i see it, the successful/total connections only show connection attemps but no measure for "data found"/"tries to find data" >I agree. I am seeing those OOM problems at my node too. They started to >occur at some point around 6182-6184 or so I think. > >/N > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of J >> Sent: den 11 september 2003 07:16 >> To: Discussion of development issues >> Subject: Re: [freenet-dev] Next steps >> >> >> Quoting Toad <[EMAIL PROTECTED]>: >> >> > The major issues with current unstable build relate to CPU >> usage and >> > opening too many connections. The latter most likely causes the >> > former, although there is probably some feedback in the other >> > direction too. Having spent considerable time trying to track this >> > down, I think a change of approach is warranted. I propose to: >> > 1. Merge unstable to stable. Most reports say it is at >> least as good as >> > stable now, and in many regards much better. >> >> Hmmmm, I don't know if merging stable and unstable at this >> point is such a great idea. I'm still having lots of >> problems with unstable right now. 24 hours of uptime and I >> have to restart Fred because it is no longer responding. I'm >> also getting lots of 'out of memory' errors, at least with >> 6187. I just went to 6190 so we'll see how that goes. >> >> I say we wait till unstable is at least *somewhat* stable >> before merging. It may somewhat slow development, but I am a >> big proponent of making sure something is right before wide >> distribution and I think it is critical that the code base is >> decently stable before building upon it. >> >> j. >> >> >> > 2. Finish implementing the PeerHandler/ConnectionHandler rewrite. >> > 3. Implement multiplexing. >> > 4. One month after multiplexing hits stable it will become mandatory >> > because the potential harm from many nodes not supporting >> multiplexing >> > is significant. >> > -- >> > Matthew J Toseland - [EMAIL PROTECTED] >> > Freenet Project Official Codemonkey - http://freenetproject.org/ >> > ICTHUS - Nothing is impossible. Our Boss says so. >> > >> >> >> _______________________________________________ >> 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 _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
