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

Wed Feb 11 04:28:53 CET 2015

Just to be clear. The memory is in Kilobytes (kB).

--

*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, Feb 11, 2015 at 3:26 AM, Nuno Reis <nreis at wavecom.pt> wrote:

> Hi Daniel.
> Thank you for your suggestion and feedback on this.
> I've tried that already and here's what I've found after 15h on a running
> kamailio:
>
> All records in pua and presentity DB tables are gone by the end of the
> day, so the expire time seems to be working.
> I still see system memory growing and not being released again.
> You can find attached (tar.gz) various dumps of pkgstats and shmem usage.
> The number after the 'underscore' in file names corresponds to system
> memory allocation in kamailio at the various timestamps. The earlier
> timestamp corresponds to minute 1.
> So I started with 638632kb system mem allocation and I'm now
> with 1086548kb being used after 15 hours.
>
> I'll continue to investigate the issue but if you have any other
> suggestions on how to tackle this, I'm of course available to test those.
> Looking forward to hear from you.
>
> Best Regards,
>
> --
>
> *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 Mon, Feb 9, 2015 at 5:05 PM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>>  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 | 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>
>>>
>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio World Conference, May 27-29, 2015
>> Berlin, Germany - http://www.kamailioworld.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150211/fa7fb413/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 16423 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150211/fa7fb413/attachment.png>
-------------- 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/20150211/fa7fb413/attachment-0001.png>