Live: Source cleanup to free memory for multiple streams. #3667
Replies: 10 comments 5 replies
-
That's right, this overhead can be calculated.
|
Beta Was this translation helpful? Give feedback.
-
Same question, if SRS keeps running, the number of sources will keep increasing, when will they be released? |
Beta Was this translation helpful? Give feedback.
-
9900 streams only occupy 65MB of memory.
|
Beta Was this translation helpful? Give feedback.
-
The situation of Source cleanup is as follows:
Therefore, I still need to restart this Issue to support a more comprehensive Source cleanup capability. |
Beta Was this translation helpful? Give feedback.
-
Source cleanup will be resolved in SRS 5.0, mainly in monitoring and RTC scenarios, where there will be a large number of streams (Sources). Since the Source pointer is widely referenced, after a long period of consideration, the best solution is to refer to C++11's smart pointers to avoid crashes after cleanup.
|
Beta Was this translation helpful? Give feedback.
-
The problem of Source cleanup is essentially due to the direct reference to Source, which makes it impossible to count and accurately clean up. A better approach is to make Source an internal type and expose a wrapped type externally. Each time it is used, a new wrapped type is created, similar to a smart pointer.
Add a wrapped type:
Also avoid creating pointers, always use instances, so you can accurately know how many references there are. Then, combined with a simple GC for delayed release, this can most simply solve the Source cleanup problem. It's a bit like a smart pointer, but much simpler, relying on specifications and type hiding to implement. It will be a bit more complicated, but overall it's quite simple. This can also be used to solve other objects that need to be cleaned up but are widely referenced. |
Beta Was this translation helpful? Give feedback.
-
Pushing a stream every 5 seconds, the memory will increase to 4.2GB in about three days. In scenarios with a large number of push-pull streams, such as stress testing, monitoring, and calling, this problem is quite serious. Some optimizations are planned for 5.0, without deleting Source, to do some cleanup and slow down the memory growth. The plan is to delete Source in 6.0 and completely solve this problem. |
Beta Was this translation helpful? Give feedback.
-
Synchronize the progress: It is confirmed that WebRTC's own implementation of ShraredPtr and WeakPtr smart pointers will be referenced, but a simpler version will be implemented and used only in Source objects. It will be done in two steps to avoid affecting stability: it will be implemented and partially cleaned up in 5.0, and it is expected to be completely resolved in 6.0. |
Beta Was this translation helpful? Give feedback.
-
Another approach is to refactor with Rust, but the implementation might be challenging. |
Beta Was this translation helpful? Give feedback.
-
Before any work addressing this issue, we need refine the shared ptr of SRS, which is used in RTMP shared message, GB sessions, and in future source objects. Refer to Using C++11’s Smart Pointers, there are three varieties of smart pointers:
If we carefully design and limit the usage of smart ptr, such as no cycle link that means we do not need weak ptr, we can archive a simple and easy to maintain smart ptr for SRS. We also consider bellow features:
Again, we don't want to switch to C++11 because I think the modern C++ 11/14/17/20 is really a horrible thing that does not fix anything, but introduces a lot of bad grammar sugar. We do not want any grammar sugar, which is very harmful for communication. We have experienced a lot of disaster of smart pointers and sugars, so we want to keep the usage very simple:
In the other hand, we should not reinvent wheels especially for smart ptr, so we must use almost the same API of C++ standard library. That is why we should learn from C++11 and refactor the similar smart ptrs in SRS. Smart pointers might seem simple when they’re just about memory management, but when you delve into inheritance, copying, comparison, performance, circular references, pointer conversion, creation, and the purism of "no naked new", their capabilities become significantly richer. In reality, the main issues with C++ programs stem from programmers messing around, and this purism along with various syntactic sugar makes it hard to notice when they are. Most problems can be addressed with something as straightforward as an AK47, yet there's an obsession with acquiring more advanced weaponry, which leads to a situation where, on the battlefield, you can’t even fire a shot due to jams and blowbacks. This is because it’s very hard to spot when programmers are messing about in companies, with large amounts of code being submitted, the usage of various new features, and tight deadlines. The true gates of hell in C++ are not the limited old features of C, but its plethora of new features.
|
Beta Was this translation helpful? Give feedback.
-
If a server is continuously requested with
rtmp://xxx/live/(1-100000)
, the number of objects keeps increasing, and no release logic is found.Related issues:
Beta Was this translation helpful? Give feedback.
All reactions