The reason that the infinite loop thingie is important is that GC only happen when the CLR decides it feels like it.So it is perfectly fine for memory to go up until the pressure go up enough to do a GC.
On Thu, Sep 3, 2009 at 10:09 PM, Ayende Rahien <[email protected]> wrote: > I run it, and I don't see a memory leak.You _are_ putting the system into > a infinite loop, though. > On my system it is stable on memory after an initial rump up time. > > > On Thu, Sep 3, 2009 at 8:21 PM, Jason Meckley <[email protected]>wrote: > >> >> here is the source >> >> http://groups.google.com/group/rhino-tools-dev/web/potential_memory_leak.zip >> >> On Sep 3, 12:48 pm, Jason Meckley <[email protected]> wrote: >> > tabbed to enter and hit space bar. picking up where I left off... >> > >> > itappears the major offenders are: >> > System.Security.Policy.PolicyLevel (3) totaling 23,080 >> > System.Reflection.Emit.OpCode and System.RunTimeType (~1020) totaling >> > 15,556 >> > >> > going back to the root and looking at all threads doesn't give me much >> > though. well, maybe it does, but I cannot tell for sure. >> > >> > Castle.Core.Resource.ConfigResource(String sectionName) ctor 31.82% >> > Rhino.Queues.Storage.QueueStorage.SetIdFromDb() 6.82% >> > >> > I'll post a zip of the solution and profile shortly. >> > >> > On Sep 3, 12:41 pm, Jason Meckley <[email protected]> wrote: >> > >> > > here's the step up. I have a simple windows service I'm using to spike >> > > RSB with RQ. real simple >> > > 2 consumers (A & B) with 2 messages (A & B) a sends A message to B. B >> > > consumes and sends a message to A. both messges have a byte[] property >> > > with 1024 bytes (just to give the message some weight). >> > >> > > so I update the assemblies fire up task manager, dot trace and the >> > > service. Task manager is showing a steady increase in memory >> > > consumption. although not as drastic with the updated Esent.Interop. >> > > And followinghttp:// >> ayende.com/Blog/archive/2009/08/31/how-i-found-a-memory-leak.aspx >> > > (possibly the only resource on the net for "how to locate a memory >> > > leak"). Here is what I found. >> > >> > > the 2 main culprits on Root are String and Object (lovely, only the 2 >> > > most common types:) ) >> > >> > > I opened both String and Object in separate tabs here are the tops >> > > results >> > >> > > System.String >> > > + System.Object >> > > + Garbage Collection Handler holding 12 objects >> > > totaling 6336 bytes >> > >> > > System.Object holding 18 objects totaling 31924 bytes >> > >> > > So at this point I look at the outgoing references to Object and it >> > > appears the major offenders are: >> > > System.Security.Policy.PolicyLevel >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
