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* <[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