[SR-Users] Possible memory leak dealing with presence in kamailio

[Nuno Reis]

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 | nreis at 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 <miconda at 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 <nreis at 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 | nreis at 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 <jh at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150130/5285bdf6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16423 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150130/5285bdf6/attachment.png>