[Mono-dev] [Mono-gc-list] Mono memory problems!
Miguel de Icaza
miguel at novell.com
Wed Jul 18 12:06:02 EDT 2007
> namespace Ipop {
> public class IPOP_Common {
> public static void Main() {
> AutoResetEvent re = null;
> while(true) {
> re = new AutoResetEvent(false);
> re.Close();
> }
> }
> }
> }
>
> blows up memory
That depends on the finalizer to run to release memory from the
unmanaged side, since AutoResetEvent implements IDisposable you should
use it like this:
using (re = AutoResetEvent (false)) {
...
Miguel
> whereas ...
>
> using System.Security.Cryptography;
> using System;
>
> namespace Ipop {
> public class IPOP_Common {
> public static void Main() {
> RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
> while(true) {
> byte[] key = new byte[1024];
> rng.GetBytes(key);
> }
> }
> }
> }
>
> This doesn't.
>
> David Wolinsky wrote:
> > We run this software on system where memory is a concern. The data that
> > we presented is our test case system that has 50 nodes all running in
> > the same mono process. We run only a single node at each site which
> > initially starts at ~15 MB, we've seen it swell to well over 300 MBs in
> > a period of less than a week. Since this must be used in production
> > environments and is meant to be extremely lightweight we can forgive a
> > small memory portion like 15 MB, since it has relatively no processing
> > overhead, but at over 300 MBs our processes are often stopped by the
> > remote admin and we are told to clean up the problem.
> >
> > Since this seems to be a problem of using a non-compacting gc, do you
> > know where the compacting gc is, so that we could at least test it out.
> > I searched the SVN and found no clues of it.
> >
> > Also, I should correct myself, the results for memory consumption were
> > not directly related to the test that grows at 25kB/sec. I found this
> > out after posting the data, I am running heap-shot right now with the
> > correct test and it has grown 100MB in less than 1 hour.
> >
> > Regards,
> > David
> >
> >
> >
> > Alan McGovern wrote:
> >
> >> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have
> >> over 1 gig of memory allocated. As you don't, i think what you're
> >> seeing is just 'normal usage' for the non-compacting GC that mono
> >> uses. I have a similar app which uses sockets extensively (50-150
> >> simultaneous connections) and i can assure you that memory usage
> >> doesn't get unbearably large. It'd be interesting to see the logs but
> >> i don't think there's much to be worried about.
> >>
> >> Alan.
> >>
> >> On 7/18/07, *David Wolinsky* <davidiw at ufl.edu
> >> <mailto:davidiw at ufl.edu>> wrote:
> >>
> >> Initially 45 MB, 12 hours later 147 MB
> >>
> >> Another developer has the heap-shot logs, I'll post those as soon as
> >> possible.
> >>
> >> David
> >>
> >> Alan McGovern wrote:
> >> > Could you post up the detailed stats from heapshot? After the 12
> >> hour
> >> > run, how much memory are you using? Are we talking in the gigabyte
> >> > range, or megabyte range?
> >> >
> >> > Alan.
> >> >
> >> > On 7/18/07, *David Wolinsky* <davidiw at ufl.edu
> >> <mailto:davidiw at ufl.edu>
> >> > <mailto:davidiw at ufl.edu <mailto:davidiw at ufl.edu>>> wrote:
> >> >
> >> > My lab works on a peer-to-peer network overlay and we've noticed
> >> > recently significant memory issues. Some background...
> >> >
> >> > This application is constantly creating new objects and shortly
> >> > thereafter deleting (removing reference to) them
> >> > Using a sample run with 150 threads running...
> >> > Mono on Linux has a growth rate of ~25 KB per second with a
> >> base
> >> > of 50MB
> >> > (y = 25K *x + 50M)
> >> > .NET on Windows stabilizes at 35 MB
> >> >
> >> > We ran heap-shot with Linux and found that in a 12 hour
> >> period it
> >> > reported this...
> >> > start:
> >> > objects: 58,823
> >> > heap memory: 6,838,426 bytes
> >> >
> >> > end:
> >> > objects: 59,925
> >> > heap memory: 6,862,336
> >> >
> >> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size
> >> > (RES) got
> >> > significantly bigger than it.
> >> >
> >> > I have searched for the Compacting GC with no luck, we would
> >> > really like
> >> > to see if it would help our problem.
> >> >
> >> > The only operating system resources we're using are Sockets, but
> >> > we use
> >> > them VERY heavily!
> >> >
> >> > If anyone has any suggestions, we'd be open to test out
> >> anything
> >> > at this
> >> > point!
> >> >
> >> > We are leaning towards an issue in unmanaged memory and
> >> possibly a bug
> >> > in mono.
> >> >
> >> > Best regards,
> >> > David
> >> >
> >> >
> >> > ps, I fwded this to gc and devel list because gc list looks
> >> quite
> >> > dead.... sorry for the duplication
> >> > _______________________________________________
> >> > Mono-devel-list mailing list
> >> > Mono-devel-list at lists.ximian.com
> >> <mailto:Mono-devel-list at lists.ximian.com>
> >> > <mailto:Mono-devel-list at lists.ximian.com
> >> <mailto:Mono-devel-list at lists.ximian.com>>
> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >
> >> >
> >>
> >>
> >>
> >
> > _______________________________________________
> > Mono-gc-list maillist - Mono-gc-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-gc-list
> >
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list