Heap memory problems

2019-04-07 03:03发布

问题:

There's a WCF self hosted service that must work 99% of time. Sometimes we got some memory troubles like this:

But service is working as usual after that issues. How can we manage this? Any tips and points to make robust services that will survive in different except situations are very very welcome.

回答1:

I am not too sure where the problem resides but memory leaking can be a reason.

All code is managed. And we use dotConnect for Oracle from devArt as data layer library.

You assume all code is managed, but there can be unmanaged parts. However, you must call the Dispose method for all the disposable objects after using them, don't think they are properly dispose once they go out of scope. The best practice is, not to let Disposable objects to go out of scope without calling their Dispose method. You may be able to use 'using' statements if you are using them as local variables.

DbConnection is a good example for disposable objects, make sure you dispose all the connections (disposable objects).



回答2:

If it's a WCF problem (I'm not sure what to do with your dump), I suggest you activate WCF server-side tracing, and have a look at the exceptions if there are any (and edit your question so we can further help you).

Here is a link that explain how to do this:

How to enable WCF tracing



回答3:

What are your Service Behaviors particularly ConcurrencyMode and InstanceContextMode.

if you have Multiple as ConcurrencyMode and InstanceContext set to (PerCall, or PerSession(default)) you can definetely run into issues if you have large DataStructures or undisposed resources.

if you are using multiple Concurrency try InstanceContextMode Single [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)]



回答4:

Are you 100% none of you dependencies have unmanaged code? I've seen something very similar to this happen, and it was happening because we were deallocating memory that another process would also try to deallocate later.