Mono memory problems!
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
Mono memory problems!
by David Isaac Wolinsky
::
Rate this Message:
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-gc-list maillist - Mono-gc-list@... http://lists.ximian.com/mailman/listinfo/mono-gc-list |
|
|
Mono memory problems!
by David Isaac Wolinsky
::
Rate this Message:
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-gc-list maillist - Mono-gc-list@... http://lists.ximian.com/mailman/listinfo/mono-gc-list |
|
|
|
|
|
|
|
|
Re: [Mono-dev] Mono memory problems!
by David Isaac Wolinsky
::
Rate this Message:
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@... >> <mailto:davidiw@...>> 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@... >> <mailto:davidiw@...> >> > <mailto:davidiw@... <mailto:davidiw@...>>> 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@... >> <mailto:Mono-devel-list@...> >> > <mailto:Mono-devel-list@... >> <mailto:Mono-devel-list@...>> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> >> > > _______________________________________________ > Mono-gc-list maillist - Mono-gc-list@... > http://lists.ximian.com/mailman/listinfo/mono-gc-list > > _______________________________________________ Mono-gc-list maillist - Mono-gc-list@... http://lists.ximian.com/mailman/listinfo/mono-gc-list |
|
|
Re: [Mono-dev] Mono memory problems!
by David Isaac Wolinsky
::
Rate this Message:
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@... >>> <mailto:davidiw@...>> 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@... >>> <mailto:davidiw@...> >>> > <mailto:davidiw@... <mailto:davidiw@...>>> 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@... >>> <mailto:Mono-devel-list@...> >>> > <mailto:Mono-devel-list@... >>> <mailto:Mono-devel-list@...>> >>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> > >>> > >>> >>> >>> >> >> _______________________________________________ >> Mono-gc-list maillist - Mono-gc-list@... >> http://lists.ximian.com/mailman/listinfo/mono-gc-list >> >> > > _______________________________________________ Mono-gc-list maillist - Mono-gc-list@... http://lists.ximian.com/mailman/listinfo/mono-gc-list |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: [Mono-dev] Mono memory problems!
by Paolo Molaro-2
::
Rate this Message:
On 07/24/07 Jonathan Gagnon wrote:
> I'm pretty sure that this will fix bug #81727 that I filed a few months ago, > although I don't have time to test it for the moment. Thanks, confirmed that issue is fixed as well. lupus -- ----------------------------------------------------------------- lupus@... debian/rules lupus@... Monkeys do it better _______________________________________________ Mono-gc-list maillist - Mono-gc-list@... http://lists.ximian.com/mailman/listinfo/mono-gc-list |
| Free embeddable forum powered by Nabble | Forum Help |
