Hello, can you check the expires column in presentity table. The issue might be accumulation of too many dialog-info documents, due to large expires interval, taken from the default lifetime of the dialog. You can change that with:
- http://kamailio.org/docs/modules/4.2.x/modules/pua_dialoginfo.html#idp2576952 Cheers, Daniel On 30/01/15 16:43, Nuno Reis wrote: > 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 <mailto: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/>* > > Description: Description: WavecomSignature > <http://www.wavecom.pt/pt/wavecom/premios.php> > > Publicity <http://www.wavecom.pt/pt/mail_eventos.php> > > > > On Fri, Jan 30, 2015 at 5:23 AM, Daniel-Constantin Mierla > <mico...@gmail.com <mailto: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 > <mailto: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 <mailto: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/>* > > Description: Description: WavecomSignature > <http://www.wavecom.pt/pt/wavecom/premios.php> > > Publicity <http://www.wavecom.pt/pt/mail_eventos.php> > > > > On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen <j...@tutpro.com > <mailto: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://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/micond <http://www.linkedin.com/in/miconda> > > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
_______________________________________________ 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
