[Mono-dev] [Mono-gc-list] Mono memory problems!
Robert Jordan
robertj at gmx.net
Wed Jul 18 12:02:36 EDT 2007
Alan McGovern wrote:
> Drop a bug report to: bugzilla.ximian.com containing that testcase and put
> it under the 'compilers' section. It sounds like a gmcs issue.
That's rather a NET_2_0 issue. AutoResetEvent has a different
implementation under 2.0.
Robert
>
> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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