ossrs / srs

SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181.
https://ossrs.io
MIT License
24.72k stars 5.28k forks source link

srs 4.0 memory leak #4023

Closed l0g1n closed 2 months ago

l0g1n commented 2 months ago

Describe the bug Approximately 10,000 streaming sessions are initiated daily, with no more than 200 streams being concurrently active. Memory usage increases to 1GB and does not decrease. Currently, a system restart is performed once every day.

Version Based on SRS (Simple Real-time Server) version 4.0.271, modifications have been made to include support for RTMP H.265.

Configuration File

listen              1931;
max_connections     2000;
pid                 objs/master1.pid;
srs_log_tank        console;
srs_log_level       info;
srs_log_file        ./objs/master1.log;
daemon              off;

http_server {
    enabled         off;
}

stats {
    network         0;
    disk            sda sdb xvda xvdb;
}

http_api {
    enabled        on;
    listen         8131;
    crossdomain    on;
    raw_api {
        enabled         on;
        allow_reload    on;
        allow_query     on;
        allow_update    on;
    }
}

vhost __defaultVhost__{
    http_hooks {
        enabled         on;
        on_play         http://localhost:10352/api/srs/callback/1931;
        on_publish      http://localhost:10352/api/srs/callback/1931;
        on_unpublish    http://localhost:10352/api/srs/callback/1931;
        on_stop         http://localhost:10352/api/srs/callback/1931;
    }
    cluster {
        mode            local;
        origin_cluster  on;
        coworkers       127.0.0.1:8132 127.0.0.1:8133 192.168.27.66:8131 192.168.27.66:8132 192.168.27.66:8133;
    }
}

Attempted Actions

  1. Applied all patches related to memory leaks from the Issues section, but the problem persists.
  2. Ran the system with Valgrind for about half an hour, during which memory usage increased to around 300MB, but was unable to determine the cause from the logs.
==47==    definitely lost: 1,224 bytes in 17 blocks
==47==    indirectly lost: 386 bytes in 11 blocks
==47==      possibly lost: 13,046,497 bytes in 1,598 blocks
==47==    still reachable: 181,798,229 bytes in 259,573 blocks
==47==                       of which reachable via heuristic:
==47==                         multipleinheritance: 944 bytes in 5 blocks
==47==         suppressed: 0 bytes in 0 blocks
==47== Reachable blocks (those to which a pointer was found) are not shown.
==47== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Below is the complete Valgrind log. v.log

Desired assistance: I am hoping to receive some analytical approaches to resolve this issue.

TRANS_BY_GPT4

winlinvip commented 2 months ago

Please do not file duplicated issue. I will delete this one. BTW: With the smart point developing in progress, we're able to address this issue.

sunpengfei0307 commented 1 month ago

Please do not file duplicated issue. I will delete this one. BTW: With the smart point developing in progress, we're able to address this issue. Hi! Is solved in srs6.0 ?