What happens if your asp.net app is using too much memory?

Lets say that you are usin开发者_运维百科g a shared hosting plan and your application stores lots of objects in the application state.

If they start taking too much memory does this mean that the server will just remove them?

If not what will happen then? What happens when the server has no memory left? Can you still store objects into the application or session state?

I am asking this because i am planning on developing a big site that will rely on the application state, and it will be crucial that the objects stored there don't get destroyed. What i am afraid of is that at a certain point i might have too many objects in the application state and they might get removed to free up memory.

There are three different thresholds:

1. The total size of your app exceeds the maximum process size on your machine (really only applicable with an x86 OS). In that case, you'll start getting out of memory errors at first, generally followed very quickly by a process crash.

2. Your process, along with everything else running on the machine, no longer fits in physical memory. In that case, the machine will start to page, generally resulting in extremely poor performance.

3. Your process exceeds the memory limit imposed by IIS on itself, via IIS Manager. In that case, the process will be killed and restarted, as with a regular AppPool recycle.

With the Application object, entries are not automatically removed if you approach any of the above thresholds. With the Cache object, they can be removed, depending on the priority you assign.

As others have said, over-using the Application object isn't generally a good idea, because it's not scalable. If you were ever to add a second load-balanced server, keeping the info in sync from one server to another becomes very challenging, among other things.

What happens when any application takes up too much memory on a computer?

It causes the server to run everything really slowly. Even the other sites that share the computer.

It's not a good idea to store that much in application state. Use your config file and/or the database.

It sounds like you have a memory leak, the process keeps leaking memory until it crushes with an out-of-memory condition and is then automatically restarted by the server.

1.5GB is about the maximum amount of memory a 32 bit process can allocate before running out of address space.

Somethings to look for:

• Do you do your own caching? when are items removed from the cache?

• Is there somewhere data is added to a collection every once in a while but never removed?

• Do you call Dispose on every object that implements IDisposable?

• Do you access any non-managed code at all (COM objects or using DllImport) or allocate non-managed memory (using the Marshal class for example)? anything that is allocated there is never freed by the garbage collector, you have to free it yourself.

• Do you use 3rd party libraries or any code from 3rd parties? it can have any of the problems in the list too.

If you use the Cache object instead of the Application object, you can minimize problems of running out of memory. If the memory utilization of the ASP.Net worker process approaches the point at which the process will be bounced automatically (the recycle limit), the memory in Cache will be scavenged. Items that haven't been used for a while are removed first, potentially preventing the process from recycling. If the data is stored in Application, ASP.Net can do nothing to prevent the process from recycling, and all app state will be lost.

However, you do need to have a way of repopulating the Cache object. You could do that by persisting the cached data in a database, as others have proposed.

Here's a short article with a good code example for handling Cache.

And here's a video of how to use Cache.

Anything stored in application state should be refreshable, and needs to be saved in current status in files or database. If nothing else happens, IIS restarts worker processes at least once a day, so nothing in application state will be there forever.

If you do run out of memory, you'll probably get an out of memory exception. You can also monitor memory usage, but in a shared host environment, that may not be enough information to avoid problems. And you may get the worker process recycled as an "involuntary" fix.

When you say that it's crucial that objects stored in application state don't get destroyed, it sounds like you're setting yourself up for trouble.

I think you should use session instead of the application sate and stored that session into sql server database. So once your application user end its session that will release your memory.

If you want more specific answer then please provide the more information about your application.