[SR-Users] rtpengine cpu usage

Diego Nadares dnadares at gmail.com
Wed May 3 18:19:40 CEST 2017


Thanks for your replies.


>System CPU or User CPU?
Well, it's cpu from top.
%Cpu0  :  8.3 us,  6.2 sy,  0.0 ni, 84.4 id,  0.0 wa,  0.0 hi,  1.0 si,
 0.0 st
%Cpu1  :  6.2 us,  5.2 sy,  0.0 ni, 86.5 id,  0.0 wa,  0.0 hi,  2.1 si,
 0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
                                            5671 root      15  -5  779912
 13856   1556 S  14.9  0.7   0:22.73 rtpengine

>This says nothing since your guest might be throttled.

>You neglected to mention this explicitly, but I guess you are trying to
>say that rtpproxy uses less during normal operation?

Yes, rtpproxy uses less than rtpengine. Right now, with 300 calls, rtpproxy
is using 7% and rtpengine almost 13% of cpu.

>If kernel forwarding is not in use, I would strongly suggest to enable it.
I compiled just daemon mode with no kernel module. I think I will try this
too, eventually. I have to see how to compile it here.

This is my cfg. Could you check if this is ok?

route[NATMANAGE] {
        xlog("L_ERR", "NATMANAGE $Ri $rd  $du $avp(rtpengine)");

        #Just replies
        if (!is_pure_ip($rd)){
                if ( $avp(rtpengine) == "1"){
                        xlog("L_ERR", "NATMANAGE $rd Not a valid ip -
rtpengine active");
                        rtpengine_manage("replace-origin
replace-session-connection ICE=remove");
                }
                exit;
        }

        if (is_ip_rfc1918($Ri)){
                if (is_ip_rfc1918($rd)){
                        xlog("L_ERR", "NATMANAGE Priv -> Priv");
                        #Not proxying for now
                        $avp(rtpengine) = "1";
                        rtpengine_manage("direction=priv direction=priv
replace-origin replace-session-connection RTP/AVP");
                }
                else{
                        xlog("L_ERR", "NATMANAGE Priv -> Pub");
                        $avp(rtpengine) = "1";
                        #rtpengine_manage("direction=priv direction=pub
replace-origin replace-session-connection ICE=remove RTP/AVP");
                        rtpengine_manage("direction=priv direction=pub
replace-origin replace-session-connection ICE=remove");
                }
        }
        else{
                if (is_ip_rfc1918($rd)){
                        xlog("L_ERR", "NATMANAGE Pub -> Priv");
                        $avp(rtpengine) = "1";
                        #rtpengine_manage("direction=pub direction=priv
replace-origin replace-session-connection RTP/AVP ICE=remove");
                        rtpengine_manage("direction=pub direction=priv
replace-origin replace-session-connection ICE=remove");
                }
                else{
                        xlog("L_ERR", "NATMANAGE Pub -> Pub");
                        $avp(rtpengine) = "1";
                        #rtpengine_manage("direction=pub direction=pub
replace-origin replace-session-connection RTP/AVP ICE=remove");
                        rtpengine_manage("direction=pub direction=pub
replace-origin replace-session-connection ICE=remove");
                }

        }

        return;
}

Thanks!

Diego.

2017-05-03 13:01 GMT-03:00 Richard Fuchs <rfuchs at sipwise.com>:

> On 05/03/2017 11:10 AM, Diego Nadares wrote:
>
> Hi guys,
>
> I'm using rtpengine (compiled from source) and I see a lot of difference
> in cpu usage comparing with rtpproxy. Is this normal?
>
> With 600 calls:
>
> cpu
> *41.7%* rtpengine
>
>
> System CPU or User CPU?
>
> If kernel forwarding is not in use, I would strongly suggest to enable it.
>
> Also, running rtpengine (and I would think the same is true for rtpproxy)
> in a VM is not recommended.
>
> Cheers
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170503/67a1afb4/attachment.html>


More information about the sr-users mailing list