0

During Runtime I find that there is a very big memory usage by my application..

But It seems that I only use 3~4 MemoryStreams one of which is sometimes full of 81 Mb..

The others are mainly 20 mb, 3 mb and 1mb containers...

But still there is 525.xx MB memory usage by the application...

I tried using using(...) statements also but without any luck..

So, I am asking here for the most efficient way to cut down memory leaks.

Writwick
  • 2,133
  • 6
  • 23
  • 54
  • 2
    folks might need more info to figure this out (code etc...). Check out using tools like the allocation profiler to see which objects are in memory: http://dotnet.dzone.com/articles/pinpointing-memory-leaks-clr – bryanmac May 17 '12 at 05:12
  • 2
    I would say you'd probably want to get rid of memory leaks completely. That should help cut them down by a lot. – Tom May 17 '12 at 05:12
  • Without any specific information, this might be helpful: http://stackoverflow.com/questions/620733/memory-leak-in-c-sharp – Ozair Kafray May 17 '12 at 05:14
  • and this: http://blogs.msdn.com/b/davidklinems/archive/2005/11/16/493580.aspx – Ozair Kafray May 17 '12 at 05:14
  • @Tom I need to store some of the files i stated in the memory until the class is Disposed – Writwick May 17 '12 at 05:16
  • You could also try [dotTrace Memory](http://www.jetbrains.com/profiler/) from JetBrains to see what objects are in memory and how big they are. – Dmitrii Erokhin May 17 '12 at 05:16
  • I Checked out CLRProfiler pointed by @bryanmac...And I saw that I was not `Close()`ing and/or `Dispose()`ing the `BinaryReader`s and `BinaryWriter`s that i used with the `MemoryStream`s.. – Writwick May 17 '12 at 05:28

2 Answers2

1

In managed .NET apps, you don't generally have memory "leaks" in the original sense of the word, unless you are allocating unmanaged resource handles and not disposing of them correctly. But that doesn't sound like what you're doing.

More likely is that you are holding on to references to objects that you no longer need, and this is keeping the memory "alive" longer than you are expecting.

For example, if you put 5MB of data into a memory stream, and then assign that memory stream to a static field, then the 5MB will never go away for the lifetime of the application. You need to assign null to the static field that refers to the memory stream when you no longer need what it points to so that the garbage collector will release and reclaim that 5MB of memory.

Similarly, local variables are not released until the function exits. If you allocate a lot of memory and assign it to a local variable, and then call another function that runs for hours, the local variable will be kept alive the whole time. If you don't need that memory anymore, assign null to the local variable.

How are you determining that your app has a memory leak? If you are looking at the process virtual memory allocation shown by Task Manager, that is not very accurate. An application's memory manager may allocate large chunks of memory from the OS and internally free them for other uses within the application without releasing them back to the OS.

Use common sense practices. Call dispose or close as appropriate and assign null to variables as soon as you no longer need their contents.

Just because the garbage collected environment will let you be lazy doesn't mean you shouldn't pay attention to memory allocation and deallocation patterns in your code.

dthorpe
  • 35,318
  • 5
  • 75
  • 119
0

Your definition of memory leak seems to be unusual... Following code will produce exactly the effect you are observing, but it rarely called memory leak:

var data = new byte[512*1024*1024];
data = null;

But you may actually have legitimate leaks. Memory profilers will easily show them, but huge ones can be tracked down by code reviews. If you already know that you have small number of memory streams - check if you don't keep them alive by storing in some list or simply in member variable. Also check if your large arrays are not staying alive for similar reasons.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179