If you forget to close an Open File in your app, its remain locked, but you usually discover that during testing and fix it. If you don't need any releasing, don't implement IDisposable and it won't be tracked
On Wed, Mar 4, 2009 at 2:16 PM, Ayende Rahien <[email protected]> wrote: > The problem is that people don't call release.Then they have a memory leak > because of this behavior.- Show quoted text - > > > On Wed, Mar 4, 2009 at 12:07 PM, hammett <[email protected]> wrote: > >> >> As much as any disposable type expects to be disposed. As Craig >> pointed out, this should happen on the bootstraping code, not >> throughout the application. I dont see the problem. But I can be >> convinced otherwise. >> >> >> Cheers, >> hammett >> http://hammett.castleproject.org/ >> Sent from: Vancouver British Columbia Canada. >> >> >> On Wed, Mar 4, 2009 at 12:00 PM, Ayende Rahien <[email protected]> wrote: >> > _having_ to release means that we are putting the onus on the developer >> to >> > do the right thing. >> > I think that this is a mistake to do so by default. Especially since we >> > generally don't need this in .Net >> > If we do need it, we can activate the feature, and >> assume responsibility for >> > its operation. >> > >> > On Wed, Mar 4, 2009 at 11:47 AM, Craig Neuwirt <[email protected]> >> wrote: >> >> >> >> yes, but generally just the root object and the component burden does >> the >> >> rest which is very important service >> >> >> >> On Wed, Mar 4, 2009 at 1:36 PM, Ayende Rahien <[email protected]> >> wrote: >> >>> >> >>> The problem is that this means that you have to release. >> >>> >> >>> On Wed, Mar 4, 2009 at 11:18 AM, Craig Neuwirt <[email protected]> >> >>> wrote: >> >>>> >> >>>> Dispose is just one type of decomission. There are other that get >> added >> >>>> dynamically by facilities which need to be applied >> when components are >> >>>> released. I think this behavior is important by default >> >>>> >> >>>> On Wed, Mar 4, 2009 at 12:51 PM, Ayende Rahien <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>> It seems that a lot of people are surprised by this behavior, I >> think >> >>>>> it would be wiser to no track components by default. >> >>>>> Thoughts? >> >>>>> >> >>>>> On Wed, Mar 4, 2009 at 8:54 AM, kurtharriger < >> [email protected]> >> >>>>> wrote: >> >>>>>> >> >>>>>> I don't understand why this isn't the default setting either. >> IMHO, >> >>>>>> Transient objects should not be tracked by default. >> >>>>>> >> >>>>>> As many several have noticed the issues arising tracking transient >> >>>>>> objects for dispose is greater then the risk of not calling dispose >> at >> >>>>>> all (and unless the object holds unmanaged resources, dispose is >> not >> >>>>>> all that necessary anyway). A disposable component that *must be >> >>>>>> disposed* should also implement a finalizer and that doesn't change >> by >> >>>>>> using a container since there is no guarantee dispose will be >> called >> >>>>>> on container either. Since release accepts the object to dispose as >> a >> >>>>>> parameter there isn't any reason to track it, if object is not >> tracked >> >>>>>> then assume it is transient and call dispose if implemented. >> >>>>>> >> >>>>>> - Kurt >> >>>>>> >> >>>>>> >> >>>>>> On Mar 3, 4:57 pm, Andrew Smith <[email protected]> wrote: >> >>>>>> > Yea, I was worried about negative effects of this also. You don't >> >>>>>> > get >> >>>>>> > something for nothing, right? The only mention I've seen so far >> is a >> >>>>>> > comment >> >>>>>> > from hammett in the another post to this group ("ViewComponent >> >>>>>> > memory >> >>>>>> > leak"): >> >>>>>> > >> >>>>>> > "The side effects is that you might have disposable components >> that >> >>>>>> > are >> >>>>>> > not being disposed by the container" >> >>>>>> > >> >>>>>> > In my case I know I don't have any disposable components >> involved, >> >>>>>> > so after >> >>>>>> > some proper testing, I'll be applying the 'fix' to my server >> >>>>>> > >> >>>>>> > On Tue, Mar 3, 2009 at 11:45 PM, Stefan Sedich >> >>>>>> > <[email protected]>wrote: >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > > Excellent glad I could help. But I would look into releasing >> your >> >>>>>> > > objects properly, not sure maybe someone can comment on >> negative >> >>>>>> > > impacts of using NoTrack policy. >> >>>>>> > >> >>>>>> > > Cheers >> >>>>>> > >> >>>>>> > > On Wed, Mar 4, 2009 at 9:43 AM, Andrew Smith < >> [email protected]> >> >>>>>> > > wrote: >> >>>>>> > > > just changed the policy and re-ran a local stress test. >> >>>>>> > > > Immediate >> >>>>>> > > > improvement. Previous test ended with memory usage of ~200MB, >> >>>>>> > > > this time >> >>>>>> > > > round 70MB >> >>>>>> > > > thanks again! >> >>>>>> > >> >>>>>> > > > On Tue, Mar 3, 2009 at 11:37 PM, Stefan Sedich >> >>>>>> > > > <[email protected]> >> >>>>>> > > > wrote: >> >>>>>> > >> >>>>>> > > >> No problems, >> >>>>>> > >> >>>>>> > > >> Something that caught me too, I knew a few people that were >> not >> >>>>>> > > >> aware >> >>>>>> > > >> and they had never stress tested their apps or realised it >> was >> >>>>>> > > >> resetting (dangerous). I am glad I profile my stuff before >> >>>>>> > > >> putting it >> >>>>>> > > >> anywhere near production. I guess releasing is the way >> proper >> >>>>>> > > >> way to >> >>>>>> > > >> handle things, but I have been naughty and just used >> >>>>>> > > >> NoTracking. >> >>>>>> > >> >>>>>> > > >> Cheers >> >>>>>> > >> >>>>>> > > >> On Wed, Mar 4, 2009 at 9:33 AM, Andrew Smith >> >>>>>> > > >> <[email protected]> >> >>>>>> > > >> wrote: >> >>>>>> > > >> > Hi Stefan, >> >>>>>> > > >> > you know as soon as I posted that, of course I came >> across >> >>>>>> > > >> > details on >> >>>>>> > > >> > this >> >>>>>> > > >> > issue. In fact your very blog post. In all the time I've >> used >> >>>>>> > > >> > castle, >> >>>>>> > > I >> >>>>>> > > >> > never realised I was expected to explicitly release a >> >>>>>> > > >> > transient >> >>>>>> > > >> > component. >> >>>>>> > > >> > By the sounds of it, I'm sure that will be the cause as >> I'm >> >>>>>> > > >> > using >> >>>>>> > > >> > windsor >> >>>>>> > > >> > integration heavily and can easily repro the issue with a >> >>>>>> > > >> > local stress >> >>>>>> > > >> > test. >> >>>>>> > > >> > Thanks for the info >> >>>>>> > > >> > Cheers, >> >>>>>> > > >> > Andrew >> >>>>>> > >> >>>>>> > > >> > On Tue, Mar 3, 2009 at 11:24 PM, Stefan Sedich < >> >>>>>> > > [email protected]> >> >>>>>> > > >> > wrote: >> >>>>>> > >> >>>>>> > > >> >> Andrew, >> >>>>>> > >> >>>>>> > > >> >> I have built a few simmilar sounding shop fronts, with >> >>>>>> > > >> >> medium load >> >>>>>> > > and >> >>>>>> > > >> >> have not had issues with memory leaks with the app pools >> >>>>>> > > >> >> running >> >>>>>> > > solid >> >>>>>> > > >> >> until their nightly reset. >> >>>>>> > >> >>>>>> > > >> >> If you hit your site with a web stress testing tool do >> you >> >>>>>> > > >> >> see the >> >>>>>> > > >> >> memory continue to climb until app pool reset? If this is >> >>>>>> > > >> >> the case it >> >>>>>> > > >> >> is possible you have a memory leak. >> >>>>>> > >> >>>>>> > > >> >> I would suggest getting a tool like ANTS profiler to see >> if >> >>>>>> > > >> >> you can >> >>>>>> > > >> >> track down any memory leaks in your application and then >> go >> >>>>>> > > >> >> from >> >>>>>> > > >> >> there. I would say from what I have seen in my apps >> ~200MB >> >>>>>> > > >> >> seems >> >>>>>> > > >> >> reasonable depending on what it is doing. >> >>>>>> > >> >>>>>> > > >> >> In my last project I had similar issues you describe. In >> my >> >>>>>> > > >> >> case I >> >>>>>> > > was >> >>>>>> > > >> >> using Windsor and not releasing my components from the >> >>>>>> > > >> >> container when >> >>>>>> > > >> >> I was done with them. In my case I decided to not release >> my >> >>>>>> > > >> >> objects >> >>>>>> > > >> >> and use the NoTrackingReleasePolicy instead, as this was >> >>>>>> > > >> >> fine for my >> >>>>>> > > >> >> needs and removed the leak that I had. >> >>>>>> > >> >>>>>> > > >> >> I have blogged about this here: >> >>>>>> > >> >>>>>> > >> >>>>>> > > > >> http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-l... >> >>>>>> > >> >>>>>> > > >> >> Cheers >> >>>>>> > > >> >> Stefan >> >>>>>> > >> >>>>>> > > >> >> On Wed, Mar 4, 2009 at 9:04 AM, Andrew < >> [email protected]> >> >>>>>> > > >> >> wrote: >> >>>>>> > >> >>>>>> > > >> >> > I've just launched an e-commerce website based on >> Monorail >> >>>>>> > > >> >> > and >> >>>>>> > > using >> >>>>>> > > >> >> > ActiveRecord. It's a replacement of a previous PHP >> >>>>>> > > >> >> > solution and we >> >>>>>> > > >> >> > have on average about 20 - 30 concurrent users at any >> >>>>>> > > >> >> > given time. >> >>>>>> > > I'm >> >>>>>> > > >> >> > also running an admin site in the same application >> pool. >> >>>>>> > >> >>>>>> > > >> >> > My issue is to do with memory usage. I'm running on a >> 1GB >> >>>>>> > > >> >> > VPS box >> >>>>>> > > >> >> > (also hosting a SQL Server DB on same machine). I've >> >>>>>> > > >> >> > limited SQL >> >>>>>> > > >> >> > Server to 200MB and my IIS6 worker process to 400MB. >> >>>>>> > > >> >> > However, even >> >>>>>> > > >> >> > pre- >> >>>>>> > > >> >> > release when testing with 1 or 2 users the memory usage >> >>>>>> > > >> >> > would >> >>>>>> > > easily >> >>>>>> > > >> >> > sit around the 300MB mark. Now with the real load, I'm >> >>>>>> > > >> >> > seeing the >> >>>>>> > > >> >> > application pool recycle approx every 40 mins (normally >> >>>>>> > > >> >> > should only >> >>>>>> > > >> >> > recycle at 3am). I'm using the ASP.Net state service so >> >>>>>> > > >> >> > session >> >>>>>> > > >> >> > details are preserved but still, I'm concerned >> >>>>>> > >> >>>>>> > > >> >> > As I said, it's an e-commerce site so there's the >> usual >> >>>>>> > > >> >> > shop >> >>>>>> > > stuff: >> >>>>>> > > >> >> > lots of nice pics, searches, checkout and a bit of 2nd >> >>>>>> > > >> >> > level >> >>>>>> > > caching >> >>>>>> > > >> >> > for things such as categories (max 200 categories), >> >>>>>> > > >> >> > countries, >> >>>>>> > > rates >> >>>>>> > > >> >> > etc. Really not that much is cached and mem usage was >> high >> >>>>>> > > >> >> > before >> >>>>>> > > we >> >>>>>> > > >> >> > fully optimised the site. I've been careful to have the >> >>>>>> > > >> >> > SQL >> >>>>>> > > profiler >> >>>>>> > > >> >> > beside me as we were testing the app, so I'm confident >> >>>>>> > > >> >> > that I don't >> >>>>>> > > >> >> > have N+1s all over the place. Oh, and I'm using >> standard >> >>>>>> > > session-per- >> >>>>>> > > >> >> > request model using Ayende's UOW stuff >> >>>>>> > >> >>>>>> > > >> >> > I guess what I'm asking is: Is that level of memory >> usage >> >>>>>> > > >> >> > expected >> >>>>>> > > >> >> > for that type of site? I would love to hear back from >> >>>>>> > > >> >> > anyone who >> >>>>>> > > has >> >>>>>> > > >> >> > launched a similar type of site. >> >>>>>> > >> >>>>>> > > >> >> > I did see a previous post about this, but they are >> >>>>>> > > >> >> > talking around >> >>>>>> > > >> >> > the >> >>>>>> > > >> >> > 200MB mark, so I'm wondering what on earth I'm doing >> >>>>>> > > >> >> > wrong! >> >>>>>> > >> >>>>>> > > >> >> > There is the option of shelling out more cash and go to >> a >> >>>>>> > > >> >> > 2GB VPS >> >>>>>> > > >> >> > box, >> >>>>>> > > >> >> > but I'd rather not have to.... >> >>>>>> > >> >>>>>> > > >> >> > cheers >> >>>>>> > >> >>>>>> > > >> >> -- >> >>>>>> > > >> >> Stefan Sedich >> >>>>>> > > >> >> Software Developer >> >>>>>> > > >> >>http://weblogs.asp.net/stefansedich >> >>>>>> > >> >>>>>> > > >> -- >> >>>>>> > > >> Stefan Sedich >> >>>>>> > > >> Software Developer >> >>>>>> > > >>http://weblogs.asp.net/stefansedich >> >>>>>> > >> >>>>>> > > -- >> >>>>>> > > Stefan Sedich >> >>>>>> > > Software Developer >> >>>>>> > >http://weblogs.asp.net/stefansedich >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> > > >> > >> >> >> > - Show quoted text - > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
