On Tue, 11 Jul 2006 23:27:46 +0200, Florent Daigni?re wrote: > * Jusa Saari <jargonautti at hotmail.com> > [2006-07-11 21:58:26]: > >> On Sun, 09 Jul 2006 10:40:17 +0200, Florent Daigni?re wrote: >> >> > * Colin Davis <Colin at sq7.org> [2006-07-08 >> > 23:41:24]: >> > >> >> Fair- The profilers I found all seemed to be GUI based- I run my node >> >> on a server without X, that I can only access via SSH. I know Java >> >> 1.5 has a way do generate a profile text file, though.. >> >> I'll look into it, I suppose. >> > >> > No need to : I can explain the current strategy: >> > >> > We *force* the GC every 18.25 sec in our MemoryChecker thread. So, >> > yes, it probaly creates CPU spikes ;) >> > >> > And yes, we have a good reason for doing so: we want to find OOM >> > errors as soon as possible when we introduce them... So until we >> > release, it will remain like that, unless you prove us it affects the >> > load-balancing algorithm. >> >> You lost me here. >> >> To the best of my knowledge, if there isn't enough free memory to >> allocate an object when one is created, the node triggers a minor >> garbage collection; if there still isn't enough free memory after that, >> it triggers a full collection. If there still isn't enough memory, it >> throws an OOM error. >> >> So, if you get an OOM error, the node has just done a full garbage >> collection anyway, and it doesn't matter if it did one a few seconds >> earlier as well, since whatever garbage that earlier collection got rid >> of would still be garbage and would be got rid of at this later time. >> Therefore, forcing full collection periodically does nothing but waste >> CPU time; it cannot affect whether an object allocation succeeds or >> fails. >> >> The only exception are objects with finalizers, since the first >> collection that detects them as garbage simply runs the finalizer, and >> only the second gets rid of them. But I hope that Freenet doesn't do >> heavy use of such objects anyway, since they negatively affect >> performance for the reasons I mentioned. >> >> What did I miss ? > > That the base object in freenet is the "Bucket" and that we do use > finalizers around it :)
Why ? If the bucket only stores data (memory structures), normal garbage collection deals with it without finalizers. Anyway, my node seems to have all connections marked as "busy". Either those finalizers do something important (which is a no-no, since the running of finalizers in a timely manner or at all can't be guaranteed), or I've been hit with a bad build. I just updated, now let's see... Well, they seem to be fluctuating between busy and non-busy normall now. And I can get content. Guess I'll be keeping explicit GC off for now. > NextGen$ > > >> Oh well, I set the JVM option to disable explicit GC, so I won't be >> affected by this anyway anymore. >> >> > NextGen$ >> > >> > >> >> On Jul 8, 2006, at 11:08 PM, Ian Clarke wrote: >> >> >> >> >On 8 Jul 2006, at 19:26, Colin Davis wrote: >> >> >>It seems that there amy be optimizations that can be made to the >> >> >>JVM, in telling it how and when to do the GC for Freenet. I'm not >> >> >>familiar enough with freenet to know which would be the best >> >> >>stragegy, but I'm looking for options. >> >> >>http://java.sun.com/docs/hotspot/gc1.4.2/faq.html >> >> >> >> >> >>Any other suggestions on lowering my CPU usage are welcome. It >> >> >>seems like the load is usually low, but spikes high- It might be >> >> >>FEC, or it might be GC in the JVM. >> >> > >> >> >Manually invoking the GC can be counter-productive unless you really >> >> >know what you are doing. >> >> > >> >> >The best way to address CPU issues is to run a profiler to see what >> >> >is causing the problem. >> >> > >> >> >Ian. >> >> >_______________________________________________ Devl mailing list >> >> >Devl at freenetproject.org >> >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> >> >> >> _______________________________________________ Devl mailing list >> >> Devl at freenetproject.org >> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> >> _______________________________________________ Devl mailing list >> > Devl at freenetproject.org >> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> >> >> _______________________________________________ Devl mailing list >> Devl at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >>
