Ok, so here is what my profiling sessions are showing. I can see that one problem is the messageId that you keep. The thing is that it never goes down to 10000 as you say. On the contrary it has a strange behavior but in general it goes up. Second problem is that the unmanaged memory goes quite high also after each batch (not always though, I have sent batches that did not increase that). Both of these two appear inside Rhino Queues as you also said and I see many handles left over to the essent db.
In order to be more concrete I have sent you a test project built with the latest rhino-esb not from your trunk though but from the hibernating-rhinos trunk. http://github.com/hibernating-rhinos/rhino-esb. There is definitely something going wrong but I am not sure where and why. Many thanks for your interest. On Oct 17, 2:03 pm, Ayende Rahien <[email protected]> wrote: > Phew! > You had me worried for a while. > > The actual reason is a bit complex, but the short of it is that there is no > memory leak, and that the behavior you see is expected. > > What is actually happening is: > * The memory is held inside Rhino Queues. > * We hold on to the MessageId to avoid giving you a message more than once > in case of network hiccups. > * Every 3 minutes, we clean the list up, trimming it to the latest 10,000. > > The last is controlled by: QueueManager.NumberOfReceivedMessagesToKeep > > On Sat, Oct 16, 2010 at 10:32 PM, George V. Nikolaropoulos < > > > > [email protected]> wrote: > > I have just rewritten the Save method on the Subscription details > > class this way: > > > public void Save() > > { > > ViewMode = ViewMode.ChangesPending; > > for (Int32 i = 0; i < 6000; i++) > > { > > bus.Send(new UpdateDetails > > { > > UserId = 1, > > Details = new SubscriptionDetailsDTO > > { > > Name = > > Editable.Name, > > Street = > > Editable.Street, > > HouseNumber = > > Editable.HouseNumber, > > City = > > Editable.City, > > ZipCode = > > Editable.ZipCode, > > Country = > > Editable.Country, > > CreditCard = > > Editable.CreditCard > > } > > }); > > } > > } > > > Just to note that the old version of RSB with the Windsor 2.1 seems a > > little better but still over time there is memory that doesn't get > > collected. Is that enough info? Would you like me to email you > > anything else in person? > > > Many thanks for the help. > > > On Oct 16, 11:17 pm, Ayende Rahien <[email protected]> wrote: > > > Hm, > > > I am pretty sure that we don't have a memory leak, since we are using RSB > > in > > > prod for over two years, and haven't found it. > > > Can you create a repro project for this? > > > > On Sat, Oct 16, 2010 at 9:52 PM, George V. Nikolaropoulos < > > > > [email protected]> wrote: > > > > I am looking into Rhino-esb and NServiceBus for a smart client > > > > application. I was doing some stress testing lately and I noticed some > > > > very strange behavior with rhino-esb. I tried to send large numbers of > > > > requests at the same time (6000-10000) and the memory of my back-end > > > > when using rhino-esb was continuously rising. I thought there was > > > > something with my code but memory profiling didn't show anything like > > > > that. > > > > > So I tried to stress the Alexandria application. I tried to send 6000 > > > > UpdateDetailsRequest requests within a for loop and the behavior was > > > > the same: after each batch 60mb of memory were "magically" lost (I > > > > have also a print screen from process explorer for anyone interested). > > > > I have even left the application running for quite a while (30mins) > > > > after these tests waiting for the memory to go down but no luck. I > > > > have to note that both the host and the client were running to the > > > > same machine. > > > > > Am I using it wrong? am I expecting too much? > > > > > Any help will be really appreciated. > > > > Thanks. > > > > > -- > > > > 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]<rhino-tools-dev%2Bunsubscribe@ > > > > googlegroups.com> > > <rhino-tools-dev%[email protected]<rhino-tools-dev%252Bunsubsc > > [email protected]> > > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/rhino-tools-dev?hl=en. > > > -- > > 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]<rhino-tools-dev%2Bunsubscribe@ > > googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. -- 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.
