----- Original Message ----- From: "Paul Derbyshire" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 16, 2004 8:30 AM Subject: [freenet-support] Odd failure(?) mode, and updating.
> You may remember me as the one who had problems with fproxy that > proved to be brain-dead IE defaults. Turns out fproxy and my node are > working fine, and the node gets around 1 request a second suggesting > it's integrating way better than the freesite of evil keeps bitching > about. :) > > Reachability of stuff browsed through the interface seems to improve > as it gels into the network. Good to hear, that is one of the reasons the why it is good to run a permanent node. > Then this AM there was an incident, which happened to catch me in > front of the keyboard. It was hard not to notice, since the whole > system became largely unresponsive. For whatever reason, my node had > spawned over 5000 new threads in a matter of seconds and bloated to > take up much more RAM and most of the CPU, forcing me to restart the > service from the tray menu. Hopefully enough is cached between > sessions that this won't seriously compromise the node's integration. > > I have a number of new questions, none of which the FAQ will answer. > 1. What caused this? I've heard of some versions grabbing a lot of > system resources when inserting certain kinds of keys locally through > FCP, but not spontaneously or as a result of requests. Can it happen > when some kinds of keys are inserted by just propagating to your > node? Was it trying to upload and store a large file, maybe one that > came in 5000 asynchronous fragments? Pathological behavior that > cripples the host system until the node is restarted manually, > possibly then hurting the network by interrupting what would have > been an important task for others or by setting back the "integration > clock" on your node is, IMO, bad. Thread, CPU, and memory use may > need to be throttleable as bandwidth currently is. (The same applies > double to the gnutella client I run, though, which frequently bloats > up to 2000 threads and uses way more ram than the freenet node under > normal circumstances -- i.e. normal for the node AND the gnutella > client. :)) The theory is that this happens when the node finishes a huge bunch of stuff at the same time (for instance when we have queued lost of messages to another node and then that dies.. suddenly we have large amounts of failure messages to handle). And.. even worse, when the node has huge amounts of threads running it will have problems catching up since we all the time receives more messages etc over the network that are supposed to be processed -> even more threads spawned > 2. Is this already addressed by the update? It is in the version you are running even.. set the config param 'threadFactory=Y' in the freenet.ini file (dont forget to remove the '%' comment sign). This will cause your node to use another threadfactory which respects the tfAbsoluteMaxThreads param (which defaults to 500 or so) > 4. My machine seems to get a new IP address every so often, > automagically, and not just after a reboot. How well will the node > handle that?: It checks periodically. > a. Will it start screwing up if the IP changes mid-session and have > to be manually restarted? How to detect this or better yet, automate > it? Short of restarting it on a fixed schedule, which would probably > be bad. Or will it discover the new ip for itself? Perhaps as long as > it works OK without uncommenting and changing the ipAddress line in > freenet.ini it will cope automatically? Yes > b. How bad an effect on the network will the dynamic IP have, > especially if it requires periodic node restarts beyond the usual > "Windows had a cerebral embolism in its atrophied and still largely > 16-bit brain; time to reboot again, sigh" situations? > I'd rather avoid the dyndns.org service that I was shocked to find > pimped in a comment in the configuration file. Shocked, because of > this from its Click-through Terms of Service Of The Week(tm by > Microsoft who pioneered the practise): Sure, a fixed IP would of course be better but fred is designed to cope with IP changes (read up on what ARK's (freenet only term) are if you want details) /N _______________________________________________ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support
