cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hargreaves <>
Subject Re: StoreJanitor new calculation [was: Re: Store Janitor Hangs System]
Date Wed, 06 Feb 2002 18:39:25 GMT

Gerhard Froehlich wrote:

> Hi,
>>>>>*) If the percent to reduce storage is set to 10%, it fails to
>>>>>remove any when the number of items are below 10. The number of items
> to be
>>>>>removed needs rounding upwards. Why not remove a fixed number of items
>>>>>instead of a percentage? (My idea and now I think it was wrong!!)
>>>>+1 on rounding up,
>>>>-1 on removing percentage. Applications highly differ on number of
>>>>objects and average size of the object. Percentage gives the advantage
>>>>to have generic configuration. If this is not over-configuration,
> number
>>>>of objects to remove may be configured with or without percent sign:
>>>>  <parameter name="reduceby" value="10%"/>
>>>>  <parameter name="reduceby" value="100"/>
>>>My thinking is this. Ideally you want to remove a defined number of
>>>bytes from the stores. If you can guess the average size of an item then
>>>by removing a defined number of items you are removing an approximate
>>>number of bytes.
>>That's when you tune for one particular application - then yes. If you
>>try to put something that works well when you have 200 huge objects, and
>>when you have 20000 tiny one - I think defined number won't work. What
>>can you suggest here? I hoped that percentage may work for these
>>>When I tried removing a percentage, I found that successive attempts
>>>freed up less and less storage
>>This makes sence, I did not thought of it this way...
>>then my system ran out of memory before the store was empty.
>>...but on the other hand: it means that you have leaks in some other
>>place! May be you will want to find them first before blaming memory
>>store ;)

It's not leaks. With increased memory I've run Jmeter overnight and memory does 
NOT slowly grow (leak).

>>It may be not leaks, but uncontrolled memory consumption by some
>>business logic of your site. Then why not just increase free-memory
>>parameter to factor in these requirements?

Yes, I have some intensive xslt which generates management reports from user 
directories (controlled but intensive). It demands a lots of memory. I can avoid 
using this, but it comes in very useful for stress testing.

My C2 application is tried and tested ready to be hosted but it needs too much 
memory - I can't find a service provider that will have me! Most of them say 
that 64M is more than enough for most people and there must be something wrong 
with Cocoon if it needs more! That why I've become very interested in efficient 
use of memory.

> That's correct. I noticed that calling the gc before freeing is very
> useful.
> Because I determined that this frees mainly enough memory and therefor
> objects don't have to freed out of the store. Be careful. There are
> other garbage in the JVM, not only the stores ;).

Calling the gc from the sj's checker is deceptive. It looks good, but it doesn't 
help because the jvm calls the gc very intensively before it lets the 
java.memory run out, in any case.

It does do harm however, because it takes several seconds to run. If it is 
called every 10 seconds then Cocoon runs about 20% slower than it should!! 
Because its not helpful or necessary, the solution I'v proposed and tested runs 
Cocoon noticably faster. Try it!

Removing some storage then running the gc to see progress, is a very slow way to 
free storage. Going round this loop enough times to empty the stores (if 
necessary) can take a long time. So, if a sudden high demand occurs then it is 
important to start to free stores as soon as possible. If instead the gc is 
called and it frees enough memory to put off the freeing of storage 
(procrastination), then there may not be enough time left before memory runs out.

> I wouldn't concentrate that much on the stores. NOTE: often there are only
> 100 objects in the cache. But if you ever seen a Cocoon StackTrace then you
> know how much objects we instantiate ;).

I have come to realise that the stores can represent very little memory, but 
it's not clear to me whether this will remain the case. So, my immediate 
concerns are that the sj's checker should not inadvertently undermine 
performance or memory consumption.

>>>The trouble with convincing people is that you have to unconvince them
>>>if you change you mind ;-)
> I know, I know...
>>>>>Ideally - low memory should be detected by some sort of interrupt or
>>>>>exception rather than by polling.
>>>>AFAIK, when you get an exception it's already late to take any
>>>Ah, but what about the undo command. Or the retrospective exception
>>>handler. You know the one I mean - "It was left at that previous
>>>Seriously though. Are there any plans for java to include a mechanism
>>>that tells folks when memory is getting low. Surely lots of people
>>>have this problem.
>>Don't know. Search bug database - may be there is already couple of
>>requests in there.
> Keep talking
>   ~Gerhard
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Procrastination is the thief of time.
Edward Young (1683-1765) British poet. Night Thoughts

To unsubscribe, e-mail:
For additional commands, email:

View raw message