-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
ingest memory leak issue #553
Comments
There is no relationship between error reporting and memory leaks, right?
|
I tested it again several times, and the memory leak is quite serious. On CentOS 6.5 system, with 100 ingest instances running for 12 hours, the system's VIRT increased from 200M to 2700M, and RES increased from 160M to 650M. However, according to the analysis results from gmc, the leak is not obvious.
|
Grass...
|
Is it SRS2 or SRS3?
|
The version is srs (ossrs) 3.0.6.
|
Please test 2.0 and 1.0.
|
Using SRS 2.0.206, after running for 3 hours, VIR increased from 170M to 650M, and RES increased from 120M to 270M. It is suspected that during the collection of FLV files, when reading data to the end of the file, there is a repeated forking of the ffmpeg process, which starts collecting from the beginning of the file again.
|
Reference #559 is the issue with joining this thread. @tufang14 fixed it.
|
The latest branch code is being used for development. The SRS configuration file enables 100 ingest instances to collect the source.200kbps.768x320.flv file from the doc. The content of the configuration file is as follows:
After running for a period of time, it was discovered that the memory slowly increases. After running for a day, the program throws an error.
During the retesting, the GMC memory leak detection was enabled, and the code was recompiled. The program was then run for one hour.
The analysis results are as follows:
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered: