Debugger taking memory and processor time

[totallyobjects]

We have an odd problem.

Having been running an image controlling one of our web sites for four years, we found, the other day, that the web site was timing out continually.

This is a 6.0.2 image running WebConnection. Nothing has changed with the set up of the computer or the configuration of the WebConnection software.

Basically, we have the occasional debug issue which is hard to resolve as none of our customers can tell us what they did - as we don't know who they are because they use the system anonymously until they need to buy a product. However, it seems that once the debug window pops up, the memory being taken by the Smalltalk image grows and the processor usage leaps to in excess of 50%. The program, on startup, takes around 63MB, with embedded memory held data. The memory usage grows to around 130MB and at that point everything stops. The memory usage seems to be connected with the debug window. When we shut the debug window, the program starts to respond again, albeit very slowly.
Also, we use socket connections to access data from a wholesaler web site and that stops at this point with time outs but I think that this is as a result not a symptom of the problems.

Does anyone have any idea of what is going on here. I have close to 14 years experience of VAST and have not come across this before.

David
Totally Objects.

[Diane Engles]

Hi David,

What does the stack trace show in the debugger? Is there a chance a dialog might be trying to open that is affecting the processor usage?

[totallyobjects]

I solved the main problem. Unbelievably, we had deleted a printer and the each web connection thread just died whilst waiting to print.

Now we have sorted that, we still have the memory growth problem. Over a two day period, the running WebConn app will grow for around 48mb to around 120mb and then keep growing. Eventually socket connections fail and the whole thing has to be restarted. Now that the freeze has gone, the memory usage increase doesn't hurt until it gets too large.

As we don't have the time to spend on this, we could manage this if we knew of a way to know the total memory usage of the app whilst it was running. We could then monitor the memory usage and send an e-mail when it grew to a certain point. We could then do a physical restart. Mickey Mouse I know but it would solve the problem whilst we track down the real issue. Can you suggest how we might monitor the memory usage?

Thanks

David

[PhotonDemon]

Hi Dave,

Attached is a windows specific object (and a helper class) that among other things will get the memory used from windows. Create an instance and send it #setStats from time to time and it will get the current values for memory used, an estimate of percent CPU time and the current windows priority.

As for the ever increasing memory usage, I add the following code to my windows NT services:

Code: Select all

   delay := Delay forSeconds: 300.
   [mainProcessFlag] whileTrue: [
      delay wait.
      Processor finalizeCycle.
      System scavenge.
   ].


where: mainProcessFlag is a boolean that is set to false when the server is being shutdown.

I found this code keeps things clean so a garbage collect can do its work.

Lou

[totallyobjects]

Sorry not to come back sooner but we finally tracked down what was going on.

Some time around this problem, we re-wrote a WebConn page which had a table embedded. We had been using the provided htnl table widget which has always worked fine. However, we wanted to get alternate line colouring so we hand crafted the table using some code we wrote years ago.

What we hadn't reckoned on was how many results were going to appear. When there were 20 - 50 - no problem - when there were 200 - whammo - the system froze.

It turned out to be our sloppy programming. As a quick code, we had used concatenation when building strings. hence, on a large table, which generated a huge amount of string content, the system would just grind to a halt. 3 minutes work, changing concatenation to Streams and everything went back to normal.

health Warning - don't use a time sensitive process just because you get away with it. Some day you won't and you won't be able to remember what you did.

thanks to all who offered help.
David