Server out of memory errors - will erasing arrays make a difference?

[Alan Howard]

We're getting "ERROR (0x8007000E) Not enough storage is available to
complete this operation" errors on a fairly large, busy ASP/SQL Server web
site. The error is being thrown on a line calling oRs.GetRows() on one of
our busiest pages. The array returned from the GetRows() call will be
'cleaned up' when the page goes out of scope, but I wonder if we should be
calling Erase specifically after the last usage to explicitly free allocated
memory. Is there any actual benefit doing this cleanup explicitly? I've
always throught that ASP's memory deallocation was a bit spotty - can anyone
comment.

Thanks.

 

[Tim]

....asp tidying up after itself?

....pages going "out of scope"

your not from an M$ background are you!

tidy up everything. leave nothing open.
..close
set=nothing
everything you can!!!

there is no garbage collection in ASP.

pages don't go out of scope when they are closed. the user may close their
browser, but the server doesn't know this.

hope this gives u some clues.

 

[Alan Howard]

I think we all know what best practices we should be following - I guess I'm
wondering if anyone has run up against this sort of situation in the past
and knows whether explicitly erasing arrays makes a difference. I'm not
talking about ADO objects.

 

[Mark Schupp]

Allocated memory and created objects are supposed to be deallocated and
destroyed when the page script completes. There have been problems in the
past with some of the ADO objects not being destroyed and causing memory
leaks (other com objects may have similar problems) but I don't know of any
problems with arrays.

Make sure that you are closing all ADO objects and setting to all objects to
Nothing as soon as you are done with them. It wouldn't hurt to erase your
arrays but I don't think you would see any impact from that unless your
arrays are very large and a there is a significant delay between the time
that you no longer need the array data and when the page completes.

Just how big are the arrays? Could you process the data in smaller chunks?

 

[Bob Barrows [MVP]]

...asp tidying up after itself?

...pages going "out of scope"

your not from an M$ background are you!

What difference does that make?

tidy up everything. leave nothing open.
.close
set=nothing
everything you can!!!

Sort of. But see:
http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx
and
http://tinyurl.com/3ajhk

there is no garbage collection in ASP.

??!?
From "ASP Internals" by Jon Flanders:
"IServer::CreateObject keeps an internal list of objects it creates. When
the script execution ends, the Server object decrements the reference count
on the interfaces in this list. This doesn't mean that we shouldn't
explicitly garbage-collect when writing ASP, but if we forget, ASP will do
it for us."


There may be bugs in some COM objects that prevent the garbage collection
from working, but there certainly is GC in ASP, as well as in the script
engine.

pages don't go out of scope when they are closed.

LOL
Pages DO go out of scope when the response ends. Everything that happens at
the client is outside of the scope of ASP.

the user may close
their browser, but the server doesn't know this.

Umm, that's irrelevant. The server-side script went out of scope when the
response ended. You may be thinking of the Session ....

Bob Barrows

 

[Bob Barrows [MVP]]

We're getting "ERROR (0x8007000E) Not enough storage is available to
complete this operation" errors on a fairly large, busy ASP/SQL
Server web site. The error is being thrown on a line calling
oRs.GetRows() on one of our busiest pages. The array returned from
the GetRows() call will be 'cleaned up' when the page goes out of
scope, but I wonder if we should be calling Erase specifically after
the last usage to explicitly free allocated memory. Is there any
actual benefit doing this cleanup explicitly? I've always throught
that ASP's memory deallocation was a bit spotty - can anyone comment.

Thanks.

I've never experienced or heard about a memory leak caused by failure to
erase arrays. I do remember back in my VB days reading advice to always
erase them, so for sizable arrays I still tend to follow that advice. I know
.... not much help.

Bob Barrows