Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High Memory Consumption Issue #1245

Open
imtadashi opened this issue Nov 30, 2024 · 12 comments
Open

High Memory Consumption Issue #1245

imtadashi opened this issue Nov 30, 2024 · 12 comments
Labels

Comments

@imtadashi
Copy link

Hi Sipsorcery team, I have been using Sipsorcery for few weeks and found memory consumption increases gradually. Is this normal? Even after stopping a PeerConnection, this memory is not disposed. Is there a way to forcefully dispose memory consumed by a PeerConnection or VideoStream?

@sipsorcery
Copy link
Member

What sort of memory consumption is involved? Are you using any video encoding?

@imtadashi
Copy link
Author

I am using VP8 for video and PCMU for audio. Actually I am setting up a basic SFU server. I have a group and separate PeerConnection for each users. I get their RTP packets and broadcast it to other members of the group using OnRtpPacketReceived.

@imtadashi
Copy link
Author

I think memory gradually increases in the receiving part. I removed the broadcasting code and ran the application, the memory still increased. Are the receiving RTP packets/frames stored locally in any buffer?

@ha-ves
Copy link
Contributor

ha-ves commented Dec 5, 2024

I can't replicate this with SIPSorceryMedia.FFmpeg (Sending & Receiving).

RTP framing and depacketizer each do copies in their process but they look to be garbage collected correctly.

@imtadashi
Copy link
Author

I have this code in the SFU part

MediaStreamTrack videoTrack = new MediaStreamTrack(SDPMediaTypesEnum.video, false, MCU_Server.VideoOfferFormats, MediaStreamStatusEnum.SendOnly, headerExtensions: result);
PC.addTrack(videoTrack);

PC.OnRtpPacketReceivedByIndex += (index, rep, media, rtpPkt) =>
{
    if(media == SDPMediaTypesEnum.video)
    {
        foreach (var user in pcs.participants)
        {
            if (user.Key != userId)
                user.Value.pc.VideoStreamList[(int)rtpPkt.Header.SyncSource - 1].SendRtpRaw(rtpPkt.Payload, rtpPkt.Header.Timestamp, rtpPkt.Header.MarkerBit, rtpPkt.Header.PayloadType);
        }
    }
}

This is what happens when I start receiving RTPPackets from an user.
102mb is normal after starting the app. From 102mb, it goes to 130mb while initializing RTCPeerConnection and VideoTracks. After that it starts increasing. When it reaches to 183mb, I stopped the PeerConnection and the memory consumption also stops.

memoryConsumption.mp4

One time I even removed the SendRTP line and executed the code (only received packets, didn't forward)

PC.OnRtpPacketReceivedByIndex += (index, rep, media, rtpPkt) =>
{

}

But still the memory increased.

I am currently checking Sipsorcery library for the memory consumption cause. This where the OnRtpPacketReceivedByIndex happens, right? Or do I have to check SipsorceryMedia.FFMpeg?

Few minutes after the PeerConnection was closed, memory is cleared. But is it normal to have memory consumption while receiving RTPPackets?

@sipsorcery
Copy link
Member

Few minutes after the PeerConnection was closed, memory is cleared. But is it normal to have memory consumption while receiving RTPPackets?

Yes, particularly with video streams. There are a lot of buffer copies required which all add up.

@imtadashi
Copy link
Author

Is it possible to clear the used copies?

@sipsorcery
Copy link
Member

PR's welcome.

@imtadashi
Copy link
Author

Sure, I’m happy to work on this. Do you have any idea which files might be causing this issue? I am currently checking OnReceiveRTPPacket().

@crashedapp
Copy link

@imtadashi
For starters do a GC.Colect() and see if that releases the memory.
.net can hang onto memory as explained many times by David Fowler as part of its "optimizations" strategy. Not a memory leak per se. You can eliminate that is what is holding onto the memory by forcing a garbage collection.

If no memory is released, then do snapshots in Visual Studio to find out who is hanging on to that memory.

Hope this helps

@imtadashi
Copy link
Author

GC.Collect() works, but it consumes more CPU. Maybe using it with interval may reduce the memory consumption and maintain the CPU usage.

@ha-ves
Copy link
Contributor

ha-ves commented Dec 19, 2024

sorry for butting in, Forcing Garbage Collection is discouraged, via MSDN,

It's possible to force garbage collection by calling Collect, but most of the time, this call should be avoided because it may create performance issues.

Since I can't reproduce this, you can try to make the barest reproducible method for your case and use the Memory Profiling to find which part of RTCPeerConnection is heaping up,
Measure memory usage in Visual Studio
dbgdiag-mem-managed-types-report-paths-to-root

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants