objects not reclaimed
Locked
 
|
Hi,
I have a stripped down version of the gemstone maintenance script. It does only the MFC. I start the script from cron. I recognized that the mfc occurs but the objects are not being deleted. It looks like this start MFC process dead phase: 07/07/10 16:17:04 CEST end MFC: 07/07/10 16:17:04 CEST AbortingError 3020: Successful completion of markForCollection. <3385737> live objects found. <3406561> possible dead objects, occupying approximately <306590490> bytes, may be reclaimed. 2010-07-07T07:17:05-07:00 ...finished markForCollect. start MFC process dead phase: 07/07/10 17:17:05 CEST end MFC: 07/07/10 17:17:05 CEST AbortingError 3020: Successful completion of markForCollection. <3385564> live objects found. <3421844> possible dead objects, occupying approximately <307965960> bytes, may be reclaimed. 2010-07-07T08:17:05-07:00 ...finished markForCollect. start MFC process dead phase: 07/07/10 18:17:04 CEST end MFC: 07/07/10 18:17:04 CEST AbortingError 3020: Successful completion of markForCollection. <3384285> live objects found. <3436342> possible dead objects, occupying approximately <309270780> bytes, may be reclaimed. 2010-07-07T09:17:04-07:00 ...finished markForCollect. My site is not visited very frequently so there is no chance all of these objects were created within one hour. Just if you asked yourself :) What is the best thing to check? thanks, Norbert |
|
|
Norbert,
I'm assuming that the gcgems are running and healthy (there should be no error messages and fairly recent activity in the following log files: *reclaimgcgem*.log *admingcgem.log ... if in doubt send me a copy of the log files including *stone.log in case there are errors there). The mark sweep scans the repository for "possible dead" objects. Then each active gem is asked to vote on the "possible dead" ... if a gem has a reference to one or more of the dead object, then those objects (and all objects referenced by those objects) are removed from the "possible dead". So it is possible that one or more of the gems are hanging onto dead objects (very possibly from SessionTemps). To see if that is the case, you can stop/restart your active gems and then run the MFC again ... the results of the "possible dead" sweep should be visible in the *admingcgem.log... This should address the problem. Dale Norbert Hartl wrote: > Hi, > > I have a stripped down version of the gemstone maintenance script. It does only the MFC. I start the script from cron. I recognized that the mfc occurs but the objects are not being deleted. It looks like this > > start MFC process dead phase: 07/07/10 16:17:04 CEST > end MFC: 07/07/10 16:17:04 CEST > AbortingError 3020: Successful completion of markForCollection. > <3385737> live objects found. > <3406561> possible dead objects, occupying approximately <306590490> bytes, may be reclaimed. > 2010-07-07T07:17:05-07:00 > ...finished markForCollect. > > > start MFC process dead phase: 07/07/10 17:17:05 CEST > end MFC: 07/07/10 17:17:05 CEST > AbortingError 3020: Successful completion of markForCollection. > <3385564> live objects found. > <3421844> possible dead objects, occupying approximately <307965960> bytes, may be reclaimed. > 2010-07-07T08:17:05-07:00 > ...finished markForCollect. > > start MFC process dead phase: 07/07/10 18:17:04 CEST > end MFC: 07/07/10 18:17:04 CEST > AbortingError 3020: Successful completion of markForCollection. > <3384285> live objects found. > <3436342> possible dead objects, occupying approximately <309270780> bytes, may be reclaimed. > 2010-07-07T09:17:04-07:00 > ...finished markForCollect. > > My site is not visited very frequently so there is no chance all of these objects were created within one hour. Just if you asked yourself :) What is the best thing to check? > > thanks, > > Norbert > > |
|
|
thanks Dale,
it wasn't actually the seaside gems. It was the maintenance gems. As you might remember I have three different users with pier kernels installed. I splitted the maintenance script provided with gemstone into a seaside session cleaner and a gemstone MFC. The seaside session cleaner still used the endless loop to run. And somehow this gems kept the objects back. As soon as I killed the gems the objects have been freed again. I'll inspect this a little further to be sure. But I also have gotten rid of the endless loop in the script. Now I have three scripts (one for each user) and a mfc running in sequence every hour having each end after a single pass. If you are interested I can provide you the altered script. So you might see what is going wrong. Norbert On 08.07.2010, at 18:35, Dale Henrichs wrote: > Norbert, > > I'm assuming that the gcgems are running and healthy (there should be no error messages and fairly recent activity in the following log files: *reclaimgcgem*.log *admingcgem.log ... if in doubt send me a copy of the log files including *stone.log in case there are errors there). > > The mark sweep scans the repository for "possible dead" objects. Then each active gem is asked to vote on the "possible dead" ... if a gem has a reference to one or more of the dead object, then those objects (and all objects referenced by those objects) are removed from the "possible dead". So it is possible that one or more of the gems are hanging onto dead objects (very possibly from SessionTemps). > > To see if that is the case, you can stop/restart your active gems and then run the MFC again ... the results of the "possible dead" sweep should be visible in the *admingcgem.log... This should address the problem. > > Dale > > Norbert Hartl wrote: >> Hi, >> I have a stripped down version of the gemstone maintenance script. It does only the MFC. I start the script from cron. I recognized that the mfc occurs but the objects are not being deleted. It looks like this >> start MFC process dead phase: 07/07/10 16:17:04 CEST >> end MFC: 07/07/10 16:17:04 CEST >> AbortingError 3020: Successful completion of markForCollection. >> <3385737> live objects found. >> <3406561> possible dead objects, occupying approximately <306590490> bytes, may be reclaimed. 2010-07-07T07:17:05-07:00 >> ...finished markForCollect. >> start MFC process dead phase: 07/07/10 17:17:05 CEST >> end MFC: 07/07/10 17:17:05 CEST >> AbortingError 3020: Successful completion of markForCollection. >> <3385564> live objects found. >> <3421844> possible dead objects, occupying approximately <307965960> bytes, may be reclaimed. 2010-07-07T08:17:05-07:00 >> ...finished markForCollect. >> start MFC process dead phase: 07/07/10 18:17:04 CEST >> end MFC: 07/07/10 18:17:04 CEST >> AbortingError 3020: Successful completion of markForCollection. >> <3384285> live objects found. >> <3436342> possible dead objects, occupying approximately <309270780> bytes, may be reclaimed. 2010-07-07T09:17:04-07:00 >> ...finished markForCollect. >> My site is not visited very frequently so there is no chance all of these objects were created within one hour. Just if you asked yourself :) What is the best thing to check? >> thanks, >> Norbert > |
|
|
Norbert Hartl wrote:
> thanks Dale, > > it wasn't actually the seaside gems. It was the maintenance gems. As you might remember I have three different users with pier kernels installed. I splitted the maintenance script provided with gemstone into a seaside session cleaner and a gemstone MFC. The seaside session cleaner still used the endless loop to run. And somehow this gems kept the objects back. As soon as I killed the gems the objects have been freed again. I'll inspect this a little further to be sure. But I also have gotten rid of the endless loop in the script. Now I have three scripts (one for each user) and a mfc running in sequence every hour having each end after a single pass. > > If you are interested I can provide you the altered script. So you might see what is going wrong. Norbert, This is interesting .... I'd like to see the altered script ... and then I'll look more closelely at the expiration code in Seaside as well to see if I can figure out why the gem is holding onto the instances... Thanks, Dale |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |