On 23.07.2010, at 17:11, David T. Lewis wrote: > Yes, it really is true. That said, I would expect the practical impact > to vary depending on how busy the main image is. > > If you are running a Squeak/Pharo image that is not busy, such as your > own personal desktop image or a Seaside image that is not currently > receiving requests, then the additional system memory used by the > forked background image is extremely small (it's pretty amazing > actually, try watching it on a system monitor such as xosview). > However, I would expect that if you were to do this with a busy > Seaside image, then that image would be doing a lot of updates to > memory and possibly garbage collection, so that will force the OS > to use more memory. > What you are saying depends on the environment underneath. In theory it is pretty easy. The fork doubles the process memory when forking. Systems like linux have something called "memory overcommit". They don't allocate the reserved memory unless something is written. I think that is what you meant by saying "... is extremely small...". Why I am saying this? Because especially for seaside images the situation could be different. It is very common nowadays to use OS virtualization to install things like seaside images. Virtualizers disable "memory overcommitment" because otherwise one virtual instance could have side effects on other instances. So you are back with doubling process memory. You need to be careful if you have a small virtual machine or if you try to fork from several images at the same time.
hope this adds anything, Norbert > Unfortunately this means that the busier your image is, the less > benefit you get from a memory usage point of view. But even at that, > you still get the advantage of doing the image save in a background > OS process running at lower OS scheduling priority. > > I do not actually run any Seaside server images, so someone would > need to try this on a real system to find out how much benefit it > delivers in practice. I would be interested to know the results. > > Dave > > > On Fri, Jul 23, 2010 at 02:12:14PM +0200, Lukas Renggli wrote: >> David, is what is said about memory management really true? I thought >> that saving the image triggered a garbage collect what forces to copy >> the whole memory anyway. >> >> Lukas >> >> On 23 July 2010 14:00, David T. Lewis <[email protected]> wrote: >>> On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >>>>> But How I can do that without fork? I track changes in another process and >>>>> when I do update I save image in this process. >>>>> How I can initiate image saving from ui process? >>>> >>>> I don't understand what you are saying. >>>> >>>> The thing is that using #fork to save the image has no effect (other >>>> than wrecking the image), because #snapshot:andQuit: is eventually >>>> calling a primitive that locks the complete VM anyway. >>>> >>>> If you want to fork while saving the image you need to use an OS-level >>>> fork, not a Smalltalk-level fork. You can do this with OSProcess for >>>> example (check the Seaside mailing-list archive). >>> >>> "UnixProcess saveImageInBackgroundNicely" >>> >>> Explained in the method comment: >>> >>> UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag >>> ? ? ? ?"When Squeak is used as a server it is sometimes desirable to >>> periodically >>> ? ? ? ?save image snapshots. This method forks a headless Squeak to perform >>> a >>> ? ? ? ?snapshot without impacting the server Squeak. Very little additional >>> memory >>> ? ? ? ?is required to do this because Unix copy-on-write memory management >>> allows >>> ? ? ? ?the two Squeak images to share object memory while the save is >>> performed. >>> ? ? ? ?The saved image is given a time stamped name, and the image name of >>> ? ? ? ?the main server Squeak remains unchanged. If niceFlag is true, the >>> ? ? ? ?background OS process runs at lowered scheduling priority." >>> >>> Dave >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
