Hi Daniel. Thanks for answering me back. I'll follow the exact procedures from here: http://www.kamailio.org/wiki/tutorials/troubleshooting/memory and will let you know about my exact finding soon.
Cheers, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS <http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88> | www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>* [image: Description: Description: WavecomSignature] <http://www.wavecom.pt/pt/wavecom/premios.php> [image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php> On Fri, Jan 30, 2015 at 5:23 AM, Daniel-Constantin Mierla <mico...@gmail.com > wrote: > Hello, > > which memory is increasing? shared or private memory? or is system memory? > > Cheers, > Daniel > > On Fri, Jan 30, 2015 at 4:24 AM, Nuno Reis <nr...@wavecom.pt> wrote: > >> Hi Juha and all. >> >> I understand that and that is what the RFC says. It seems pua module does >> that right. Although something is clearly not right in my production >> environment because kamailio memory consumption still grows pretty fast. >> Kamailio memory usage starts in ~500MB and after ~24H kamailio is using >> ~3GB. If I disable kamailio from listening on the localhost(127.0.0.1) >> where pua is generating the SIP Publishes kamailio just keeps around the >> ~500MB all the time. >> This is a small production environment with 70 extensions with Yealink >> phones. >> Any ideas on how to chase down this memory leak? Should I open a git >> issue for this one? >> >> >> >> -- >> >> *Nuno Miguel Reis* | *Unified Communication** Systems* >> M. +351 913907481 | nr...@wavecom.pt >> WAVECOM-Soluções Rádio, S.A. >> Cacia Park | Rua do Progresso, Lote 15 >> 3800-639 AVEIRO | Portugal >> T. +351 309 700 225 | F. +351 234 919 191 >> *GPS >> <http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88> >> | www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>* >> >> [image: Description: Description: WavecomSignature] >> <http://www.wavecom.pt/pt/wavecom/premios.php> >> >> [image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php> >> >> >> >> On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen <j...@tutpro.com> wrote: >> >>> Nuno Reis writes: >>> >>> > Here my publisher is Kamailio itself. Can someone elaborate a bit more >>> on >>> > this issue and maybe we can get to bottom of it? >>> >>> when your application issues initial publish request, it does so without >>> SIP-If-Match header. 200 ok from presence server then contains an etag >>> in SIP-ETag header. when your application refreshes the publish, it must >>> place this etag in SIP-If-Match header to prevent presence server from >>> creating a new publication. >>> >>> for subscribes, your application must place in re-subscribe the >>> same event header id param as the previous one had in order for the >>> presence server to know that subscribe was not a new subscription. >>> >>> -- juha >>> >> >> > > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond > <http://www.linkedin.com/in/miconda> >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
