Hi Gerhard, Thanks for the reply. I've done more work on this and posted two messages on the cocoon-dev list, but your moderator hasn't let them through yet! Quick summary is:
In the loop that frees an item from a store then calls the garbage collector. Typically the item clears 5k (not m) of memory then the garbage collector is called which takes 2.5 seconds. So, at this rate, to clear 20m would take a few hours during which time the system appears to be locked! I've noticed when running Optimizeit that although garbage collection can be quick, it sometimes takes a few seconds. If it has just been run, and you force it to run again, then it seems to take longer. If it can't find much to freeup, it seems to do a more time consuming search for garbage. Can the stores tell you how much they've freed (even approximately) so you don't need to call the garbage collector then ask the jvm about freememory so often? Full details and evidence posted under dev list. Peter [EMAIL PROTECTED] wrote: > Hi Peter, > > >>From: Peter Hargreaves [mailto:[EMAIL PROTECTED]] >> >>Hi Gerhard, >> >>In my earlier notes on the above topic, I mentioned my garbage collector >>occasionally taking over the system thereby freezing it! I think it >> > > Damn threads! > > >>could be a bug connected with the Round Robin not managing to free >>memory and not giving up trying to when it can't. >> >>With the following settings: >>Xms=0m >>Xmx=140m >>heapsize =100000000 >>freememory=20000000 >> >>I find using Optimizit that when my actual heap get to just over 100m >>and my heap in use gets over 80m, then usually memory gets freed as >>expected. Sometimes at this point the lockup occurs. It usually happens >>just after one or two attempts have only just managed to free more than >>20m. If the store-janitor can't free memory (store empty) I would expect >>it to let the memory in use continue to grow. >> > > For that he checks if more then one store is registered. > > >>Looking in my components.log and matching the output with the >>StoreJanitorImpl.java source. The following seems to be happening: >> >>Inside the method run() it seems to be getting stuck in the while loop >>that repeatedly attempts to freeMemory() until the store is empty. It >>doesn't seem to be able to empty the store! >> >> while (this.memoryLow() && this.getStoreList().size() > 0) { >> this.freeMemory(); >> } >> >>In my log I find alternating groups of statements from this.memoryLow() >>and this.freeMemory() and the message "StoreList size=3" gets repeated. >>Every attempt to free memory calls the garbage collector. >> >>I couldn't understand the Round Robin thing so don't know if that is to >>blame. There is other activity in the log which might be relevant, see >>below. >> > > Hmm I don't find the bug, yet. But I changed the logging messages at least. > Now it prints out "memory is low true/false". Maybe that's more clearly-presented. > > Could you do a new check-out of the Head version and redo your test? I assume you just mean to try the latest CVS? I was trying to stick with C2.0 because I've done so much testing with it for release of my completed application. I'll see if I can organise myself to do this. > > <skip/> > > Gerhard > > -------------------------------- > Children are hereditary; > if your parents didn't have any, > neither will you. > -------------------------------- > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
