Alachisoft / NCache

NCache: Highly Scalable Distributed Cache for .NET
http://www.alachisoft.com
Apache License 2.0
647 stars 123 forks source link

Memory consumption on pub/sub cache #57

Closed andrevoltolini closed 3 years ago

andrevoltolini commented 4 years ago

Hi,

I'm using Events & Pub / Sub Messaging, as time goes by, the cache memory consumption grows in but it is not released. I am setting the expiration when creating the message and I also configured the expiration in the cache configuration file on the server. I believe that something is missing, as it is something very basic and there is no information available. Related issue in #45. I appreciate any help.

Publisher:

             _topic = _cache.MessagingService.GetTopic(eventName);
            if (_topic == null)
            {
                _topic = _cache.MessagingService.CreateTopic(eventName);
                _topic.ExpirationTime = TimeSpan.FromMinutes(10);
            }
            Message message = new Message(@event, TimeSpan.FromMinutes(10));
            _topic.Publish(message, DeliveryOption.Any, true);

Server cache config:

      <expiration-policy enabled="True">
          <absolute-expiration longer-enabled="False" longer-value="0" default-enabled="True" default-value="30"/>
          <sliding-expiration longer-enabled="False" longer-value="0" default-enabled="False" default-value="30"/>       
      </expiration-policy>    
      <cleanup interval="15sec"/>
      <storage type="heap" cache-size="128mb"/>
      <eviction-policy default-priority="normal" eviction-ratio="25%"/>
      <cache-topology topology="replicated">

Version: 5.0 SP3

Thanks for any help.

Mark-NCache commented 3 years ago

Hi @andrevoltolini ,

Please note that I’ve tried reproducing this issue on my end using the code snippet provided and was not able to do so, it is working fine for me without any issues. I think we need more details to analyze this.

Please see if you can share a sample application which we can use in our environment to reproduce this issue. This will be really helpful in narrowing down the root cause.

If that’s not doable, then please share the memory dumps of your “Alachisoft NCache Cache Host Process” from your NCache servers. Please take the memory dumps when: • Cache host processes are consuming normal memory. • Cache host processes are consuming high memory. Moreover, please send us the following DLLs and the cache config file along with the memory dumps • C:\Windows\Microsoft.NET\Framework64<v4.0 framework version>\sos.dll • C:\Windows\Microsoft.NET\Framework64<v4.0 framework version\mscordacwks.dll • C:\Windows\Microsoft.NET\Framework64<v4.0 framework version \clr.dll • C:\Windows\Microsoft.NET\Framework<v4.0 framework version>\sos.dll • C:\Windows\Microsoft.NET\Framework<v4.0 framework version\mscordacwks.dll • C:\Windows\Microsoft.NET\Framework<v4.0 framework version \clr.dll • Config files from the Cache Servers hosting the clustered cache located at “C:\Program Files\NCache\config\config.ncconf”

Please let me know if there are any questions.

andrevoltolini commented 3 years ago

Hi @Mark-NCache,

Below is the link to download the requested files. I appreciate the help.

Files.zip

Dan-Ahmed commented 3 years ago

Hi @andrevoltolini ,

We have conducted a complete memory dump analysis that you had shared with us and we have also done code review based on this analysis. During analysis, we found some issues where the "ClientManager" data structures were not getting disposed and are kept in memory. It seems that your client applications connect and dispose the cache very frequently and there are a few situations where these connection handles are not being disposed. There were 2600+ such instances were found which seem to be the main cause of over utilization of memory.

We then created an environment and an application based on our dump analysis to reproduce this issue in our environment. We saw several instances of disposed but pinned "ClientManager" data structures in the memory but in our case it was not increasing memory too much as the number of connection handles seen in our environment was very low compared to your environment.

Issue Fix: Engineering is currently reviewing this more and plan to provide a fix of this issue. It is expected to be releases as part of our upcoming NCache version 5.0 SP4 released expected in next 2-3 weeks.

I hope this will fix will resolve your issue.

andrevoltolini commented 3 years ago

Hi @Dan-Ahmed, thank you very much for the answer. This demonstrates the seriousness with which Alachisoft takes the product and the community. I will be waiting for the new version and thanks again.

Dan-Ahmed commented 3 years ago

Hi @andrevoltolini ,

I trust you're in good health. I wanted to update you in regards to the PUB/SUB memory consumption issue that was raised a couple of months ago. Our engineering team has fixed this issue in the NCache v5.0 SP4 release and you can download the NCache 5.0 SP4 OSS Edition using the following link.

https://www.alachisoft.com/download-ncache.html

Please let us know if this resolves your issue and feel free to reach out in case of any questions.

andrevoltolini commented 3 years ago

Hi @Dan-Ahmed, thanks for the reply. I will plan to upgrade SP3 to SP4 next weekend. As soon as I have the results, I'll let you know. Thanks again.

Dan-Ahmed commented 3 years ago

Hi @andrevoltolini ,

Thanks for your response, I want to add a few more details on my previous comment.

The fix is provided in NCache v5.0 SP4 and is entirely based on the memory dumps analysis as well as NCache code review done by our engineering team as mentioned in my comments above. We were unable to reproduce your exact case on our side and this is released as a tentative fix.

It is highly recommended that you try NCache v5.0 SP4 in your test environment and let us know if this resolves your issue. This will help us validate that the issue is indeed fixed.

I hope this helps and we will wait for your feedback here.

andrevoltolini commented 3 years ago

Hi @Dan-Ahmed,

The fix worked perfectly. Please extend my thanks to everyone involved and especially engineering. Another point to be highlighted is that this version is much faster. Thank you.