Anyone here having any of the numerous problems reported in the FMS thread "1262: very bad performance"?
Lets try to focus on client layer problems. Some users are reporting that downloads stop some hours after startup, yet can be made to work again by changing the priority of a request there and back. One reason to doubt this is that cooldown issues are unlikely to be affected by restarting, whereas load management problems are unlikely to be affected by changing priorities... == Re: 1262: very bad performance on 2010-08-02 21:30:45 [Permalink] Reply tumbler at OxXBm2It3J3u0lPyChcWoQMTB2YZUGlJZVfQjiZpZN8 wrote: toad-notrust at h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote : Is there any hope of disentangling all these different problems? As far as I can see, there are many different issues many of which are completely unrelated to each other: - High proportion of backed off peers. - Poor performance. - Download lower than expected. - Needing more threads to get good performance. - Downloads stalling and then restarting after being bumped up and down in priority. - Download performance steadily dropping after startup and coming back after restart. - Worse payload output. Then factor in that the network level code has hardly changed at all and you can see why this is something of a nightmare from the point of view of trying to debug it! Is it a client layer problem? Is it a backoff problem? Is it something else? This idea that the node slows down after startup - can you get snapshots of the stats page at intervals, and see what has changed? The proportion of requests accepted? The number of requests running? The AIMD inter-request times? The average request completion times? The proportion of peers backed off? The ping time and throttle delay time? The number of threads? The reasons for preemptive rejection? If it's a client layer problem, the simplest possible client layer bug would be if it no longer sends requests after a given point - can we rule this out? Can you enable logging for RequestStarter (freenet.node.RequestStarter:MINOR,freenet.node.NodeStats:MINOR) and see if requests are still being started, at reasonable intervals, and if not why not? Etc etc. Just saying it don't work doesn't give me much to go on! == toad, you are listing every problem regarding the performance. IMHO it would be a good starting point to review - Downloads stalling and then restarting after being bumped up and down in priority. because this problem requires observation and manual intervention by the user. I increased my store capacity by 20% (utilization was at 100% before). Strange effects: - after resize was completed utilization is at ~50% now - 'sleep mode' is gone and there seems to be no performance degradation over time - the node was running several hours after restart when download rate in fuqid dropped to nearly 0,the node's statistiscs page showed same up/down rate as before. After more than an hour (I was already going to restart the node) downloads in fuqid started again, download rate soon was at same level as before this drop out. I'll have to analyze log files. However download performance is as bad as before. Maybe you can try the same, just to see whether you experience the same behaviour. @toad: - I have a lot of log files now, what should I look for? - In another message I wrote that build of 1st week in June still performed well. Is it possible to create a test version based on this build which contains current metadata changes only? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100802/f75167b8/attachment.pgp>
