[Mono-dev] [Mono-gc-list] Mono memory problems!
David Wolinsky
davidiw at ufl.edu
Wed Jul 18 13:54:49 EDT 2007
That case leaks as well.
Regards,
David
Miguel de Icaza wrote:
>> 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