SRS带宽不足下内存泄漏

  • 最近解决了SRS中的一个bug,特此记录一下。
  • SRS(4.0)服务器上,使用RTMP推流,在网页端用webrtc拉流。设置低带宽场景下存在内存大幅度持续不断上涨现象,应该是有内存泄漏。
  • 观察发现2个现象——1.存上涨幅度与推流端码率成正比。2.关闭nack后内存上涨幅度明显减小。
  • 控制台上打印SRS日志发现错误日志:
[Warn][24154][x6w4gl27][62] handle udp pkt, count=1/1, err: code=1011 : size=104, data=[00 01 00 54 21 12 a4 42] : stun binding request failed : stun binding response send failed : sendto 
thread [24154][x6w4gl27]: cycle() [src/app/srs_app_listener.cpp:630][errno=62]
thread [24154][982648t3]: on_stun() [src/app/srs_app_rtc_conn.cpp:2113][errno=62]
thread [24154][982648t3]: on_binding_request() [src/app/srs_app_rtc_conn.cpp:2773][errno=62]
thread [24154][982648t3]: sendto() [src/app/srs_app_listener.cpp:347][errno=62]
  • 结合日志中代码调用路径,分析可能是SrsUdpMuxSocket::sendto中srs_error_new中new的对象没有释放,修改函数代码将错误直接返回:
if (nb_write <= 0) {
    if (nb_write < 0 && errno == ETIME) {
        return err;
        //return srs_error_new(ERROR_SOCKET_TIMEOUT, "sendto timeout %d ms", srsu2msi(timeout));
    }   

    return srs_error_new(ERROR_SOCKET_WRITE, "sendto");
}
  • 使用gperf.gmp工具分析代码修改前和修改后的函数内存使用情况:
// 原始代码分析结果
Using local file objs/srs.
Using local file gperf.srs.gmp.0001.heap.
Total: 9.8 MB
     2.3  23.2%  23.2%      2.3  23.2% SrsResourceManager::SrsResourceManager
     2.0  20.2%  43.5%      2.0  20.2% _st_new_stk_segment
     1.8  18.2%  61.7%      1.8  18.2% SrsCommonMessage::create_payload
     1.7  17.6%  79.4%      1.7  17.6% std::string::_Rep::_S_create
     1.4  14.5%  93.8%      1.4  14.5% SrsCplxError::create
     0.1   1.3%  95.1%      0.1   1.3% SrsFastStream::SrsFastStream
     0.1   0.7%  95.8%      0.1   0.7% av_malloc_array (inline)
     0.1   0.6%  96.4%      0.1   0.6% SrsUdpMuxSocket::SrsUdpMuxSocket
     0.1   0.6%  97.1%      0.1   0.6% SrsUdpMuxListener::SrsUdpMuxListener


// 修改后代码分析结果
Using local file objs/srs.
Using local file gperf.srs.gmp.0001.heap.
Total: 6.8 MB
     2.3  33.7%  33.7%      2.3  33.7% SrsResourceManager::SrsResourceManager
     2.0  29.3%  63.0%      2.0  29.3% _st_new_stk_segment
     1.9  27.8%  90.8%      1.9  27.8% SrsCommonMessage::create_payload
     0.1   1.8%  92.7%      0.1   1.8% SrsFastStream::SrsFastStream
     0.1   1.0%  93.7%      0.1   1.1% av_malloc_array (inline)
     0.1   0.9%  94.6%      0.1   0.9% SrsUdpMuxSocket::SrsUdpMuxSocket
     0.1   0.9%  95.5%      0.1   0.9% SrsUdpMuxListener::SrsUdpMuxListener
  • 发现修改代码后SrsCplxError::create函数的内存使用就没有那么多了,结合代码基本就能定位问题,应该是有地方调用的SrsCplxError::create,但没有在外面释放内存。查找所有调用了SrsUdpMuxSocket::sendto函数的地方发现华点——果然在SrsRtcConnection::do_send_packet函数中有一段代码没有处理这个错误:
// TODO: FIXME: Handle error.
sendonly_skt->sendto(iov->iov_base, iov->iov_len, 0);
  • 这里加trace打印发现有频繁调用,而且开启nack后在弱网下调用更频繁,结合前面现象,基本可以确定问题就出在这里。修改如下:
if ((err = sendonly_skt->sendto(iov->iov_base, iov->iov_len, 0)) != srs_success) {
    return srs_error_wrap(err, "send to");
}
  • 修改后测试,同样场景下未见内存大幅度增长。
  • 这里不得不吐槽下SRS这种错误处理方式。首先说好处是,打印的错误日志可以还原调用的过程,查找问题很方便。但是带来的问题就是,只要外面有一个地方没有free这个错误指针就会存在内存泄漏。对于像SrsUdpMuxSocket::sendto这样频繁调用的函数内存增长还很明显,比较好查,但是其他地方如果有这样的情况发生,但是内存只会一点点的增长,就很难查了。
  • 很奇怪这个问题应该很明显,而且作者还备注了需要修改,但我后来查看最新的代码这块也还没有修改,不知道是基于什么考虑,望大神指点。
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值