CODEWITHSUNDEEP
c#.net
FastAl
FastAl

Reputation: 6280

How do I know if I'm about to get an OutOfMemoryException?

I have a program that processes high volumes of data, and can cache much of it for reuse with subsequent records in memory. The more I cache, the faster it works. But if I cache too much, boom, start over, and that takes a lot longer!

I haven't been too successful trying to do anything after the exception occurs - I can't get enough memory to do anything.

Also I've tried allocating a huge object, then de-allocating it right away, with inconsistent results. Maybe I'm doing something wrong?

Anyway, what I'm stuck with is just setting a hardcoded limit on the # of cached objects that, from experience, seems to be low enough. Any better Ideas? thanks.

edit after answer

The following code seems to be doing exactly what I want:

Loop 
    Dim memFailPoint As MemoryFailPoint = Nothing
    Try
        memFailPoint = New MemoryFailPoint( mysize) ''// size of MB of several objects I'm about to add to cache 
        memFailPoint.Dispose()
    Catch ex As InsufficientMemoryException
        ''// dump the oldest items here
    End Try
   ''// do work
next loop.

I need to test if it is slowing things down in this arrangement or not, but I can see the yellow line in Task Manager looking like a very healthy sawtooth pattern with a consistent top - yay!!

Upvotes: 10

Views: 471

Answers (6)

Only You
Only You

Reputation: 2072

The simple answer... By knowing what your memory limit is.

The closer you are to reach that limit the more you ARE ABOUT to get an OutOfMemoryException.

The more elaborated answer.... Unless you yourself writes a mechanism to do that kind of thing, programming languages/systems do not work that way; as far as I know they cannot inform you ahead or in advance you are exceeding limits BUT, they gladly inform you when the problem has occurred, and that usually happens through exceptions which you are supposed to write code to handle.

Memory is a resource that you can use; it has limits and it also has some conventions and rules for you to follow to make good use of that resource.

I believe what you are doing of setting a good limit, hard coded or configurable, seems to be your best bet.

Upvotes: 0

Justin
Justin

Reputation: 86729

There are a number of metrics you can use to keep track of how much memory your process is using:

The trouble is that there isn't really a reliable way of telling from these values alone whether or not a given memory allocation will fail as although there may be sufficient space in the address space for a given memory allocation memory fragmentation means that the space may not be continuous and so the allocation may still fail.

You can however use these values as an indication of how much memory the process is using and therefore whether or not you should think about removing objects from your cache.

Update: Its also important to make sure that you understand the distinction between virtual memory and physical memory - unless your page file is disabled (very unlikely) the cause of the OutOfMemoryException will be caused by a lack / fragmentation of the virtual address space.

Upvotes: 1

Logan Capaldo
Logan Capaldo

Reputation: 40336

If you implement your cache with WeakRerefences (http://msdn.microsoft.com/en-us/library/system.weakreference.aspx) that will leave the cached objects still eligible for garbage collection in situations where you might otherwise throw an OutOfMemory exception.

This is an alternative to a fixed sized cache, but potentially has the problem to be overly aggressive in clearing out the cache when a GC does occur.

You might consider taking a hybrid approach, where there are a (tunable) fixed number of non-weakreferences in the cahce but you let it grow additionally with weakreferences. Or this may be overkill.

Upvotes: 1

Dan Bryant
Dan Bryant

Reputation: 27495

You can use MemoryFailPoint to check for available memory before allocating.

Upvotes: 9

Otávio Décio
Otávio Décio

Reputation: 74270

You may need to think about your release strategy for the cached objects. There is no possible way you can hold all of them forever so you need to come up with an expiration timeframe and have older cached objects removed from memory. It should be possible to find out how much memory is left and use that as part of your strategy but one thing is certain, old objects must go.

Upvotes: 1

Jorge Córdoba
Jorge Córdoba

Reputation: 52123

If you're only using managed resources you can use the GC.GetTotalMemory method and compare the results with the maximum allowed memory for a process on your architecture.

A more advanced solution (I think this is how SQL Server manages to actually adapt to the available memory) is to use the CLR Hosting APIs:

the interface allows the CLR to inform the host of the consequences of failing a particular allocation

which will mean actually removing some objects from the cache and trying again.

Anyway I think this is probably an overkill for almost all applications unless you really need an amazing performance.

Upvotes: 0

Related Questions