[Mono-aspnet-list] Memory Leak in Generic Handler

Niknak nick.pateman at certivox.com
Mon Dec 10 15:43:45 UTC 2012

I'm still working on this issue and have come across the following page...


FAQ wrote*
> Quote:
> Memory Usage
> Why does the memory consumed by the Mono process keep growing?
> Mono currently uses a conservative, non-moving, non-compacting garbage
> collector. This means that the heap is not compacted when memory is
> released. This means that applications can produce memory allocation
> patterns that will effectively make the process grow, just like C, C++,
> Perl, Python applications would.
> It is hence important to not get into patterns that would create these
> holes, for example such a hole could be created if you create a block of
> size SIZE, release it, and then create two blocks of size SIZE/2+1.
> ASP.NET in Mono is particularly vulnerable to this kind of memory problems
> because it is easy for developers to define APIs that transfer large blobs
> of data like entire image files, these would allocate a lot of memory that
> can easily be fragmented.
> A simple solution is to try to write your software in a way that large
> data blocks are not allocated, but instead your application handles them
> in blocks (like writing a "copy" command).
> Is there a better collector in the works?
> Yes, there is work to make a new generational collector under way, but it
> will not be ready for a while. For more information on it, see the
> Generational GC page.

As I'm using generic handlers I assume I'm adhering to this anyway, as I'm
writing the request stream directly to disk, unless it's JSON in which I'm
having to parse it of course.  The JSON blobs are tiny so shouldn't result
the memory leaks afaik.

Anyone else experienced this or have any work arounds?


View this message in context: http://mono.1490590.n4.nabble.com/Memory-Leak-in-Generic-Handler-tp4657696p4657719.html
Sent from the Mono - ASP.NET mailing list archive at Nabble.com.

More information about the Mono-aspnet-list mailing list