Or just use the

-XX:+DisableExplicitGC

parameter to make Sun JVM ignore garbage collection requests. Simply add

wrapper.java.additional.1=-XX:+DisableExplicitGC

to wrapper.conf, like I just did.


On Mon, 10 Jul 2006 22:54:07 +0100, Matthew Toseland wrote:

> I would support making it conditional on a flag; node.aggressiveGC=<-1 or
> period in seconds>.
> 
> On Sun, Jul 09, 2006 at 11:17:13AM +0200, Florent Daigni?re (NextGen$)
> wrote:
>> * Ian Clarke <ian at revver.com> [2006-07-09
>> 02:05:43]:
>> 
>> 
>> > On 9 Jul 2006, at 01:40, Florent Daigni?re (NextGen$) 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 ;)
>> > 
>> > Indeed, it could be the cause of all our CPU issues.  Can you explain
>> > the rationale for this?
>> > 
>> > I have heard Java engineers say that the System.gc() command is one of
>> > the most abused commands in the Java API - because 99.9% of the time
>> > programmers think they should use it, they are wrong.
>> > 
>> > Ian.
>> 
>> from :
>> 
>> http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/node/MemoryChecker.java?rev=8876&view=markup
>> 
>> // FIXME
>> // Do not remove until all known memory issues fixed, // Especially #66
>> // This probably reduces performance, but it makes // memory usage *more
>> predictable*. This will make // tracking down the sort of nasty
>> unpredictable OOMs // we are getting much easier.
>> 
>> Toad wrote that thread ... see
>> https://bugs.freenetproject.org/view.php?id=66
>> 
>> Maybe it was just the NPTL-related bug :/ Maybe we can disable it on
>> user's nodes and let it enabled on developers' ones ... the problem
>> beeing that incidents like that hardly ever occur on developer's nodes
>> :'( and that user's nodes aren't running at loglevel=MINOR.
>> 
>> NextGen$
> 
> 
> 
>> _______________________________________________ Devl mailing list
>> Devl at freenetproject.org
>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl



Reply via email to