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* <[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]>> 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* <[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]> >>>> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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@lists.ximian.com >>>> <mailto:Mono-devel-list@lists.ximian.com> >>>> > <mailto:Mono-devel-list@lists.ximian.com >>>> <mailto:Mono-devel-list@lists.ximian.com>> >>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> > >>>> > >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Mono-gc-list maillist - [EMAIL PROTECTED] >>> http://lists.ximian.com/mailman/listinfo/mono-gc-list >>> >>> >>> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list