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
>>situations.
>>
>>
>>
>>>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
>>>>action.
>>>>
>>>Ah, but what about the undo command. Or the retrospective exception
>>>handler. You know the one I mean - "It was left at that previous
>>>junction".
>>>
>>>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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
Peter
_____________________________________________________
Procrastination is the thief of time.
Edward Young (1683-1765) British poet. Night Thoughts
_____________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
