I am running a memory profiler on my UCMA application which works as a client that adds recorder participants to a session and I notice a lot of string instances eating up memory (even when participants are removed and after some time of inactivity I notice these strings don't get garbage collected):

Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.DiagnosticsInformation..ctor( int,DiagnosticVisibility )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.DiagnosticsInformation.CreateOutgoingDiagnosticsInformation( uint )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Call.SignalingSession_StateChanged( object,SignalingStateChangedEventArgs )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.EventWorkitem<TEventArgs>.Process()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.WorkitemQueue.ProcessItems()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessing()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessingCallback( object )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod( WaitCallback,object )
mscorlib!System.Threading.ExecutionContext.Run( ExecutionContext,ContextCallback,object )
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal( _ThreadPoolWaitCallback )
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback( object )

I see about 2000 instances like this and they're not being cleaned up. Has anyone seen this before and knows what the cause could be or if this is a UCMA issue in the framework itself?

Edit: I also see a lot of deserialization on the framework (XML deserializer object not being cleaned up?)

System.Xml!System.Xml.Serialization.XmlSerializer.Deserialize( XmlReader,string,XmlDeserializationEvents )
System.Xml!System.Xml.Serialization.XmlSerializer.Deserialize( XmlReader,string )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.XmlHelper.DeserializeObjectFragment( byte[],XmlSerializer )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Conferencing.ConferenceJoinCommandResponse.TryProcessResponseCore( SipMessageData,ref RealTimeException )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Conferencing.EstablishFocusSessionsAsyncResult.ParticipateCallback( IAsyncResult )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.CompletionCallbackWorkItem.Microsoft.Rtc.Signaling.IWorkitem.Process()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.WorkitemQueue.ProcessItems()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessing()
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessingCallback( object )
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod( WaitCallback,object )
mscorlib!System.Threading.ExecutionContext.Run( ExecutionContext,ContextCallback,object )
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal( _ThreadPoolWaitCallback )
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback( object )
有帮助吗?

解决方案

Garbage collection is not triggered by some time of inactivity. There is nothing wrong with seeing a lot of instances of string or any other class in memory. And interned strings (compile time constants) are never collected.

You don't have a memory leak until you get an Out-Of-Memory exception.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top