[Mono-dev] [Mono-gc-list] Mono memory problems!
Alan McGovern
alan.mcgovern at gmail.com
Wed Jul 18 11:52:07 EDT 2007
Drop a bug report to: bugzilla.ximian.com containing that testcase and put
it under the 'compilers' section. It sounds like a gmcs issue.
Alan.
On 7/18/07, David Wolinsky <davidiw at ufl.edu> wrote:
>
> FYI, this case is only triggered when using gmcs and not mcs.
>
> David
>
> David Wolinsky wrote:
> > We've isolated the problem down to AutoResetEvent...
> >
> > using System;
> > using System.Threading;
> >
> > namespace Ipop {
> > public class IPOP_Common {
> > public static void Main() {
> > AutoResetEvent re = null;
> > while(true) {
> > re = new AutoResetEvent(false);
> > re.Close();
> > }
> > }
> > }
> > }
> >
> > blows up memory
> >
> > 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
> >>
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070718/5344b9cd/attachment.html
More information about the Mono-devel-list
mailing list