We've been having Out of Memory issues with our mixed classic ASP/.NET site for quite some time. Basically, we see a couple of different cases:
- Some request (SQL query that returns a LARGE recordset) happens that causes memory to drastically spike (Private and Virtual Bytes), and the IIS worker process crashes, and the application pool recycles.
- Private Bytes remain 'normal', but Virtual Bytes is at its max (~2GB), and the IIS worker process crashes, app pool recycles.
Crashes have the EventID's: 1009, 1011, & 1013.
In both cases, ASP reports Out of Memory messages in our application log.
If we truly are 'out of memory', why is that users ALREADY in the application can still work and new users are blocked from even logging in? Wouldn't that mean that NO requests could be served?
Obviously, IIS can still serve some requests -- so the answer is probably that it depends on the specific request. Maybe one is more 'expensive' than the other?
In any case, my ultimate question is -- at what point does the application pool say enough is enough, I MUST recycle?
We ran DebugDiag and saw some heaps that were over 90% or even 100% fragmented, so does the recycle happen only when fragmentation is high AND there is no more heap space?
This is a slightly subjective question but I hope I can get some input on sort of what that threshold is!