Forum Moderators: open
what else can be done to stem memory leakage?
I spent a good two hours this morning wading through a client's data because it looked like the error generated was specific to that client. I couldn't replicate it in my demo set or other clients.
When the second client called with the same issue I knew I had to reboot the server, and after that the first client's data (and all) are working fine again.
So what else can it be? What else can I look for to stem off memory leaks?
If I set an object to nothing (or null) does that also close or reclaim the memory used to create that object?
Thanks.
If I set an object to nothing (or null) does that also close or reclaim the memory used to create that object?
Unfortunately not -- it gives some hint to garbage collector though. I had one hell of a time with .NET dealing with memory leaks -- in this situation I highly recommend using memory leaks profiler as otherwise you will be pretty much guessing.
Thing to be very careful about is putting lots of objects into ArrayLists and Hashtables.
And what is the "memory leaks profiler?"
Anyhow, if you are in classic ASP, then how come .NET is used? Are you using some COM calls or something like that?
I'll have a poke around -G- and see what shakes.
(that's what I get for spending a Saturday afternoon watching Monty Python.....)
If I set an object to nothing (or null) does that also close or reclaim the memory used to create that object?
Yes, but if the object itself is running "out of process" it's possible the object itself is leaking the memory. ASP is pretty good about cleaning up in-process objects but DLL's that run out of scope can leave these type of trails if they aren't cleaning up properly after themselves.
Here's a simple example:
1) IIS creates COM-Object1 (memory allocated #1)
2) COM-Object1 creates SQL Connection (memory allocated #2)
3) IIS destroys COM-Object1 (memory space #1 reclaimed)
4) COM-Object1 goes out of scope.
What happenned here is the COM-Object1 didn't close/destroy the object it created and since it is running out of process, that SQL Connection is orphaned and in many cases the memory space allocated won't be reclaimed properly.
If there are just a few objects, you can track it down by setting up a webpage that calls it over-over again using a java refresh. As the object gets created/destroyed over and over, the memory counts should stay constant. If they decline persistently, you've found your culprit.
Have you checked for excessive Session state usage?
I do use the Session variables quite a bit
I've done major repair to a big site that over-used Session Variables. Once the big site got, well, bigger - poof - nothing really worked very well. I love using them cause they are so easy but use them sparingly, 5-10 per, albeit 10 is a bit on the high end for my preference.
Unfortunately the early ASP books actually encouraged the use of Session variables. I remember one that showed example code of how to put a Connection Object into a Session Variable.
[edit]How to..... Using Performance Monitor, there are several metrics to view ASP/IIS usage statistics.[/edit]
Never actualy seen memory leaks from forgetting to close the db connections, but if you enable connection pooling you will know if thats the problem or not.
5-10 per, albeit 10 is a bit on the high end for my preference
really? as long as session variables don't contain objects, then I have never had a problem with that - I use 30-40 variables on sites with heavy traffic.
I have had big problems with unclosed connections though. In particular I've had problems where users are redirected in certain circumstances before the close connection line. I don't know an easy way of checking for it other than searching every file for "response.redirect" and "response.end".
If you're storing things like database results in Session then you're going to be consuming a lot of memory duuring busy periods.
On most of my sites I disable the session state completely except for member areas. There's quite a bit of processing overhead involved with the session. There's usually much better ways of managing state between pages depending on your application.
users are redirected in certain circumstances before the close connection line
I wonder about this one. I have an error handler that calls response.end and its made me think about that too.
Does response.end/re-direct actually stop a script from finishing on the server or just take control of the response object? If its the latter it shouldnt stop the objects being closed.
I was referring to a recordset, but the connection object will work the same way. Now I'm coding my pages to close down the connection and recordset before a server transfer or response redirect.
users are redirected in certain circumstances before the close connection line
this one surprised me early on. I never suspected this one, but now it's part of the "redirect" routine to always control the objects.
I still get into trouble with the conditional close/null. For example, when I create an object based on another condition, I need a surefire way to close it only if it's been opened or even created.
