Hello all.
I am having a problem with the Squeak VM running on Linux 2.6.11 with an SMP kernel (2 real processors appears to the OS to be 4 via Hyper- Threading ). The image is running a fairly active Seaside application. The application runs an external process very often (convert). It also access an external file after the external process completes. `lsof | grep squeak | wc -l` usualy returns a number around 120. The squeak version is 3.7-7 #1 Wed Oct 26 17:11:21 EDT 2005 gcc 3.4.3 Squeak3.7 of '4 September 2004' [latest update: #5989] The image will lockup (or start responding slowly) `top` reports 99.x % CPU usage. Opening the process browser will show the "UI process" taking up about 60% and the event tickler taking up the remaining. The UI process appears to be using so much process time because of the process browser. During the normal running of the application only a workspace is open. The web application will slow way down. From almost instantaneous. to 5 sec plus. Restarting (save and quit and reopening the image) will restore the application back to it's speedy self. An expectable level of speed will last for about 2 to 3 days. If the image is "doing nothing" the Squeak image will then hang around 50% CPU time. As soon as someone access a page the image will freeze for a second or two. Has anyone experienced this sort of issue ? Is there any known resolution or steps I could take to eliminate the problem? Thanks Will |
probably its something else, but what you might want to make sure is
that it is not the weak weak array finalization of Squeak that is typically a problem with Seaside applications. For example see http:// macos.tuwien.ac.at:9009/15376353.asHtml Maybe you could manage to find some more data points? Adrian On Jan 31, 2006, at 23:34 , William Harford wrote: > Hello all. > > I am having a problem with the Squeak VM running on Linux 2.6.11 > with an SMP kernel (2 real processors appears to the OS to be 4 via > Hyper-Threading ). > > The image is running a fairly active Seaside application. The > application runs an external process very often (convert). It also > access an external file after the external process completes. > > `lsof | grep squeak | wc -l` usualy returns a number around 120. > > The squeak version is > 3.7-7 #1 Wed Oct 26 17:11:21 EDT 2005 gcc 3.4.3 > Squeak3.7 of '4 September 2004' [latest update: #5989] > > The image will lockup (or start responding slowly) `top` reports > 99.x% CPU usage. > > Opening the process browser will show the "UI process" taking up > about 60% and the event tickler taking up the remaining. > > The UI process appears to be using so much process time because of > the process browser. > > During the normal running of the application only a workspace is open. > The web application will slow way down. From almost instantaneous. > to 5 sec plus. > Restarting (save and quit and reopening the image) will restore the > application back to it's speedy self. > > An expectable level of speed will last for about 2 to 3 days. > > If the image is "doing nothing" the Squeak image will then hang > around 50% CPU time. As soon as someone access a page the image > will freeze for a second or two. > > Has anyone experienced this sort of issue ? > > Is there any known resolution or steps I could take to eliminate > the problem? > > Thanks > Will > |
the weak array finalization process does not appear to be taking up
and processing time. I have not been able to come up with any more data points. I was kind of wondering if someone could give me some advice that might some up with more data points. Thanks Will On 31-Jan-06, at 5:46 PM, Adrian Lienhard wrote: > probably its something else, but what you might want to make sure > is that it is not the weak weak array finalization of Squeak that > is typically a problem with Seaside applications. For example see > http://macos.tuwien.ac.at:9009/15376353.asHtml > > Maybe you could manage to find some more data points? > > Adrian > |
In reply to this post by William Harford
It appears to be the UI process that is either causing or
exacerbating the vm lockups. To fix the problem I use Seaside's ability to suspend the UI process. While I am not yet sure if it solves the problem I have had an image running for a week with out any problems. On 31-Jan-06, at 5:34 PM, William Harford wrote: > Hello all. > > I am having a problem with the Squeak VM running on Linux 2.6.11 > with an SMP kernel (2 real processors appears to the OS to be 4 via > Hyper-Threading ). > > The image is running a fairly active Seaside application. The > application runs an external process very often (convert). It also > access an external file after the external process completes. > > `lsof | grep squeak | wc -l` usualy returns a number around 120. > > The squeak version is > 3.7-7 #1 Wed Oct 26 17:11:21 EDT 2005 gcc 3.4.3 > Squeak3.7 of '4 September 2004' [latest update: #5989] > > The image will lockup (or start responding slowly) `top` reports > 99.x% CPU usage. > > Opening the process browser will show the "UI process" taking up > about 60% and the event tickler taking up the remaining. > > The UI process appears to be using so much process time because of > the process browser. > > During the normal running of the application only a workspace is open. > The web application will slow way down. From almost instantaneous. > to 5 sec plus. > Restarting (save and quit and reopening the image) will restore the > application back to it's speedy self. > > An expectable level of speed will last for about 2 to 3 days. > > If the image is "doing nothing" the Squeak image will then hang > around 50% CPU time. As soon as someone access a page the image > will freeze for a second or two. > > Has anyone experienced this sort of issue ? > > Is there any known resolution or steps I could take to eliminate > the problem? > > Thanks > Will |
Free forum by Nabble | Edit this page |