On Monday 06 January 2003 13:40, you wrote: > > On Mon, Jan 06, 2003 at 10:51:42AM -0500, Gianni Johansson wrote: > > Mathew: > > I am still seeing load averages of 10 -20 and higher for about 6 hours > > then my node goes moribund and stops answering incoming FNP requests. > > Can I have a stack trace of this please? logLevel=debug logs would be > helpful too. Oskar suggests that it's probably an infinite or near-infinite > loop. Oh and BTW, the new anon filter code is MUCH heavier than the old > stuff - that will cause loadaverage to increase when loading lots of > HTML via fproxy. I'm having trouble reproducing the lock up. My node was down for a while so I'm not getting as much traffic. If it locks again I will send you a thread dump.
> > > The load seems to be unrelated to the amount of data my node is moving. > > > > Here are a few ideas: > > 0)One explanation I can come up with for the excessive load is that the > > new CP code is allowing the outbound link crypto to thrash. > > > > Routing is highly non-linear. The previous CP code explictly limited the > > number of times a reference could be retried per unit time so that nodes > > that were popular with the routing wouldn't be retried too often. i.e. If > > a reference has failed once in the last minute, retrying it 5 times in > > the next 20 seconds probably won't tell us much. Making those > > connections could burn a lot of mips, especially if the target node is > > hanging up after the link crypto. > > > > You can argue that the CP will be reduced enough eventually to stop the > > ref from being routed to, but eventually *doesn't matter*. You have > > already paid the price in unsuccessful connections to get there. That > > price could be very high for a popular node. > > > > 1) There is a hack in the OCM that keeps too many outbound connections > > from blocking trying to connect to the same host. It throws > > ConnectFailedExceptions. I commented it out as a quick test. Without it > > my load average increased without bound until I lost control of the > > machine and had to power down to regain control. But it's good to keep > > it in mind as a source of "fake" ConnectFailedExceptions. > > > > 2) Persisting the updated routing table information might be burning > > mips.. I don't think that the DataObjectRoutingMemory was ever designed > > to handle a really fast update rate. Maybe this is fixed. I know Oskar > > did some work a while back to move the routing info into separate files. > > > > > > > > --gj > > > > p.s.: > > Do you intend to fix this? > > http://hawk.freenetproject.org/pipermail/devl/2002-December/003217.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > devl mailing list > > devl at freenetproject.org > > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl ---------------------------------------- Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
