2

I have an ASP Classic application that runs currently in IIS6, but often due to the original programmer not following "best practices" this application throws an Out of Memory error after several hours.

Originally, I had asked this question on StackOverflow in reference to the original problem.

The ideal solutions would be to migrate the application to .NET, or to troubleshoot the raw code to find the memory leakage and remedy it. However, there are nearly a million lines of code...and it has taken time to find various problems and fix them and more time is required to find further memory leaks.

My question is: Would IIS7 handle VBScript memory usage better or more efficiently than IIS6 that it would be an improvement? Is it worth it to migrate the application to IIS7 to help alleviate this problem? Obviously the entire problem would not go away, as there are still leaks, but would it improve?

The application is running on Windows Server 2003.

Community
  • 1
RogueSpear00
  • 162
  • 1
  • 1
  • 9

2 Answers2

3

It would run longer if you moved to x64. It could use as much memory as you could throw at it before blowing up. In x86, you probably would not even reach the 2 GB process limit before blowing up. Then you could recycle the application pool less often and hopefully after hours when fewer users are impacted.

But does it "handle VBScript better or more efficiently"? Nope.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • I see. I understand how it would improve memory allocation in an x64 environment, and it makes sense. However, with it not handling VBScript memory usage any different it may be a moot point to migrate. But, I will have to test this out to ensure a proper answer. Appreciate the feedback, @Greg Askew – RogueSpear00 Feb 22 '12 at 16:04
0

Migrating might be more trouble than it's worth. IIS 6 has basically the same recycling options as 7, and that's probably what I'd be considering first in your situation.

If it's actually leaking memory, you could implement memory-limit-based recycling.

For example: if the app eventually pops 800MB private bytes, it gets recycled. (Recycling creates a new process to replace the old one, then terminates the old one).

If your app doesn't respond badly to recycling (recycling causes a loss of state - eg, session state, in-memory variables, etc), that might be a good option. If it's stateless, you could also look at setting maxprocesses > 1 (a "web garden"), which would in theory multiply the time before failure by the number of worker processes. (this assumes you have n * 2GB RAM to throw at it)

If it does, and your app has a defined lifetime, implementing a shorter recycle interval than that would work (eg, recycle every 1 hour).

TristanK
  • 8,953
  • 2
  • 27
  • 39
  • Very interesting @TristanK! When I recycle my app now, it does lose sessions, etc., unfortunately. Also, I think in further reading, I don't believe VBScript responds to memory management within the App Pool. At least that's what I'm getting, but I've been known to be wrong! :) – RogueSpear00 Feb 23 '12 at 15:07
  • Would it be best to try and automatically recycle the app based on Virtual or Physical memory? – RogueSpear00 Feb 23 '12 at 16:54
  • 1
    The memory-based recycling limits aren't something the app knows about, they're a trigger to *kill* the current worker process and start a new one (actually, start a new one *then* kill the old one). On what specific numbers to use: If you can say for sure your app will break at 800MB private (virtual is always higher than private bytes), then implement a recycle at 700MB. – TristanK Feb 23 '12 at 21:00
  • 1
    VBScript does its own memory management and it'd be uncommon for it to leak without provocation - if you're using heavy COM objects etc, don't stuff them into session variables, acquire and release them each time a page runs. Etc. But if your app doesn't respond well to recycling, you're pretty much left with "more headroom" as Greg suggested. – TristanK Feb 23 '12 at 21:01