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