Re: [Mono-gc-list] Mono memory problems!
"Alan McGovern" <[email protected]> Wed, 18 Jul 2007 11:52:07 -0400
| Newsgroups | gmane.comp.gnome.mono.devel,gmane.comp.gnome.mono.garbage-collection |
|---|---|
| Message-ID | <[email protected]> |
--===============0249251405== Content-Type: multipart/alternative; boundary="----=_Part_69912_26085792.1184773927857" ------=_Part_69912_26085792.1184773927857 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 <[email protected]> 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* <[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 > >>> > [email protected] > >>> <mailto:[email protected]> > >>> > <mailto:[email protected] > >>> <mailto:[email protected]>> > >>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >>> > > >>> > > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Mono-gc-list maillist - [email protected] > >> http://lists.ximian.com/mailman/listinfo/mono-gc-list > >> > >> > > > > > > ------=_Part_69912_26085792.1184773927857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Drop a bug report to: <a href="http://bugzilla.ximian.com">bugzilla.ximian.com</a> containing that testcase and put it under the 'compilers' section. It sounds like a gmcs issue.<br><br>Alan.<br><br><div><span class="gmail_quote"> On 7/18/07, <b class="gmail_sendername">David Wolinsky</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> FYI, this case is only triggered when using gmcs and not mcs.<br><br>David<br><br>David Wolinsky wrote:<br>> We've isolated the problem down to AutoResetEvent...<br>><br>> using System;<br>> using System.Threading ;<br>><br>> namespace Ipop {<br>> public class IPOP_Common {<br>> public static void Main() {<br>> AutoResetEvent re = null;<br>> while(true) {<br>> re = new AutoResetEvent(false); <br>> re.Close();<br>> }<br>> }<br>> }<br>> }<br>><br>> blows up memory<br>><br>> whereas ...<br>><br>> using System.Security.Cryptography;<br>> using System;<br>><br> > namespace Ipop {<br>> public class IPOP_Common {<br>> public static void Main() {<br>> RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();<br>> while(true) {<br>> byte[] key = new byte[1024]; <br>> rng.GetBytes(key);<br>> }<br>> }<br>> }<br>> }<br>><br>> This doesn't.<br>><br>> David Wolinsky wrote:<br>>> We run this software on system where memory is a concern. The data <br>>> that we presented is our test case system that has 50 nodes all<br>>> running in the same mono process. We run only a single node at each<br>>> site which initially starts at ~15 MB, we've seen it swell to well <br>>> over 300 MBs in a period of less than a week. Since this must be<br>>> used in production environments and is meant to be extremely<br>>> lightweight we can forgive a small memory portion like 15 MB, since <br>>> it has relatively no processing overhead, but at over 300 MBs our<br>>> processes are often stopped by the remote admin and we are told to<br>>> clean up the problem.<br>>><br>>> Since this seems to be a problem of using a non-compacting gc, do you <br>>> know where the compacting gc is, so that we could at least test it<br>>> out. I searched the SVN and found no clues of it.<br>>><br>>> Also, I should correct myself, the results for memory consumption <br>>> were not directly related to the test that grows at 25kB/sec. I<br>>> found this out after posting the data, I am running heap-shot right<br>>> now with the correct test and it has grown 100MB in less than 1 hour. <br>>><br>>> Regards,<br>>> David<br>>><br>>><br>>><br>>> Alan McGovern wrote:<br>>><br>>>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have<br> >>> over 1 gig of memory allocated. As you don't, i think what you're<br>>>> seeing is just 'normal usage' for the non-compacting GC that mono<br>>>> uses. I have a similar app which uses sockets extensively (50-150 <br>>>> simultaneous connections) and i can assure you that memory usage<br>>>> doesn't get unbearably large. It'd be interesting to see the logs<br>>>> but i don't think there's much to be worried about. <br>>>><br>>>> Alan.<br>>>><br>>>> On 7/18/07, *David Wolinsky* <<a href="mailto:[email protected]">[email protected]</a><br>>>> <mailto:<a href="mailto:[email protected]">[email protected] </a>>> wrote:<br>>>><br>>>> Initially 45 MB, 12 hours later 147 MB<br>>>><br>>>> Another developer has the heap-shot logs, I'll post those as<br>>>> soon as<br> >>> possible.<br>>>><br>>>> David<br>>>><br>>>> Alan McGovern wrote:<br>>>> > Could you post up the detailed stats from heapshot? After the 12<br>>>> hour <br>>>> > run, how much memory are you using? Are we talking in the<br>>>> gigabyte<br>>>> > range, or megabyte range?<br>>>> ><br>>>> > Alan.<br>>>> > <br>>>> > On 7/18/07, *David Wolinsky* <<a href="mailto:[email protected]">[email protected]</a><br>>>> <mailto:<a href="mailto:[email protected]">[email protected]</a>><br>>>> > <mailto: <a href="mailto:[email protected]">[email protected]</a> <mailto:<a href="mailto:[email protected]">[email protected]</a>>>> wrote:<br>>>> ><br>>>> > My lab works on a peer-to-peer network overlay and we've <br>>>> noticed<br>>>> > recently significant memory issues. Some background...<br>>>> ><br>>>> > This application is constantly creating new objects and<br> >>> shortly<br>>>> > thereafter deleting (removing reference to) them<br>>>> > Using a sample run with 150 threads running...<br>>>> > Mono on Linux has a growth rate of ~25 KB per second with a <br>>>> base<br>>>> > of 50MB<br>>>> > (y = 25K *x + 50M)<br>>>> > .NET on Windows stabilizes at 35 MB<br>>>> ><br>>>> > We ran heap-shot with Linux and found that in a 12 hour <br>>>> period it<br>>>> > reported this...<br>>>> > start:<br>>>> > objects: 58,823<br>>>> > heap memory: 6,838,426 bytes<br>>>> > <br>>>> > end:<br>>>> > objects: 59,925<br>>>> > heap memory: 6,862,336<br>>>> ><br>>>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory <br>>>> size<br>>>> > (RES) got<br>>>> > significantly bigger than it.<br>>>> ><br>>>> > I have searched for the Compacting GC with no luck, we would <br>>>> > really like<br>>>> > to see if it would help our problem.<br>>>> ><br>>>> > The only operating system resources we're using are<br> >>> Sockets, but<br>>>> > we use<br>>>> > them VERY heavily!<br>>>> ><br>>>> > If anyone has any suggestions, we'd be open to test out <br>>>> anything<br>>>> > at this<br>>>> > point!<br>>>> ><br>>>> > We are leaning towards an issue in unmanaged memory and<br>>>> possibly a bug <br>>>> > in mono.<br>>>> ><br>>>> > Best regards,<br>>>> > David<br>>>> ><br>>>> ><br>>>> > ps, I fwded this to gc and devel list because gc list looks <br>>>> quite<br>>>> > dead.... sorry for the duplication<br>>>> > _______________________________________________<br>>>> > Mono-devel-list mailing list <br>>>> > <a href="mailto:[email protected]">[email protected]</a><br>>>> <mailto:<a href="mailto:[email protected]">[email protected] </a>><br>>>> > <mailto:<a href="mailto:[email protected]">[email protected]</a><br>>>> <mailto:<a href="mailto:[email protected]">[email protected] </a>>><br>>>> > <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>>>> ><br>>>> ><br> >>><br>>>><br>>>><br>>><br>>> _______________________________________________<br>>> Mono-gc-list maillist - <a href="mailto:[email protected]">[email protected] </a><br>>> <a href="http://lists.ximian.com/mailman/listinfo/mono-gc-list">http://lists.ximian.com/mailman/listinfo/mono-gc-list</a><br>>><br>>><br>><br>><br><br></blockquote></div><br> ------=_Part_69912_26085792.1184773927857-- --===============0249251405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list --===============0249251405==--