6236 and some previous versions of fred where, on heavily loaded nodes, seeing thread consumption spikes. This seems to be due to the fact that fred now uses the Ticker to notify itself of when for instance a messge has been asynchronously sent to another node.. Now, since messages nowadays are packetized (on my node I have quite frequently seen 200-500 message packets beeing sent) a whole lot of messages can be reported as sent at, more or less, the same time. This caused the Ticker to try to execute 1k+ events at once.. causing 1k+ threads to be allocated, and when the events where done, released again. Another effect of this problem was that we where seeing heavy lock congestion in the StandardMessageHandler.. further amplifying the problem.
So, last night toad added code that enables fred to treat some TickerEvents as "fast events".. "Fast events" are executed on the thread that tries to schedule them instead of on a Thread from the Pool, effectively throttling unnecesary thread creation and removing some unnecessary scheduling overhead. An obvious side effect of this mechanism is that this the thread that wants to schedule an event might instead end up executing it, beeing blocked during the time the execution consumes. Hence the name "fast events"... we should avoid executing anything that isn't "fast" on the scheduling thread. Unfortunately, today, it has proved that bucketloads of "fast events" still consumes significant amounts of execution time and since, in the current architecture, the threads ending up executing the bucketloads of "fast events" are the *SL threads.. the network communication threads.. thereby blocking network communication more than desired. I am about the commit a change that enables the Ticker to take a middle route between the old behaviour and the new one. I am adding a thread, internal to the Ticker, that is dedicated to handle all of these "fast events", thereby relieving the scheduling thread of the execution but still not causing the ThreadPool to spawn large amounts of threads to execute these "fast events". This thread will have a maximum allowed backlog, when the backlog is full the Ticker will revert to letting the scheduling thread execute the event (the current queue size and the actual events can be seen in a separate table in the 'Pending Tasks' infolet). This graph indicates the effect of this change on network bw usage (before change is to the left, after is to the right): http://194.236.28.174/freenetstuff/6237_and%206237modified_bwusage.jpg /N _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
