hi - When using the (squeak) image as a database, what is the proper way to save that image on a periodic basis? Doing it the naive way (#snapshot: true andQuit: false, called from a #stepAt: method) leads to my image locking up or crashing on a regular basis (at least I think that this is the cause of the crashes/lockups). I thought I saw code which rather saves a new version of the whole image each time, but I can't find it now. Would that solve the issue? thanks, Michal _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> I thought I saw code which rather saves a new version of the whole
> image each time, but I can't find it now. Would that solve the issue? There are certainly other examples out there, but Pier does that. Have a look at the class PRImagePersistency. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
thanks Lukas - Looking into it, I see that in Jan 2008 you wrote on the pier list: I saw that you have PRImagePersistency set in your image. This will sooner or later result in corrupted sources and changes, if you manually change code or load packages in the image. You have been warned! and then: saving the image while code is compiled can screw up your changes Does this mean that I need to disable the auto-saving everytime I load a new monticello version into the running server? (a rather frequent event!) thanks, Michal _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by michal-list
On Wed, Apr 08, 2009 at 11:58:07PM +0200, Michal wrote:
> > When using the (squeak) image as a database, what is the proper way to > save that image on a periodic basis? Doing it the naive way > (#snapshot: true andQuit: false, called from a #stepAt: method) leads > to my image locking up or crashing on a regular basis (at least I > think that this is the cause of the crashes/lockups). > > I thought I saw code which rather saves a new version of the whole > image each time, but I can't find it now. Would that solve the issue? Michal, If you are using a Unix (OS X or Linux) platform, and have OSProcess in your image, then try this: UnixProcess saveImageInBackgroundNicely This will fork a background Squeak to do the image save without locking up your main server image. You'll need to take care that you have enough disk space of course, but otherwise this approach will do the save with no impact at all on your server image. Dave _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Thu, Apr 09, 2009 at 12:04:58PM +0200, Michal wrote:
> > hi David - > > > If you are using a Unix (OS X or Linux) platform, and have OSProcess in > > your image, then try this: > > > > UnixProcess saveImageInBackgroundNicely > > > > This will fork a background Squeak to do the image save without locking > > up your main server image. You'll need to take care that you have enough > > disk space of course, but otherwise this approach will do the save with > > no impact at all on your server image. > > Excellent, thank you! Do you have experience loading UnixProcess into > a running production server under medium/high load? I have a couple > thousand users relying on that image... Michal, No, I do not. I am not actually running any Seaside server. Definitely you should test carefully. I would suggest that you plan for these possible failure modes: - Out of disk space. Probably your backup process should check in advance to verify that sufficient space is available(*), but you may also want to test the effect of trying to do the save with no space available, just to understand the effect of this kind of failure. - Backup process fails to complete, and the image never exits. If for any reason the backup procedure fails to run to completion, such that the background Squeak process does not exit, you would see an accumulation of background Squeak processes that will eventually consume too many system resources(**). - Memory usage. The background Squeak process consumes a very small amount of memory due (processes share address space after a Unix fork, until memory is actually modified). However this may not be the case if your server image is very active and doing garbage collection. Test this and watch for system memory usage issues when you put this into your production system. (*) Here is one way to check free disk space, assuming you have OSProcess and CommandShell loaded. This example is on a Linux system, and I'm checking free block count on the file system that Squeak is using: freeBlocks := (ProxyPipeline command: 'df . | tail -1 | cut -c41-50 ') upToEndOfFile withBlanksTrimmed asInteger (**) The number of running background processes started by OSProcess is: (OSProcess thisOSProcess allMyChildren select: [:p | p isRunning]) size Dave _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |